o(ther)l/log

An interesting interview on Artima (as always), with Erich Gamma. Why framework design is (really) hard, why the OOP promises of the past were often over-hyped (in a nutshell: inheritance is not reuse). Interesting distinction between three different levels of 'reuse'. Lowest level is basically library level, design patterns are middle level - describing class interrelations. Highest level is the framework layer, where you want to "distill design" through "key abstraction".

It's notable that when he explains this, the discussion of the 'hollywood principle' and hook-and-subclass (what I often call the "framework dual nature - both mould and conductor') seems to come as a consequence of the reuse constraints. I must admit I was somewhat puzzled by the mix of concrete and architectural levels in these three layers.

Another interesting point is the gradual exposition of API and that new API should be driven by existing client needs, or even better with existing replicated code. API design is hard. API design coming from hypothetic needs is harder -and- high-risk. The conclusion is also worthwhile: don't try to have everything in a big framework, build several smaller frameworks instead. I tend to agree, but this often comes with a new difficulty: mixing frameworks means mixing different ways of delegating control to hooked objects, which complicates interactions. And often, complex interactions are not that explicit or formalizable in code.

Something different: some notes from a conversation with LC. At class-level, the encapsulation principle is often viewed as a way to hide data and internals, but it should also be viewed as a way to encapsulate and control life-cycle for an instance. Data/behavior and dynamics equally important in encapsulation?