Read Notes from a In: The Blog Ride - There, but for the grace of God (and the experiences of Java) go I. Ted Neward laments the habit of building: "building abstraction layers on top of abstraction layers on top of abstraction layers, all in the name of "we might want or need to change something... someday".
The example he cites the Commons Logging facility does seem strange - but I'm not sure abstraction is a bad as he claims. I see well used layers of abstraction all the time. First we build a fine grained reusable stateless engine - where the small parts can be reassembled to make any number of systems (perhaps rules or calculation engine). Then we build an operations layer on top of it. The operations layer is responsible for gluing together several fine grained concepts into larger blocks - useful for specific actions an end user might take (like: add a business rule). That layer might also provide all the notification and statefullness that an application requires. The same idea applies to models - the GUI might require alot more information than the engine provides (color, font, etc.). So we build our models in layers - giving a us proper separation of concerns.
So Ted - I suggest that abstraction isn't as harmful as you suggest. BTW I'm currently a Java guy (having been a .NET and every other language back to Pascal) so maybe I repeating the mistakes of the other Java guys.
If you enjoyed this post, subscribe now to get free updates.
