Hi,
There's a third option: put it in an object. before considering the
On Tue, May 15, 2012 at 7:44 AM, Michael Schuerig
<michae...@schuerig.de> wrote:
>
> Here's a question related to OO in Ruby, even if not directly related to
> OOR. When you implement some general functionality, you basically have
> to options. Implement it in a base class to be subclassed, or implement
> it in a module to be included.
other two options you mentioned, I always look very hard to see if
there's a way to put common stuff in a new class.
When you implement some general functionality, you basically have
to options. Implement it in a base class to be subclassed, or implement
it in a module to be included.
Here's a question related to OO in Ruby, even if not directly related to
OOR. When you implement some general functionality, you basically have
to options. Implement it in a base class to be subclassed, or implement
it in a module to be included.
Note that the GoF explicitly tell us to "prefer composition over
inheritance", and that's what most of their design patterns are
attempting to achieve.
On Wednesday, May 16, 2012 4:57:59 AM UTC-7, Kevin Rutherford wrote:Note that the GoF explicitly tell us to "prefer composition over
inheritance", and that's what most of their design patterns are
attempting to achieve.
Actually, out of 23 patterns in the book, only 2 do not use inheritance (Singleton and Memento) - either in the pattern itself, or in the pattern's clients.
This hits the nail on the head about one of the most significant differences between composition and inheritance. Big systems exhibit this problem most notably: >> (ActiveRecord::Base.instance_methods - Object.methods).count => 125 >> ActiveRecord::Base.ancestors.count => 32 I had linked to a pair of Practicing Ruby articles before that cover pretty much everything that has been discussed here so far, but I wasn't doing that to sell my work! A few months ago, I read two papers (one by M. Sakkinen and one by Liskov/Wing which was the source of the Liskov Substitution Principle), and they thoroughly broke my brain. I wrote up a comprehensive summary of how I felt these papers applied to Ruby and ran it in my journal. I've gone ahead and copied my articles over to Gist so that there is now a comment thread that anyone can use on them (not just PR subscribers). Would love to hear feedback there, or here! https://gist.github.com/2721607
I had linked to a pair of Practicing Ruby articles before that cover pretty much everything that has been discussed here so far, but I wasn't doing that to sell my work! A few months ago, I read two papers (one by M. Sakkinen and one by Liskov/Wing which was the source of the Liskov Substitution Principle), and they thoroughly broke my brain. I wrote up a comprehensive summary of how I felt these papers applied to Ruby and ran it in my journal. I've gone ahead and copied my articles over to Gist so that there is now a comment thread that anyone can use on them (not just PR subscribers). Would love to hear feedback there, or here! https://gist.github.com/2721607
Thanks for sharing those, I appreciate it, even though I haven't made the time to read through them yet.
I see your point, I think, but the Post/PostMapper implementationOn Thursday 17 May 2012, Steve Klabnik wrote:
> Before I really reply:
> http://blog.steveklabnik.com/posts/2012-05-07-mixins--a-refactoring-a
> nti-pattern
doesn't look very attractive to me. I'd have to see actual code using
Post and PostMapper, but so far, in my imagination, it seems rather
unwieldy. Say, those posts have comments. Then, in addition to the
PostMapper, I get a CommentMapper. Basically, for every domain entity, I
get a corresponding mapper class. And the relationships among domain
entities are mirrored by relationships among mappers. The PostMapper
needs to know about CommentMapper, in order to first save the post
itself, then extract its comments and save them using a CommentMapper.
I currently prefer a solution where domain entities know a slight bit
about persistence. They get injected with (the moral equivalent of) a
mapper object at creation and know that in order to persist themselves,
they need to call a method on that mapper passing in themselves. The
actual persistence is to a REST service, but the entities know nothing
about that.
Additionally, the mapper is generic, and if one entity instance begets
another, it passes the mapper along. As a consequence, I can inject
special mappers for testing in just one place, the root of an aggregate,
and everything just works.
I'd love to show some code, but I work on this stuff in the context of a
closed-source project and therefore unfortunately can't.