设计原则之多用组合少用继承

一.为什么不推荐使用继承

不推荐过度使用继承的原因有以下几点：

紧耦合：继承可能导致紧耦合，子类与父类紧密相关，一旦父类发生变化，子类可能也会受到影响。这增加了代码的维护成本和难度。
破坏封装：子类可以访问父类的所有属性和方法，包括那些本应该被隐藏的。这违反了面向对象设计的封装原则，使得代码更难以理解和维护。
继承层次过深：如果继承层次过深，会导致代码的复杂性增加，理解和维护起来都更困难。过深的继承层次也可能意味着代码违反了单一职责原则。
灵活性差：继承是固定的，一旦确定了一个类继承自另一个类，那么这种关系就不能改变。这使得代码在面对变化时缺乏灵活性。
不利于代码复用：虽然继承是一种实现代码复用的方式，但过度使用继承可能会导致代码的复用性下降。有时候，使用组合（composition）或者接口（interface）等其他方式可能更能有效地实现代码复用。

因此，在面向对象的设计中，通常推荐使用组合和接口来实现代码的复用和扩展性，而不是过度依赖继承。当然，这并不是说继承没有用处，而是在使用时需要谨慎考虑，避免滥用。

以下是一个Java中使用继承的例子，这个例子将展示继承可能导致的一些问题，从而解释为什么不推荐过度使用继承。

假设我们有一个Animal类，它有一个makeSound方法：

public class Animal {  
    public void makeSound() {  
        System.out.println("The animal makes a sound");  
    }  
}

然后我们有一个Dog类，它继承自Animal类：

public class Dog extends Animal {  
    // Dog specific behavior  
    public void bark() {  
        System.out.println("The dog barks");  
    }  
}

在这个例子中，Dog类继承了Animal类，因此它可以使用makeSound方法。然而，这里存在几个潜在问题：

紧耦合：如果Animal类的makeSound方法改变了（比如方法签名、返回类型或行为），那么所有继承自Animal的类（如Dog）都可能受到影响。
破坏封装：Dog类可以访问和调用Animal类的所有protected和public方法和字段，即使这些方法和字段在Animal的上下文中并不适合Dog。
扩展性问题：假设我们想要添加另一种动物，比如Cat，它应该发出不同的声音。我们可能需要在Animal类中添加新的逻辑来处理不同动物的声音的差异，这违反了单一职责原则，并使Animal类变得更加复杂。
灵活性差：如果以后我们想要改变Dog的声音生成方式，但因为继承的关系，我们可能不得不修改Animal类或者创建另一个子类来覆盖makeSound方法，这限制了代码的灵活性。

一个更好的设计可能是使用接口和组合来实现类似的功能：

public interface SoundMaker {  
    void makeSound();  
}  
  
public class Animal {  
    // Animal specific behavior, no sound making here  
}  
  
public class Dog extends Animal implements SoundMaker {  
    private final SoundMaker soundMaker;  
  
    public Dog(SoundMaker soundMaker) {  
        this.soundMaker = soundMaker;  
    }  
  
    @Override  
    public void makeSound() {  
        soundMaker.makeSound();  
    }  
  
    public void bark() {  
        System.out.println("The dog barks");  
    }  
}  
  
public class DogSound implements SoundMaker {  
    @Override  
    public void makeSound() {  
        System.out.println("Woof woof");  
    }  
}

在这个改进的设计中，Dog类实现了一个SoundMaker接口，并使用组合的方式持有一个SoundMaker对象。这样，我们可以轻松地为Dog类更换声音生成器，只需传入不同的SoundMaker实现即可。这种设计提供了更好的解耦和灵活性，使得代码更易于维护和扩展。

二、组合相比继承有哪些优势

组合相比继承在面向对象编程中具有一些显著的优势，这些优势使得组合在很多情况下成为更优选的设计原则。以下是组合相比继承的主要优势：

代码复用：虽然继承是实现代码复用的一种机制，但组合提供了更加灵活和强大的复用能力。通过组合，你可以将现有的对象作为新对象的成员，从而复用这些对象的功能。这种复用方式更加灵活，因为它允许你在运行时动态地改变对象的行为。
松耦合：组合通常导致更松散的耦合关系，因为对象之间是通过组合关系而不是继承关系连接在一起的。这意味着一个对象的改变不会直接影响到其他对象，这提高了代码的可维护性和可扩展性。相比之下，继承可能会导致紧密的耦合关系，因为子类会继承父类的所有方法和属性，任何对父类的更改都可能影响到子类。
多态性：组合可以更好地支持多态性。通过组合，你可以将不同类型的对象组合在一起，并在运行时根据需要动态地替换这些对象。这使得代码更加灵活和可扩展。而继承虽然也支持多态性，但通常是通过子类重写父类的方法来实现的，这在某些情况下可能会受到限制。
封装性：组合可以更好地支持封装性。通过将对象作为其他对象的成员进行封装，可以隐藏对象的内部实现细节，只暴露必要的接口给外部使用。这有助于保护对象的状态和行为，防止外部代码直接访问和修改对象的内部数据。相比之下，继承可能会破坏封装性，因为子类可以访问和修改父类的所有属性和方法。
灵活性：组合提供了更大的灵活性。在运行时，你可以根据需要添加、删除或替换组合中的对象，从而改变系统的行为。这种动态性使得系统更加适应变化的需求。而继承通常在编译时确定类的关系，因此在面对变化时可能不够灵活。

综上所述，组合相比继承在代码复用、松耦合、多态性、封装性和灵活性等方面具有显著的优势。当然，这并不意味着你应该完全放弃继承，而是在具体的设计决策中根据需求和上下文来选择使用组合还是继承。在很多情况下，将组合和继承结合起来使用可能会获得更好的效果。

三、如何判断该用组合还是继承

在面向对象编程中，判断该使用组合还是继承是一个重要的设计决策。以下是一些指导原则，可以帮助你做出正确的选择：

1. 考虑“Is-A”与“Has-A”关系：

Is-A（继承）：如果子类确实是父类的一种特殊类型，即子类与父类之间存在一种“是一个”的关系，那么使用继承是合适的。例如，Dog 是一个 Animal，所以 Dog 类可以继承自 Animal 类。
Has-A（组合）：如果一个类包含另一个类的对象作为它的成员，即存在一种“有一个”的关系，那么使用组合是更合适的。例如，Car 类有一个 Engine 对象，所以 Car 类应该包含一个 Engine 类型的成员变量。

2. 考虑代码复用：

继承：如果你想要复用父类的行为，并且这些行为对于子类来说是核心且不变的，那么继承可能是个好选择。
组合：如果你想要复用某个对象的功能，而不是整个类的行为，或者这些功能在不同的上下文中可以有不同的实现，那么组合更合适。

3. 考虑封装与隐藏：

继承：继承可能会破坏封装，因为子类可以访问父类的所有属性和方法。这可能导致子类意外地修改父类的状态或行为。
组合：组合允许你更好地控制对成员对象的访问，只暴露必要的接口给外部使用，从而保护成员对象的内部实现细节。

4. 考虑灵活性：

继承：继承是静态的，一旦确定了类的继承关系，在运行时就不能改变。这可能导致代码在面对变化时不够灵活。
组合：组合是动态的，你可以在运行时更改对象的组合方式，从而改变系统的行为。这使得代码更加灵活和可扩展。

5. 考虑多态性：

继承：继承支持多态性，但通常是通过子类重写父类的方法来实现的。
组合：组合也可以与接口和多态性结合使用，允许你将不同类型的对象组合在一起，并在运行时根据需要动态地替换这些对象。

综上所述，在选择使用组合还是继承时，你应该综合考虑类的关系、代码复用需求、封装与隐藏需求、灵活性需求以及多态性需求。在某些情况下，可能还需要结合使用继承和组合来实现最佳的设计。记住，设计决策应该是基于具体的需求和上下文，而不是盲目地遵循某种规则或模式。

思考个实际问题

MVC模式中Entity、BO、VO中大量重复的代码，我们该怎么处理呢

在MVC（Model-View-Controller）模式中，Entity（实体）、BO（业务对象）和VO（值对象）之间的代码重复确实是一个常见的问题。这些对象通常用于在不同的层次和组件之间传递数据，但由于它们各自的目的和上下文不同，常常导致代码重复。为了解决这个问题，可以考虑以下几种策略：

使用DTO（Data Transfer Object）模式：
DTO是一种用于在不同层之间传输数据的对象。你可以创建一个通用的DTO层，其中包含与Entity、BO和VO共享的属性。然后，每个层都可以使用适当的映射工具（如MyBatis、Hibernate的DTO映射功能，或手动的BeanUtils等）将这些DTO转换为特定的对象类型。
使用构建者模式：
当对象具有大量相似但不完全相同的属性时，可以使用构建者模式来减少重复代码。你可以创建一个构建器类，该类负责构建Entity、BO和VO对象，并根据需要设置不同的属性。这样，你可以避免在每个对象的构造函数中重复相同的属性设置逻辑。
使用继承和多态：
如果Entity、BO和VO之间存在明显的继承关系，可以考虑使用继承来减少重复代码。例如，你可以创建一个基类，其中包含共享的属性和方法，然后让Entity、BO和VO继承自这个基类。但是，请注意不要过度使用继承，以免导致代码结构变得复杂和难以维护。
使用代码生成工具：
有些工具可以根据数据库表结构自动生成Entity、BO和VO的代码。这可以大大减少手动编写重复代码的工作量。但是，生成的代码可能需要进行一些调整才能满足特定的业务需求。
使用ORM框架：
ORM（对象关系映射）框架如Hibernate、MyBatis等可以帮助你自动处理Entity与数据库表之间的映射关系，从而减少手动编写Entity相关代码的需求。这些框架通常也提供了将Entity转换为其他对象类型的功能。
重构和提炼：
对现有的代码进行重构，提炼出重复的代码片段并将其放入单独的类或方法中。这样可以使代码更加清晰和易于维护。同时，关注代码的可读性和可维护性，避免过度优化和复杂化代码结构。