| This is a relative of Parallel Inheritance Hierarchies, but everything has been folded into one hierarchy. Symptoms -
You want to introduce a single new class, but it turns out that you have to introduce multiple classes at various points of the hierarchy. -
You notice that each layer of the hierarchy uses a common set of words (e.g., one level adds style information, and the next adds mutability). Causes What should be independent decisions instead get implemented via a hierarchy. What to Do -
If things aren't too far gone, you may be able to Replace Inheritance with Delegation. (By keeping the same interface for the variants, you can create an example of the Decorator design pattern.) -
If the situation has grown too complex, you're in big refactoring territory and can Tease Apart Inheritance (see Fowler's Refactoring for the details). Payoff Reduces duplication. Reduces size. Contraindications None identified. | Exercise 43 Documents. | Consider this hierarchy: Document AsciiDocument ZippedAsciiDocument RawAsciiDocument BriefAsciiDocument HtmlDocument RawHtmlDocument ZippedHtmlDocument MarcDocument BriefMarcDocument FullMarcDocument -
What's the impact of adding a new compression type that all document types will support? -
Rearrange the hierarchy so it's based first on compression (or none), then brief/full, then document type. Is this an improvement? -
Describe a different approach, using the Decorator pattern. See Appendix A for solutions. | |