问题
I have very long class inheritance hierarchy. For example:
-MyAbstractObject
--MyAbstractUiObject
---MyAbstractTable
-----MyAbstractPageableTable
-------MyAbstractScrollableTable
---------MyAbstractStateblaTable
etc...
I read at Code complete
that ideal inheritance deep is 3. And sometimes it allowable to make inheritance deep 7-9. But I have inheritance deep 11!
How I can change my architecture? What design pattern is applicable to my case? And what is bad is that I can change places of MyAbstractPageableTable
and MyAbstractScrollableTable
in inheritance hierarchy. This 2 classes not mixed into one because my goal is single responsibility. Also I want to provide for users different interfaces (APIs)
回答1:
Often it is better to use a Strategy-Pattern and not create an Subclass for each use case. But it is hard to give any hard advice because it depends on the circumstances.
In your example I would guess you could do a Table Implementation and give it an strategy-object that handles for example the Pagenation or any other display strategy the table should support.
According to Joshua Bloch's "Effective Java" it is often better to use composition over inheritence. I don't think larger inheritence depths are bad, as long as they stay understandable, with 11 levels I would guess thats not the case.
回答2:
Composition. You get two smaller inheritance hierarchies:
class MyAbstractObject
class MyAbstractUIObject : MyAbstractObject
class MyAbstractTable : MyAbstractUIObject
interface IMyAbstractTableBehaviour { void Perform(); }
class MyAbstractTablePageableBehaviour : IMyAbstractTableBehaviour
class MyAbstractTableScrollableBehaviour : IMyAbstractTableBehaviour
class MyAbstractTableStateableBehaviour : IMyAbstractTableBehaviour
You can instantiate a subclass of MyAbstractTable
with any combination of the three behaviours, and implementing additional behaviours is trivial.
回答3:
I don't know what code complete is but the ideal inheritance is probably just a signal in the right direction (guidance), it doesn't apply to every situation (maybe your case is one of them). The inheritance hierarchy for UI controls usually has this phenomenon such as Controls in WPF (Windows Presentation Foundation). So if you're building a UI framework you may encounter this. It Depends on the Context (Your Specific Situation), but overall inheritance increase coupling in your code and as @Casey said you should favor Composition if that is possible.
回答4:
Without more details in the question, it's hard to give a specific answer.
With UI frameworks (which your class seems to be a part of) you do tend to have deeper than average inheritance hierarchies. The classes at the top tend to deal with layout and such, so you get several deep before you get to add your rendering and custom behavior classes.
But, are there any classes that you could change? For instance, does it really make sense for ScrollableTable to derive from PageableTable, or could you make interfaces IScrollableTable and IPageableTable?
来源:https://stackoverflow.com/questions/17193132/long-inheritance-hierarchy