This post originated from an RSS feed registered with Java Buzz
by Carlos Perez.
Original Post: Principles of Manageable Object Oriented Software
Feed Title: .:Manageability:.
Feed URL: http://www.manageability.org/blog/stuff/rssDisabled?portal_status_message=Syndication+is+Disabled
Feed Description: Random thoughts on the manageability of complex software.
Mike Hogan put together a list of his experiences working on a 50,000 line code base, it's all pretty interesting. That made me dig up some old information about this to better grasp of the subject matter. The first ancient text comes from Robert Martin who compiled a collection of principles for Object Oriented design. These principles help guide a developer as to when and why to refactor towards better manageability:
The Open Closed Principle (OCP). A module should be open for extension but closed for modification.
The Liskov Substitution Principle (LSP). Subclasses should be substitutable for their base classes.
The Dependency Inversion Principle (DIP). Depend upon Abstractions. Do not depend upon concretions.
The Interface Segragation Principle (ISP). Many client specific interfaces are better than one general purpose interface.
The Release Reuse Equivalency Principle (REP). The granule of reuse is the granule of release.
The Common Closure Principle (CCP). Classes that change together, belong together.
The Common Resuse Principle (CRP). Classes that aren't reused together should not be grouped together.
The Acyclic Dependcies Principle (ADP). The dependencies between packages must not form cycles.
The Stable Dependencies Principle (SDP). Depend in the direction of stability.
The Stable Abstractions Principle (SAP). Stable packages should be abstract packages.
Guidelines that developers should take to heart, or at least post in your cubicle. I also went back to an older text, this on techniques for writing large scale C++ software design. The book accentuates the complexities of using C++ since many of the recommendations do come for free in Java. Here's a list of techniques that appear applicable for Java:
Escalation. Moving mutually dependent functionality higher in the physical hierarchy.
Demotion. Moving common functionality lower in the physical hierarchy.
Dumb Data. Using data that indicates a dependency on a peer object, but only in the context of a separate higher level object.
Redundancy. Deliberately avoiding reuse by repeating small amounts of code or data to avoid coupling.
Callbacks. Using client supplied functions that enable lower-leve subsystems to perform specific tasks in a more global context.
Manager Class. Establishing a class that owns and coordinates lower-level objects.
Factoring. Moving independently testable subbehaviour out of the implementation of complex components involved in excessive physical coupling.
Escalating Encapsulation. Moving the point at which implementation details are hidden from clients to a higher level in the physical hierarchy.
A bit of apologies, the above list may be a bit difficult to parse. However, I suggest everyone read the book for more detail. What's so appealing about the list is that its very pragmatic, take a look at "redundancy", its advocating cut-and-pasting your code. In certain cases this infact may be necessary. Mike Hogan writes that you shouldn't reuse libraries that you use little functionality. Well this rule says, if you don't want to be coupled to that library, cut-and-paste the code, rather that rewrite it.
Finally, for the most interesting observation, I go back to "Aspect-Oriented Dependency Inversion" which demonstrates how guided by the OO principles that code can become more manageable using Aspects. I've written about this before in the entry "Refactoring to Aspects". Most people understand the benefits of AOP to be in terms of "Functional Aspects", that is for logging, synchronization, persistence, transactions etc. However, there's a different kind of aspect, that is "Connective Aspects" whose purpose is to organize the code in a way that improves manageability. It's the same dichotomy between functionality and structure as described by Jim Coplien, but applied to AOP.
Previous Topic
