面向对象编程中的6大设计原则

Posted 2023-05-27 AI大胜

面相对象编程中，参考以下编码原则，可以帮助提升程序的可维护性、可扩展性、可复用性。这些原则也是设计模式的基础。

单一职责原则

There should never be more than one reason for a class to change

定义：应该有且仅有一个原因引起类的变化。

该原则适用于类、接口，同时也适用于方法，一个方法要尽可能的只做一件事。

这个原则的要点是每个类在理想情况下，应该围绕一个核心任务构建。本质上不是简化，而是通过暴露数量非常有限的责任，使这个类与系统的交集更小，这样一来，当需求改变的时候，需要编辑这个类的可能性就会更小了。

有大佬建议在实际项目中，接口一定要做到单一职责原则，类的设计尽量做到只有一个原因引起变化。

开放/封闭原则

该原则认为模块应该对扩展开放，但对修改封闭。

对扩展开放基本上意味着现有的类应该是可扩展的。可以用作构建其他相关功能的基础，但在实现其他相关功能时，你不应该修改现有代码，因而是对修改封闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。

该原则鼓励使用组合、接口、和泛型等编程机制生成在不修改源代码的情况下，可以扩展的类。

里氏替换原则

定义：只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常。

里氏替换原则（LSP）为良好的继承定义了一个规范，包含以下几个含义：

1. 子类必须完全实现父类的方法。（父类是抽象类或接口，父类的方法是指父类中未显式实现的方法）
   另外注意，在类中调用其他类时，务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则
2. 重写（override）或实现父类方法时，输入参数可以被放大。（输入参数范围大于父类该方法中的参数范围，这样才能LSP，这很明显）
3. 重写（override）或实现父类方法时，返回值即输出结果可以被缩小。

里氏替换原则的本质是派生类不能限制基类执行的条件。简而言之，派生类需要的不能比父类多，提供的不能比父类少。

依赖倒置原则

定义：该原则认为高级模块不应该依赖于低层模块，二者都应该依赖于抽象。

在项目中，大家只要记住是“面向接口编程”就基本上抓住了依赖倒置原则的核心。这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

具体处理依赖的模式有两种：依赖注入、服务定位器。

依赖注入通常有构造函数注入、属性注入、方法注入这三种，我们一般通过构造函数注入，因为这样可以从一开始就清楚表明一个类有什么依赖。依赖注入通常需要特定的生产力工具，也被称为ioc容器。

服务定位器模式：

在使用形式上类似下面这样：

void Copy()
 
 Byte  byte;
 var reader = ServiceLocator.GetService<IReader>();
 var writer = ServiceLocator.GetService<IWriter>();
 while (byte=reader.Read())
 
     writer.Write(byte);
 

通常的做法是把服务定位器创建成一个类，暴露少数静态工厂方法，类似下面这样：

public class ServiceLocator

 public object GetService(Type typeToResolve)  ……
 public T GetService<T>( )  ……
 public object GetService(string typeNickName)  ……

这个模式的缺点是需要你深入代码才能弄清如何处理依赖。另外最适合他的场景是，当你要为很难通过其他方式重新设计的某个大型遗留代码添加扩展时。在多数情况下，服务定位器被看做反模式。理由是你的代码最终会遍布服务定位器类的引用。更糟糕的情况是直到运行时，你才会发现错误。

接口隔离原则

该原则认为不应该强制客户（调用方）依赖于他们不用的接口。

正确实施这个原则，意味着把接口分解成多组函数。以便每个客户更容易匹配他真正感兴趣的那组函数。

未能充分遵守接口分立原则会导致实现很复杂以及很多方法根本没有实现。此外，客户被迫依赖于他们不用的接口，而且这些客户还受制于这种接口的改变。

迪米特法则

又称最少知道原则，是指：一个实体应当尽量少地与其他实体之间发生相互作用，以使得系统功能模块相对独立。

---

更新于：2923.5.27

面向对象编程的软件设计原则

         在開始Android软件实际APP開始之前，我们须要对面向对象设计原则及设计模式做一个初步的了解。才干在以后的实战过程中，少走弯路。使我们的软件开发生涯感觉到快乐、轻松。好了，废话少说，咱们今天给大家一起探讨一下软OOP中的软件开发设计原则。这些东东都是OOP的设计精髓，他们蕴藏着前辈留下的产物。眼下。软件设计最基本原则有下面几种（总共同拥有11种）：单一职责原则、开放封闭原则、依赖倒置原则、接口隔离原则和里氏替换（Liskov替换）原则

       单一职责原则

        就是一个类值做一件事情。引起它发生变化的仅仅有一个。

我们常常会听到一个词语“高内聚、低耦合”。我们将职责定义为引起变化的原因。以提高内聚性来降低引起变化的原因。

若是职责越多，耦合性就会越高；我们略微哪个地方有修改，都会波及到其它的类。

       开放封闭原则

      地方详细体如今：对扩展开发、对改动关闭。

什么意思呢？对扩展开放，意味着有新的需求或变化时，能够对现有代码进行扩展。以适应新的情况；对改动封闭。意味着类一旦设计完毕。就能够独立完毕其工作，而不要对其进行不论什么尝试的改动。

       事实上，我们在实际的编程过程中，用的最多。

您想想：一般我们在设计的时候，我们会设计抽象类、接口（行为）；然后详细的实现类是通过继承的方式；我们通过覆写的方式来编写不同详细的实现类的方法；这就是此设计原则的真实写照。

      依赖倒置原则

      其核心思想是：依赖于抽象。

详细而言就是高层模块不依赖于底层模块，二者都同依赖于抽象；抽象不依赖于详细，详细依赖于抽象。当两个模块之间存在紧密的耦合关系时，最好的方法就是分离接口和实现：在依赖之间定义一个抽象的接口使得高层模块调用接口。而底层模块实现接口的定义，以此来有效控制耦合关系，达到依赖于抽象的设计目标。

抽象的稳定性决定了系统的稳定性，由于抽象是不变的，依赖于抽象是面向对象设计的精髓，也是依赖倒置原则的核心。依赖于抽象是一个通用的原则。而某些时候依赖于细节则是在所难免的，必须权衡在抽象和详细之间的取舍。方法不是一层不变的。依赖于抽象，就是对接口编程。不要对实现编程。

 

      接口隔离原则

      其核心思想是：使用多个小的专门的接口，而不要使用一个大的总接口。我们在设计接口的时候。详细而言，接口隔离原则体如今：接口应该是内聚的，应该避免“胖”接口。一个类对另外一个类的依赖应该建立在最小的接口上，不要强迫依赖不用的方法，这是一种接口污染。

    里氏替换（Liskov替换）原则

      不论什么基类能够出现的地方，子类一定能够出现。LSP是继承复用的基石。仅仅有当子类能够替换基类，软件单位的功能不受影响时，基类才干真正的被复用，而子类也能够在基类的基础上添加新的行为。Liskov替换原则，主要着眼于对抽象和多态建立在继承的基础上，因此仅仅有遵循了Liskov替换原则。才干保证继承复用是可靠地。实现的方法是面向接口编程：将公共部分抽象为基类接口或抽象类，通过Extract Abstract Class。在子类中通过覆写父类的方法实现新的方式支持相同的职责。