为什么继承是强耦合的,因为组合在Java中松散耦合? [英] why inheritance is strongly coupled where as composition is loosely coupled in Java?

查看:1242
本文介绍了为什么继承是强耦合的,因为组合在Java中松散耦合?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在设计模式中一次又一次地听到这个赞成组合而不是继承。引用的一些原因是

I have heard this favor composition over inheritance again and again in design patterns. some of the reasons cited for this are

1)Inheritance is strongly coupled where as composition is loosely coupled
2) Inheritance is compile time determined where as composition is run-time
3)Inheritance breaks encapsulation where as composition does not
4) anything else I am not aware of

对于像我这样的初学者来说,通过插图来理解遗传和构图在上述方面的不同之处会很棒。我已经阅读了各种关于它们的SO链接,但是通过这些关键点的示例对Java初学者来说非常有用。

It would be great for beginners like to me follow these by illustrations as how inheritance and composition differs with respect to above points. I have read various SO links that talks about them, but walk through examples on these key points would be great for Java beginners.

我认为理解这一点非常重要差异显然不仅仅是记住积分。

I think it is very crucial to understand the difference clearly than just memorizing the points.

推荐答案

对于初学者来说这个问题很好,我想我应该首先提醒继承和构成,然后去解释究竟是什么赞成继承继承确实意味着。


散文和继承的缺点

Nice question and big for a beginner, I think I should first remind inheritance and composition, and then go to explain what is exactly Favor Composition over Inheritance does means.

prose and cons of inheritance :

优点:


  • 动态绑定和多态的主要好处之一是
    它们可以帮助使代码更容易更改

  • 新实现很简单,因为大多数都是继承的b $ b修改或扩展正在重复使用的实现。

缺点:


  • 打破封装ation,因为它公开了一个子类到实现

    其超类的详细信息

  • 白盒重用,因为超级类的内部细节通常是转载可见的

  • 如果
    超类的实现改变从超类继承的实现,则可能必须更改子类可以在运行时更改

  • Breaks encapsulation, since it exposes a subclass to implementation
    details of its super-class
  • White-box reuse, since internal details of super-classes are often visible to subleases.
  • Subclasses may have to be changed if the implementation of the superclass changes Implementations inherited from superclasses can not be changed at runtime.

关于问题:


继承强耦合,其中组合松散耦合

Inheritance is strongly coupled where as composition is loosely coupled

继承将带给你紧耦合,只需对基类进行一次更改即可打破许多子类。


但何时使用以及如何检测我们需要继承或组合?

仅在满足以下所有条件时才使用继承(Coad规则):

Inheritance will bring you tight coupling, simply one change to base class can break many child classes.

But when to use and how detect we need inheritance or composition?
Use inheritance only when all of the following criteria are satisfied (Coad's Rule):


  1. 子类表示是一种特殊的而不是是一种rol e由播放。

  2. 子类的实例永远不需要成为另一个类的对象

  3. 子类扩展,而不是覆盖或取消
    超级类的责任

  4. 子类不扩展仅仅是
    实用程序类的功能

  5. 对于实际问题域中的类,子类专门化
    a角色,交易或设备

  1. A subclass expresses is a special kind of and not is a role played by a.
  2. An instance of a subclass never needs to become an object of another class
  3. A subclass extends, rather than overrides or nullifies, the responsibilities of its super-class
  4. A subclass does not extend the capabilities of what is merely a utility class
  5. For a class in the actual Problem Domain, the subclass specializes a role, transaction or device




继承是编译时确定的,其中作曲是运行时

Inheritance is compile time determined where as composition is run-time

编译时,你的基础类代码将被添加到每个子类。

When compiled, your base class codes will be added to every child class.


继承打破封装,其中组合不是

Inheritance breaks encapsulation where as composition does not

是的。看看继承的劣势。

Yes .see the disadvantage of inheritance .

底线是

确保继承模型是一种关系
我的主要指导思想是只有当子类是超类时才应该使用继承。在上面的例子中,Apple可能是一个Fruit,所以我倾向于使用继承。
当你认为你有一个is-a关系时,问一个自己的一个重要问题是,这是一个关系在整个应用程序的整个生命周期中是不变的,幸运的是,代码的生命周期。例如,您可能认为Employee是一个Person,而真正的Employee代表Person在部分时间内扮演的角色。如果这个人失业怎么办?如果此人既是员工又是主管怎么办?这种无常的关系通常应该用组合来建模。

Make sure inheritance models the is-a relationship My main guiding philosophy is that inheritance should be used only when a subclass is-a superclass. In the example above, an Apple likely is-a Fruit, so I would be inclined to use inheritance. An important question to ask yourself when you think you have an is-a relationship is whether that is-a relationship will be constant throughout the lifetime of the application and, with luck, the lifecycle of the code. For example, you might think that an Employee is-a Person, when really Employee represents a role that a Person plays part of the time. What if the person becomes unemployed? What if the person is both an Employee and a Supervisor? Such impermanent is-a relationships should usually be modelled with composition.

不要仅仅为了获得代码而使用继承
如果你真正想要的只是重用代码,看不到任何关系,使用组合。

Don't use inheritance just to get code reuse If all you really want is to reuse code and there is no is-a relationship in sight, use composition.

不要仅仅为了获得多态性而使用继承
如果您真正想要的只是多态,但没有自然的is-a关系,请使用带接口的组合。


赞成组合超过继承:)

我直接从 javaworld

这篇关于为什么继承是强耦合的,因为组合在Java中松散耦合?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆