SOLID原则

在面向对象的编程语言中，这些类是任何应用程序的构建块。如果这些块不牢固，则建筑物（即应用程序）将来将面临艰难时期。

当应用程序范围扩大，或者实现在生产或维护中遇到某些设计问题时，设计不佳的应用程序可能导致团队陷入非常困难的境地。

另一方面，一组精心设计和编写的类可以加快编码过程，同时减少技术负担和相比之下的错误数量。

在本教程中，我们将学习SOLID原则，这是5条最推荐的设计原则，在编写类时我们应牢记这些原则。

目录

什么是SOLID原则

单项责任原则

开放封闭原则

Liskov替代原则

接口隔离原则

依赖倒置原则

5个Java类设计原则

SOLID原理简介

SOLID是一组实践的首字母缩写，当一起实施时，可使代码更适应更改。鲍勃·马丁（Bob Martin）和米卡·马丁（Micah Martin）在他们的《 Clean Code(代码整洁之道)》一书中介绍了这些概念。

首字母缩略词旨在帮助我们轻松记住这些原则。这些原则也构成了我们在与其他团队成员讨论时可以使用的词汇，或者作为社区共享的技术文档的一部分。

SOLID原则构成了构建健壮，可扩展和可维护的面向对象应用程序的基本准则。

单一责任原则

我们可能会遇到一种传达类似想法的面向对象设计原则，即关注点分离（SoC）。SRP的名称说明了一切：“一个类应该只有一个职责”换句话说，我们应该仅出于一个目的编写，更改和维护类。一个类就像一个容器。我们可以向其中添加任意数量的数据，字段和方法。但是，如果我们试图通过一个单一的类添加太多功能，那么该类很快就会变得庞大。如果我们遵循SRP，则各类将变得紧凑而整洁，每个类负责单个问题、任务或职责。

例如，如果给定的类是模型类，则它应严格只代表应用程序中的一个参与者/实体。这种设计决策将使我们能够灵活地在类中进行更改，而不必担心将来其他类的更改所带来的影响。

同样，如果我们正在编写服务/管理器类，则该类应仅包含方法的那一部分，而不能包含其他任何内容。服务类甚至不应包含与模块相关的实用程序全局功能。

最好将全局函数分隔在另一个可全局访问的类中。这将有助于维护用于特定目的的类，并且我们可以决定类对特定模块的可见性。

例子：

在所有流行的Java库中，我们都可以找到很多遵循单一职责原则的类。例如，在Log4j2中，我们有不同的类带有日志记录方法，不同的类是日志记录级别，依此类推。

在我们的应用程序级代码中，我们定义了模型类来表示实时实体，例如Person，Employee，Account等。这些类中的大多数都是SRP原理的示例，因为当我们需要更改人员的状态时，才需要修改Person类，依此类推。

在给定的示例中，我们有两个类Person和Account。两者都负有存储其特定信息的单一责任。如果要更改Person的状态，则无需修改类Account，反之亦然。

public class Person { private Long personId; private String firstName; private String lastName; private String age; private List<Account> accounts; } public class Account { private Long guid; private String accountNumber; private String accountName; private String status; private String type; }

 

开闭原则

OCP是设计应用程序时应牢记的第二个原则。它指出：“软件组件应对扩展是开放的，但对修改是关闭的”，这意味着应按以下方式设计应用程序类：每当开发人员想要更改应用程序中特定条件下的控制流时，他们只需扩展类并覆盖某些功能即可。

如果其他开发人员由于类所施加的约束而无法编写所需的行为，则应重新考虑重构类。

在这里并不是要说任何人都可以改变类的整体逻辑，但是应该可以以软件允许的无害方式来覆盖软件提供的选项。

例子：

如果我们研究如struts或spring之类的任何良好框架，我们将看到我们无法更改其核心逻辑和请求处理，但仅通过扩展某些类并将其配置文件中即可修改所需的应用程序。

例如，spring框架具有类DispatcherServlet。此类充当基于String的Web应用程序的前端控制器。要使用此类，我们不需要修改此类。我们所需要做的就是传递初始化参数，然后我们可以按需要扩展其功能。

请注意，除了在应用程序启动期间传递初始化参数之外，我们还可以重写方法，以通过扩展类来修改目标类的行为。例如，扩展了Struts Action类以覆盖请求处理逻辑。

public class HelloWorldAction extends Action { @Override public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception {     // 处理请求     } }

里斯科夫的替代原则

LSP是先前讨论的开放式封闭原则的变体。它说：“派生类型必须完全可以替代其基本类型”，

LSP意味着这些类（通过扩展我们的类而创建的其他开发人员）应该能够毫无障碍的适合应用程序。当我们通过继承来实现多态行为时，这一点很重要。

这要求子类的对象的行为与超类的对象相同。在我们进行运行时类型识别然后将其转换为适当的引用类型的地方，通常会看到这种情况。

例子：

LSP的一个示例可以是Spring框架中的自定义Property编辑器。Spring提供了属性编辑器以不同于对象本身的方式表示属性，例如，解析来自HTTP请求参数的人类可读输入，或在视图层（例如Currency或）中显示Java对象的人类可读值URL。

Spring可以为一种数据类型注册一个Property编辑器，并且需要遵循基类所规定的约束PropertyEditorSupport。因此，如果任何类扩展了PropertyEditorSupport类，则可以在需要基类的任何地方替换它。

例如，每本书都有一个ISBN号，该号始终采用固定的显示格式。您可以在数据库和UI中使用独立的ISBN表示形式。为此，我们可以用以下方式编写Property编辑器–

import java.beans.PropertyEditorSupport; import org.springframework.util.StringUtils; import com.howtodoinjava.app.model.Isbn;   public class IsbnEditor extends PropertyEditorSupport { @Override public void setAsText(String text) throws IllegalArgumentException { if (StringUtils.hasText(text)) { setValue(new Isbn(text.trim())); } else { setValue(null); } }   @Override public String getAsText() { Isbn isbn = (Isbn) getValue(); if (isbn != null) { return isbn.getIsbn(); } else { return ""; } } }

 

接口隔离原理

这是我最喜欢的原则。ISP适用于接口，因为单一职责原则适用于类。ISP说：“不应强迫客户实施不必要的不必要的方法”。举个例子。开发人员周三创建了一个界面，Reportable并添加了两个方法generateExcel()和generatedPdf()。现在，客户“ A”希望使用此界面，但他打算仅以PDF格式而不是excel使用报告。他将能够轻松使用该功能吗？

不。他将必须实现这两种方法，而其中的一种是软件设计人员的负担。他要么实现另一种方法，要么将其留空。这不是一个好的设计。

那么解决方案是什么？解决方案是通过破坏现有接口来创建两个接口。他们应该像PdfReportable和ExcelReportable。这将为用户提供灵活性，使其仅使用所需的功能。

例子：

查找IPS示例的最佳地方是Java AWT事件处理程序，用于处理从键盘和鼠标触发的GUI事件。对于每种事件，它都有不同的侦听器类。我们只需要编写希望处理的事件处理程序即可。没有什么是强制性的。

如下监听器，如

①　FocusListener

②　KeyListener

③　MouseMotionListener

④　MouseWheelListener

⑤　TextListener

⑥　WindowFocusListener

任何时候，我们希望处理任何事件，只需找到相应的侦听器并实现它即可。

public class MouseMotionListenerImpl implements MouseMotionListener { @Override public void mouseDragged(MouseEvent e) { // 一些代码 }   @Override public void mouseMoved(MouseEvent e) { // 一些代码 } }

依赖倒置原则

我们大多数人已经熟悉原则名称中使用的词语。DI原理说：“取决于抽象而不是具体”。换句话说。我们应该以这样一种方式设计我们的软件，即可以使用抽象层将各个模块彼此绑定在一起，从而将各个模块彼此分离。

例子：

bean configuration在Spring框架中经典使用此原理。

在spring框架中，所有模块都作为单独的组件提供，可以通过简单地将依赖项注入其他模块来一起工作。此依赖关系在XML文件中从外部进行管理。

这些单独的组件在边界上封闭得非常好，以至于我们可以像Spring一样轻松地在其他软件模块中使用它们。这已经通过依赖倒置和开放封闭原则来实现。所有模块仅公开抽象，这对于扩展功能或另一个模块中的插件很有用。

这是5类设计原则，也称为SOLID原则，它是设计应用程序类时要遵循的最佳实践。