 |
| Transaction script cost escalation |
- Hamstrung team - The original developers may have moved on, development beyond the first release may have been transferred to a less capable team or handover may have been ineffective.
- Poor codebase - Test quality and coverage may be lacking, encapsulation may be broken, or the build may be inordinately long.
For a typical business app, everything else remaining constant, good encapsulation will lead to constant or decreasing delta effort for delta functionality. The point of object orientation is that it is meant to help manage complexity of the business domain. This can only happen when we encapsulate along the grain2 of the domain.
1:http://martinfowler.com/eaaCatalog/transactionScript.html
2:Cutting with the grain: the rhythms of design - Kent Beck
3 comments:
I suspect lack of encapsulation may only be one of many possible explanations. I've often found the Open Closed Principle a better conceptual model especially when figuring out the nature of the grain one is building into the application. The notion of a strategic closure actually helps the designer build in the right nature of grain.
There are many many scenarios where the brittleness you refer to doesn't stem from lack of encapsulation. Some applications often have a simple and stable data model, where encapsulation may not even be required (eg. I suspect Google map/reduce algorithms for search indexing). Many others might just be very compute intensive algorithmic code, where switchable algorithms are important (eg. a technical charting helper application). Assuming you refer to the conventional meaning of encapsulation which refers not just to data structuring and decomposition but also to data/information hiding, there's a lot of OO Python code which uses public member variables, and there's probably a fairly decent subset of it which is quite maintainable.
To quickly summarise : Causes of brittleness could often be related to but then could as often be not related to encapsulation. A better option is to always apply the open closed principle, and then the dependency inversion principle after studying the decision tree to be able to work out the appropriate grain within the given context.
@dhananjay
You make an interesting point. Makes sense in the scenarios you describe. To me, OPC mostly addresses pluggability. Encapsulation in the small is also important e.g. avoiding primitive obsession, following tell don't ask, using first class collections. As for identifying the appropriate grain, I like iterative domain modeling sessions as described by Eric Evans in his book.
Btw, I very much enjoyed your posts on functional python. I eagerly await the next installment on itertools :)
YMMV, but IMHO algorithmic problems and (reasonably) side-effect-free processes (ala MapReduce) rarely lend themselves to OO solutions, at least not very good ones. I'm sure Sriram will agree we went down that very path and burned our fingers on the project we shared at TW.
That said, in my thought process, OCP plays right into Encapsulation and I find it a little hard to explain one without the other.
Dependency Injection takes a little getting used to. It's also a little hard to get what side is up. For instance, lately I've been tackling some iPhone/iPad apps and development here tends to progress down from the views. Not a terribly wrong practice, especially given the fact that a lot of these apps tend to be interaction rich. But this approach seems to result in some butt-ugly code with view-controllers sharing state with other view-controllers! I'm reminded of my VB6 and SQLWindows days... :S
Oh! And before I forget, I'll second @sriram's point about your python blogs- cool stuff! ;)
Post a Comment
Note: Only a member of this blog may post a comment.