Java中的SOLID原则及示例

本文主要是介绍Java中的SOLID原则及示例，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

类是任何Java应用程序的构建块。如果这些区块不强，那么建筑（即应用）将来将面临艰难时期。这实际上意味着，当应用程序范围上升或应用程序在生产或维护中面临某些设计问题时，不那么好的编写会导致非常困难的情况。

另一方面，一组精心设计和编写的类可以加速编码过程的突飞猛进，同时减少错误的数量。

在本教程中，我们将使用 5个最推荐的设计原则的示例来讨论Java中的SOLID原则，在编写类时我们应该记住这些原则。它们还构成了设计应用程序类时应遵循的最佳实践。

目录1.单一责任原则
2.公开封闭原则
3.利斯科夫的替代原则
4.界面隔离原则
5.依赖性倒置原则

5 java类设计原则

让我们逐一深入研究它们。

1.单一责任原则

原则的名称说明了一切：

“一个类应该只有一个责任”

换句话说，我们应该只为一个目的编写，更改和维护一个类。如果它是模型类，那么它应该严格地只代表一个参与者/实体。这将使我们能够灵活地在未来进行变更，而不必担心变更对另一个实体的影响。

类似地，如果我们正在编写服务/管理器类，那么它应该只包含方法调用的那部分而不包含任何其他内容。甚至不是与模块相关的实用程序全局函数最好将它们分隔在另一个全局可访问的类文件这将有助于为特定目的维护类，并且我们可以仅决定类对特定模块的可见性。

1.1。单一责任原则示例

我们可以在所有流行的Java库中使用单一责任原则的大量类。例如，在log4j中，我们有不同的类和日志记录方法，不同的类是日志记录级别，等等。

在我们的应用程序级代码中，我们定义模型类来表示实时实体，例如人员，员工，帐户等。这些类中的大多数都是SRP原则的示例，因为当我们需要更改人员的状态时，我们才会修改一个人的类。等等。

在给定的示例中，我们有两个类Person和Account。两者都有单一的责任来存储他们的具体信息。如果我们想要改变Person的状态，那么我们不需要修改类Account，反之亦然。

Person.java
`public` `class` `Person` `{` `private` `Long personId;` `private` `String firstName;` `private` `String lastName;` `private` `String age;` `private` `List<Account> accounts;` `}`

Account.java
`public` `class` `Account` `{` `private` `Long guid;` `private` `String accountNumber;` `private` `String accountName;` `private` `String status;` `private` `String type;` `}`

2.公开封闭原则

这是我们在设计应用程序时应该牢记的第二个重要规则。开放封闭原则：

“软件组件应该是可以扩展的，但是关闭以进行修改”

这是什么意思？？这意味着我们的类应该设计成这样一种方式，即每当开发人员想要在应用程序中的特定条件下更改控制流时，他们都需要扩展我们的类并覆盖一些函数，就是这样。

如果其他开发人员由于我们班级的限制而无法设计所需的行为，那么我们应该重新考虑改变我们的类。我并不是说任何人都可以改变我们班级的整个逻辑，但是他/她应该能够以软件允许的无害方式覆盖软件提供的选项。

2.1。打开封闭原理示例

如果我们看一下像struts或spring这样的好框架，我们会发现我们无法改变它们的核心逻辑和请求处理，但我们只是通过扩展一些类并将它们插入配置文件中来修改所需的应用程序流。

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

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

扩展Struts Action
`public` `class` `HelloWorldAction` `extends` `Action` `{` `@Override` `public` `ActionForward execute(ActionMapping mapping,` `ActionForm form,` `HttpServletRequest request,` `HttpServletResponse response)` `throws` `Exception` `{` `//Process the request` `}` `}`

3.利斯科夫的替代原则

该原理是先前讨论的开放封闭原理的变形。它说：

“派生类型必须完全可替代其基类型”

这意味着通过扩展我们的类创建的类开发人员应该能够适应应用程序而不会失败。这要求子类的对象的行为方式与超类的对象相同。这主要出现在我们进行运行时类型识别然后将其转换为适当的引用类型的地方。

3.1。Liskov替代原则示例

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

Spring可以为一种数据类型注册一个属性编辑器，并且需要遵循基类规定的约束PropertyEditorSupport。所以是任何类扩展PropertyEditorSupport类，然后它可以被所有需要的基类替代。

例如，每本书的ISBN号始终是固定的显示格式。您可以在数据库和UI中单独表示ISBN。对于这个要求，我们可以用这样的方式编写属性编辑器 -

IsbnEditor.java
`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` `"";` `}` `}` `}`

4.接口隔离原理

这个原则是我最喜欢的。它适用于接口，因为单一责任原则适用于类。ISP说：

“客户不应该被迫实施他们不会使用的不必要的方法”

举个例子。开发者亚历克斯建立的接口Reportable并添加两个方法generateExcel()和generatedPdf()。现在客户'A'想要使用这个界面，但他打算只使用PDF格式的报告，而不是excel。他能否轻松使用这项功能？

没有。他将不得不实施这两种方法，其中一种方法是软件设计者给他带来的额外负担。他要么实施另一种方法，要么留空。这不是一个好的设计。

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

4.1。接口隔离原理示例

查找IPS示例的最佳位置是Java AWT事件处理程序，用于处理从键盘和鼠标触发的GUI事件。它为每种事件都有不同的监听器类。我们只需要为事件编写处理程序，我们希望处理。没有必要。

一些听众是 -

的FocusListener
KeyListener的
的MouseMotionListener
MouseWheelListener的
的TextListener
的WindowFocusListener

任何时候，我们都希望处理任何事件，只需找出相应的监听器并实现它。

MouseMotionListenerImpl.java
`public` `class` `MouseMotionListenerImpl` `implements` `MouseMotionListener` `{` `@Override` `public` `void` `mouseDragged(MouseEvent e) {` `//handler code` `}` `@Override` `public` `void` `mouseMoved(MouseEvent e) {` `//handler code` `}` `}`