Long inheritance hierarchy

a 夏天 提交于 2020-01-16 04:49:05

问题


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

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!