Finding Balance In Your Object-Oriented Design Complexity

There are many areas of life where moderation is required.  Object-oriented design complexity is one of those situations.  We can create a solution that is highly granular and flexible or one that is monolithic and simple.  However, as is often the case, the best solutions find some middle ground that keeps our application flexible and limits complexity. A Balanced Object-Oriented Design Every solution is unique and has its own constraints and requirements.  Nevertheless, we have guidelines to avoid a solution that is either over-simplified or over-engineered.  They may appear obvious but are often overlooked. Isolate unique functionality - we will not get much re-use from it. Look for repeated actions or manipulations. Focus on a unit of work. Do not break down a problem that is not improved by doing so. When we walk through the steps of our solution, we should be either to easily see how to solve the related problems.  Those related problems are often a pointer to our methods and classes.  We want to break it down into easily solvable pieces and then stop.  There is no need for our object-oriented design complexity to rise to the level of micro-managing the solution. Re-use Is A Many Splendered Thing When we are thinking about code re-use and the related work to make a solution generic, there should be multiple uses.  This should be more than two occurrences or at least a vision of the code being reused many times.  That is where we gain back the extra time spent in creating a generic solution rather than brute force.  Our design should take into account that the direct and simple approach can also be the best.  We do not get points for an elegant solution in most cases. Simple First The best designs start with a simple solution.  It is easier to make our software more complex in a future iteration than simplifying it.  We also will have lower maintenance costs associated with a less complex solution.  These benefits add up and should bias us away from over-architected solutions.  Not only are there no gains inherent in a complex system, but there are also many assumed costs.  These include a slower solution, one that is harder to maintain, and a longer ramp-up time for new/additional resources.  Therefore, simple is better than complex when possible.

There are no comments yet.

Please log in to write the first comment.