On Fri, 18 Sep 2009 14:46:35 -0700, Uriel <lost.gob...@gmail.com> wrote:
On Fri, Sep 18, 2009 at 3:22 PM, frederic <fduboi...@gmail.com> wrote:
Anticipating changes in the code is a generally a bad idea, because your
predictions are likely to fail
This can't be repeated often enough. Your predictions are not likely
to fail, they are *bound to crumble in an epic implosion of pure
fail*.
Not falling into the pitfall of trying to anticipate future changes in
code is surprisingly *hard*.
The only way to fight against it is to keep your code as simple as
possible, and avoid any speculative code as if it had come from
between RMS's toes. Fortunately this turns out to be the best way to
make code easier to change later on!
Or, another alternative is to use programming language constructs which help
you achieve benefits of polymorphism, encapsulation and code reuse while at the
same time making it easy to break / evolve the initial source code design.
Take a look at "traits", a somewhat new programming language construct recently
introduced in Scala.
http://scg.unibe.ch/research/traits
Its pretty orthogonal to OO and seems to be a good alternative to inheritance
for code reuse. Of course, only time and experience with the construct would
tell how much of an improvement it really is.
--
Pinocchio
