By way of an example of how implementation technology and language features can impact software architecture, I recently had several days worth of meethings with a room full of designers. The scenario is this: there is a Class A, and B inherits from A (the first subsystem knows only about A’s, and the second knows about A’s and B’s). Some part of the subsystem makes an A object and hands it off to another subsystem. This other thread of execution needs to add some behaviour to the base class type (which is why we need a B type), but we cannot require the folks who make an A to make a B instead, as this would introduce an undesirable dependency between the two subsystems. We also don’t have the cycles to devote to any deep copy either, as we have to keep things lean and mean.

Besides the fundamentally disturbing fact that everyone in the room maintained, for more than two days, that one could have the best of both worlds and simply make an A, hand it off, and make a B out of it *by simple typecasting* (as in B b = (B) a), the implications on the architecture itself was completely missed.

This was solved simply by changing the semantic that a B ‘isa’ A to B ‘hasa’ A, and in fact, being a little more strict, making it a true composition. The point is, the target language was Java, and the two requirements for the design were that the first subsystem had to be as loosely bound to the second subsystem, and that we didn’t have the spare clock cycles for deep copies, etc. While other OO languages do provide mechanisms to handle this better (ObjectiveC, Smalltalk, etc.), in this case, since the implementation language was also a requirement, and not optional, its language features therefore directly impacted what we could or could not do in terms of architecture (in this case compostion instead of inheritance).

So I discovered that I have a bunch of IT managers around me … ;-]