--7/urU3J20UL6XDxf76H
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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.

> 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.

-mental

--7/urU3J20UL6XDxf76H
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHClc7SuZBmZzm14ERAi/rAJwOj8VS0LI2egNp9b5MaE0/yOVsSwCfe5p3
0nUJr2s/v4tfzL2av56bQ1kkd
-----END PGP SIGNATURE-----

--7/urU3J20UL6XDxf76H--