A lot of people are aware of what others call design smells. I hate using the term smell, so I use the term stenches, but they amount to the same thing: Something that reeks up the place somethin' fierce. I'm going to be writing a series of posts with my experiences on projects that feature plenty of malodorous designs, and show how I would have improved them and why they are better. I hope to keep these relatively short, as I tend to go too long, but if you have questions, I can answer them in follow-up posts.
From Agile Principles, Patterns, and Practices by Robert C. Martin, rigidity of design is defined as:
"Rigidity is the tendency for software to be difficult to change, even in simple ways. A design is rigid if a single change causes a cascade of subsequent changes in dependent modules. The more modules that must be changed, the more rigid the design."
From my personal experience, this happens most often when people are more worried about data than they are about functionality. For example, for a simple property bag, if you make an interface for it and make more than one implementation, what happens when you change the interface because it turns out it didn't have all the data you needed, or the datatype on one of the properties needed to change? Did you have control over all the implementors, and did you just publish an unnecessary breaking change? For this reason, I do not support having many properties on an interface - 2-3 tops, preferably none.
In any case, when you change the interface, it completely screws the app. *Every* place that uses that interface now may have to change, depending on the type of change. Does this mean we shouldn't use interfaces? No! We should only use them when they are appropriate, and ensure that they encapsulate a responsibility, rather than represent a piece of data.
To fix this, I would only put the appropriate functionality for a given class on the interface. More importantly, I try to ensure that the interface is truly stable. Without stability, interfaces are actually less useful than standard classes.
Friday, March 4, 2011
Subscribe to:
Posts (Atom)