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

Reply via email to