On Oct 8, 9:13 am, MenTaLguY <men... / rydia.net> wrote:
> On Tue, 2007-10-09 at 00:17 +0900, Austin Ziegler wrote:
> > If the answer is few, then you're doing it wrong and you're introducing
> > negative consequences in terms of maintainability, while not actually
> > increasing reuse. Most methods are specific behaviour for a given state.
> > Pretending that by extracting that into modules that youre increasing
> > reuse is nonsense. Unless you're actually reusing the code, you're not
> > increasing reuse.
>
> On the other hand, if you're reusing them in multiple places, e.g.:
>
>  class FooWithBarAndBaz
>    include Foo
>    include Bar
>    include Baz
>  end
>
>  class FooWithBarAndHoge
>    include Foo
>    include Bar
>    include Hoge
>  end
>
> ...you've got to create a distinct class up front for every permutation
> of features.  If you were composing objects instead, you'd be able to
> compose objects dynamically, instead of being limited to the particular
> compositions that you've baked into classes.

How would you do it? Ok, say we create classes for everything instead,
then how do create this dynamic composer? Is it a factory?

  FooWithBarAndHoge = Composer.factory(Foo, Bar, Hoge)

So what's really that difference between this and the above? Or do you
have something else in mind?

Seems like in the end it's formally equivalent no matter how we do it,
only the underlying implementation differs. Of course there are
different trade-offs to consider for different implementations. But I
doubt any one is better than another in all ways. For instance using
delegation, we initialize four new objects in memory for every one
FooWithBarAndHoge, depending on what's more important to us, that
might not be as desirable.

> > Just because your storage representation is flat doesn't mean your
> > in-memory object has to be.
>
> I've come to recognize a tying of the internal representation to the
> serialized form as a code smell, because usually (especially) when the
> serialized form is designed to be human-editable, the requirements for
> the structure of the two can be very different.

There doesn't need to be just one representation for all cases, does
there? A one-to-one map is great for a first layer. Then an adapter
can be created for any different internal representation that's
needed. But in my case, the whole point of the class is really to
provide read-access to that serialized data.

T.