面向对象的设计原则也被称为SOLID

 

创建软件应用程序是为了满足不断变化和发展的需求。一个成功的应用程序还应该提供一种简单的方法来扩展它以满足不断变化的期望。

幸运的是，我们不是第一个遇到这些问题的人。有一些问题已经被开发人员所发现并总结了解决方案。如果在设计和开发软件时应用一组面向对象的设计原则和模式，则可以避免或解决这些常见问题。

面向对象的设计原则也被称为SOLID。在设计和开发软件时可以应用这些原则，以便创建易于维护和开发的程序。SOLID最初是由Robert C.Martin所提出的，它们是敏捷软件开发过程的一部分。

SOLID原则包括单一职责原则、开闭原则、里氏替换原则、接口隔离原则和依赖倒置原则。

1.5.1 单一职责原则

单一职责原则是一种面向对象的设计原则，该原则指出软件模块应该只有一个被修改的理由。在大多数情况下，编写Java代码时都会将单一职责原则应用于类。

单一职责原则可被视为使封装工作达到最佳状态的良好实践。更改的理由是：需要修改代码。如果类需要更改的原因不止一个，那么每个类都可能引入影响其他类的更改。当这些更改单独管理但影响同一模块时，一系列更改可能会破坏与其他更改原因相关的功能。

另一方面，每个更改的职责/理由都会增加新的依赖关系，使代码不那么健壮，更难以修改。

在示例中，我们将使用数据库来持久保存对象。假设对Car类添加方法来处理增、删、改、查的数据库操作，如图1-9所示。

在这种情况下，Car不仅会封装逻辑，还会封装数据库操作（两个职责是改变的两个原因）。这将使我们的类更难维护和测试，因为代码是紧密耦合的。Car类将取决于数据库，如果将来想要更改数据库系统，我们必须更改Car代码，这可能会在Car逻辑中产生错误。

相反，更改Car逻辑可能会在数据持久性中产生错误。

解决方案是创建两个类：一个用于封装Car逻辑，另一个用于负责持久性。如图1-10所示。

 

1.5.2 开闭原则

这个原则如下：“模块、类和函数应该对扩展开放，对修改关闭。”

应用此原则将有助于我们开发复杂而稳健的软件。我们必须想象：开发的软件正在构建一个复杂的结构，一旦我们完成了它的一部分，不应该再修改它，而是应该在它的基础之上继续建设。软件开发也是一样的。一旦我们开发并测试了一个模块，如果想要改变它，不仅要测试正在改变的功能，还要测试它负责的整个功能。这涉及许多额外的资源，这些资源可能从一开始就没有估算过，也会带来额外的风险。一个模块中的更改可能会影响其他模块或整体上的功能。如图1-11所示。

因此，最好的办法是尝试在完成后保持模块不变，并通过继承和多态扩展来添加新功能。开闭原则是最重要的设计原则之一，是大多数设计模式的基础。

 

1.5.3 里氏替换原则

Barbara Liskov指出，派生类型必须完全可替代其基类型。里氏替换原则（LSP）与子类型多态密切相关。基于面向对象语言中的子类型多态，派生对象可以用其父类型替换。例如，如果有一个Car对象，它可以在代码中用作Vehicle。

里氏替换原则声明，在设计模块和类时，必须确保派生类型从行为的角度来看是可替代的。当派生类型被其父类型替换时，其余代码就像它是子类型那样使用它。从这个角度来看，派生类型应该像其父类型那样表现，不应该破坏它的行为。这称为强行为子类型。

为了理解LSP，我们举一个违反原则的例子。在开发汽车服务软件时，我们发现需要对以下场景进行建模。当留下汽车需要服务时，车主离开汽车。服务助理拿走钥匙，当车主离开时，服务助理检查他是否有正确的钥匙以及是否发现了正确的车。他只是去解锁并锁上车，然后将钥匙放在指定的地方并留一张便条，这样机械师就可以在检查汽车时轻易找到钥匙。

我们已经定义了一个Car类，现在创建一个Key类并在汽车类中添加两个方法：lock和unlock。我们添加了一个相应的方法，助理检查钥匙是否匹配汽车：

 

在开发软件时，我们想到了有时通过汽车服务修理巴吉赛车（译者注：一种没有门的沙漠赛车，使用后轮驱动）。由于巴吉赛车是四轮车，我们创造了一个继承自Car的Buggy类。如图1-13所示。

巴吉赛车没有门，因此无法锁定或解锁。我们相应地实现了代码：

我们设计的软件要用于汽车，无论它们是否是巴吉赛车，所以将来可以将它扩展到其他类型的汽车。汽车能被锁定或解锁可能会产生一些问题。

 

1.5.4 接口隔离原则

 

下面这句话从链接https://www.oodesign.com/interface-segregation-principle.html得来：“客户端不应该依赖于它所不需要的接口。”

实际应用中，接口隔离原则（Interface Segregation Principle，ISP）减少了代码耦合，使软件更健壮，更易于维护和扩展。接口隔离原则最初是由Robert Martin提出的，他意识到如果接口隔离原则被破坏，客户端被迫依赖它们不使用的接口时，代码就会变得紧密耦合，几乎不可能为其添加新功能。

为了更好地理解这一点，我们再次采用汽车服务示例（参见图1-14）。现在我们需要实现一个名为Mechanic（机修工）的类。机修工修理汽车，所以我们增加了修理汽车的方法。在这个例子中，Mechanic类依赖于ICar类，但是，Car类提供的方法超出了Mechanic需要的。

这是一个糟糕的设计，因为如果我们想把汽车替换为另一辆汽车，需要在Mechanic类中进行更改，这违反了开闭原则。换个思路，我们可以创建一个仅公开Mechanic类所需的相关方法的接口。如图1-15所示。

 

1.5.5 依赖倒置原则

“高级模块不应该依赖低级模块，两者都应该依赖抽象。”

“抽象不应该依赖于细节，细节应该依赖于抽象。”

为了理解这个原理，我们必须解释耦合和解耦的重要概念。耦合是指软件系统的模块彼此依赖的程度。依赖度越低，维护和扩展系统就越容易。有不同的方法来解耦系统的组件。其中一个办法是将高级逻辑与低级模块分开，如图1-16所示。这样做时，可以尝试让它们都依赖于抽象进而减少二者之间的依赖关系。如此就可以替换或扩展其中任何一个模块而不影响其他模块。

 

1.6 总结

在本章中，我们介绍了Java中使用的主要编程范式。我们学习了两种不同的范式（例如命令式编程和函数式编程）可以在同一种语言中共存，也学习了Java如何从纯粹的、命令式的面向对象编程转变为集成函数式编程元素的。

虽然Java从版本8开始引入了新的函数式编程元素，但它的核心仍然是面向对象的语言。为了编写易于扩展和维护的可靠且健壮的代码，我们学习了面向对象编程语言的基本原则。

开发软件的一个重要部分是设计程序组件的结构和所需行为。通过这种方式，我们可以在大型系统、大型团队中工作，在团队内部或团队之间共享面向对象的设计。为了能够做到这一点，我们强调了与面向对象设计和编程相关的主要UML图和概念。我们还在本书中广泛使用UML来描述这些示例。在介绍了类关系并展示如何在图中表示它们之后，我们进入下一部分，在那里我们描述了面向对象的设计模式和原理，提出了主要原则。在下一章中，我们将继续介绍处理对象创建的设计模式，这种模式使代码具有健壮性和扩展性。