Why Lots of Things are Considered Harmful.
I wrote earlier about common programming constructs that were "considered harmful". Interestingly enough it turns out that for many of them the solution was to loosen the coupling. In fact, someone made the observation that the progress of computer science correlates to the level of indirection in our programming constructs.
For example, for machine code you jump to a location based on its address in memory, for assembly language the jump is a name, then there came procedures which was more than a program counter change it added a stack, in the OO world the procedure call is now polymorphic and depends on the target object and the arguments of the call. So, in essence, the more levels of indirection we build the more progress we make.;-)
So, for "new considered harmful" we avoid exposing the new operator to clients, rather we decouple the request for an object from the creation of one. For "get,set considered evil" we decouple (to its extreme) any knowledge of an objects internal structure from a calling client. For "If Statement Considered Harmful" we decouple the conditional from its execution.
Curiously enough there are other computer science constructs that have been "decoupled". What's so interesting about this is that things that you may have taken for granted as being the same can acually be different. One example is the idea of continuations, continuations actually break up a procedure call, that is a continuation is a procedure call that doesn't return to its original caller! (Interesting to note, document passing style as opposed to RPC is more like continuations).
Finally, I discovered recently the decoupling of object identity, a cornerstone of OO as we kow it. Essentially its shown that object identity can be broken up into 2 parts, reference and comparison, the decoupling is shown to have real benefits.
In conclusion, as we move to developing larger systems, loose coupling then becomes more important. To achieve loose coupling we have to rexamine our current notions of programming constructs.
[::Manageability::]
Agreed. I think AOP may well hold the key to the next level of indirection and decoupling of code, keeping business logic seperate from architectural plumbing code.
