Gabriel Sechan wrote:
The problem comes from not encapsulating state correctly.
I have recently come to the conclusion that it isn't even a problem of
not encapsulating state correctly. It's a problem of the encapsulation
of state changing over time, with the change of requirements.
I have a system right now that senses an external event, looks up a
bunch of information (often in different cities, and/or from different
providers/partners), and sticks it into a database. (Part "R".) It then
has a Part "C" that allows someone to come in and wander around the
external events, looking at them and interacting with them.
Then the boss comes along and says "Hey, we want to take the history of
things that happened at this provider, and let users of Part "C" wander
around in them, just like you looked them up with Part "R". Well,
there's no place in the database to do that, and Part "C" isn't even in
the same programming language as Part "R".
Then the boss says "Hey, not everyone can talk to "C", so we want "R" to
generate, when it gets such an event, all the interactions that "C" can
generate, and send them through a different channel." Well, again, R
doesn't have access to the things C does, and vice versa.
So the stuff was quite nicely encapsulated and all, except for the
changing requirements, where now the encapsulation needs to be all
different.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg