This is Philip_schwarz's Typepad Profile.
Join Typepad and start following Philip_schwarz's activity
Join Now!
Already a member? Sign In
Recent Activity
Hey Michael, Thanks, this clarifies the following answer you posted in [1]: "It’s a funny thing about the design principles. I think that often if you take one, you get many of the others by implication. If you concentrate on SRP, you can end up with OCP without even thinking about it. I think the same is true of OCP.. If you really push it, you will end up with modules with single responsibilities..." [1] Philip
I came across similar thoughts in the following two passages from "Holub on Patterns" (2004) : #1 Template Method has little to recommend it in most situations. Strategy for example, typically provides a better alternative. Well done class libraries work "out of the box". You should be able to instantiate a framework class, and it should do something useful. Generally, the 90/10 rule applies (10 % of the functionality is used 90% of the time, so the 10 % should define the default behaviour of the class.) In template method, however, the framework often defines NO default behaviour, but rather you are required to provide subclasses to do anything useful. Given the 90/10 rule, this means you have to do unnecessary work 90% of the time. Template method does not prohibit the class designer from providing useful default functionality at the superclass level, expecting that the programmer will modify the behaviour of the superclass through derived-class overrides if necessary. In an OO system, though, using derivation to modify superclass behaviour is just run-of-the-mill programming that's hardly worth glorifying an an official pattern. #2 Template method is best used in moderation. An entire class "framework" that depends on derivation-based customization is brittle in the extreme. The base classes are just too fragile. When I was programming in MFC, I had to rewrite all my applications every time M$ released a new version. Often the code compiled just fine but didn't work anymore because some base-class method had changed. Template method is not used in any of the code I supply in this book(Holub on Patterns). It is a telling condemnation of Template Method that most of the Java-library code works pretty well out-of-the-box and that the Java libraries are more useful than MFC ever was. You can extend the Java classes if you need to customize them for an off-the-wall application, but they work just fine without modification for the vast majority of applications. This sort of out-of-the-box structure is just better than a derivation-based framework. It's easier to maintain, it's easier to use, and it doesn't put your code at risk if the vendor-supplied class changes its implementation.
In "Growing Object-Oriented Software, Guided by Tests", the authors say the following: "we find that we tend towards different programming styles at different levels in the code. Loosely speaking, we use the message-passing style we’ve just described between objects, but we tend to use a more functional style within an object, building up behavior from methods and values that have no side effects. Features without side effects mean that we can assemble our code from smaller components, minimizing the amount of risky shared state. Writing large-scale functional programs is a topic for a different book, but we find that a little immutability within the implementation of a class leads to much safer code and that, if we do a good job, the code reads well too."
In Clean Code, Jeff Langr says "We want our systems to be composed of many small classes, not a few large ones. Each small class encapsulates a single responsibility, has a single reason to change, and collaborates with a few others to achieve the desired system behaviors.". To those who fear that a large number of small, single-purpose classes makes it more difficult to understand the bigger picture, he asks: "Do you want your tools organized into toolboxes with many small drawers each containing well-defined and well-labeled components? Or do you want a few drawers that you just toss everything into?". These opposing approaches to growing one's toolbox seem to map to your two approaches to growing code: budding and festering. When we have a new tool to add to the toolbox, the fact that we know that putting the tool in a newly labelled drawer is more cost effective over time doesn’t change the perception of the cost at the time of change, so we are always tempted to just throw the new tool in an existing draw.
Philip_schwarz is now following The Typepad Team
Jun 29, 2010