设计模式七大原则

本文详细介绍了设计模式的七大原则,包括单一职责原则、开放-封闭原则、依赖倒转原则、里氏代换原则、迪米特法则、接口隔离原则和合成复用原则。阐述了每个原则的含义、原因、应用场景和实践方法,旨在提高代码的可维护性、可扩展性和可读性。

目的

  • 高内聚、低耦合
  • 可靠性:当增加新功能后,对原来的功能没有影响
  • 可扩展性:可以在原有方法的基础上增删功能
  • 可读性:编程的规范性,利于他人阅读和理解
  • 重用性:相同功能的代码。不用 重复编写

七大原则:

单一职责原则(SPR)

what:

  • 这个由字面意思就很好理解了,顾名思义,功能要单一。
    准确的解释是:就一个类而言,应该仅有一个引起它变化的原因。

why:

  • 我们在做编程的时候,很自然给一个类加各种各样的功能,这就意味着,无论任何需求要来,都需要改这个窗体类,这样维护麻烦,不能复用,缺乏灵活性。

场景:

  • 当你看见天空有一道彩虹,特别想拍下来留作纪念,但是由于手机像素不好,拍出来的照片都不是自己想要的效果,这时候就该懊恼了,为什么手机的相机功能不能强大一点呢?就像数码相机一样,它其实就是将功能单一化,精进化了,但是也不等于智能手机职责多,就不能做好,只不过现在的科技还不能让手机在摄像时超过DV(点我啊)而已,
    彩虹

how:

  • 所以我们在编程时,要在类的职责分离上多思考,做到单一职责,这样你的代码才是真正的易维护,易扩展,易复用,灵活多样,

开放-封闭原则

what:

  • 开放-封闭原则,对什么开放?对什么封闭呢?
    这个原则其实是有两个特征,一个是说“对于扩展是开放的(open for extention)“,另一个是说”对于更改是封闭的(colsed for modification)”。

why:

  • 设计软件要容易维护又不容易出问题的最好的办法,就是多扩展,少修改。
    我们在做任何系统的时候,都不要指望一开始需求确定了,就永不再变,这是不科学也是不现实的想法。既然需求一定会变化,那么在设计软件时可以相对容易修改。不至于说,新需求一来,就推到整个程序。那么怎样设计才能面对需求的改变却可以保持相对稳定,从而使得系统可以在第一个版本以后不断推出新的版本呢?这就是开放-封闭原则带给我们的答案。

场景:

  • 如:一国两制。这是中国政治上一个伟大的提议。开放的是两制,封闭的是一国。国不可分割,制度可分制。
    一国两制

真希望学校也能充分的用好这种开放-封闭原则啊,那就是:学生只要可以在最后考试中及格,就可以不强制去上课,哈哈。不变的是最后结果,变的是学习过程。真是一举数得啊~

how:

  • 全力以赴是必须,两手准备也是灵活的体现。就是在追求事物的时候,坚持一面不变,同时也要在其他方向做出努力!这种原则也同样使用于生活。

依赖倒转原则(DIP)

what:

  1. 高层模块不应该依赖于底层模块,两个都应该依赖抽象。
  2. 抽象不应该依赖细节,细节应该依赖于抽象。

说白了,就是针对接口编程,不要对实现编程。

why:

  • 如果我们将高层模块依赖了低层模块,那么想再次利用高层模块时,就没有办法复用了,因为高层模块是与低层模块的访问数据库绑在一起的。如果都依赖与抽象,也就是接口或抽象类,那么只要接口是稳定的,更改任何一个模块都不会造成影响,

场景:

  • PC里如果CPU, 内存,硬盘都需要依赖具体的主板,那么主板一坏,所有的部件都不能用了,这显然不合理。反过来,如果内存坏了,也不应该造成其他部件不能用。

  • 还有就像我们的手机一样,如果你的手机只能用原装的一个充电器,是不是当你的充电器坏了的时候,你的手机就再也不能用了。那岂不是有很大的损失?所以只要咱们的手机充电接口不坏,就可以换成任何一个匹配的充电器。

how:

  • 依赖倒转可以说是面向对象设计的标志了,用哪种语言来编写程序不重要,如果编写时考虑的都是如何针对抽象编程而不是针对细节编程,即程序中所有的依赖关系都是终止于抽象类或者接口,那就升级面向对象的设计,反之则是过程化的设计了。

### 设计模式七大原则详解 #### 单一职责原则 (SRP) 单一职责原则指出一个类应该只有一个引起它变化的原因。如果一个类承担了过多的责任,则会增加其复杂度,降低系统的稳定性。因此,在设计时应确保每个类只负责一项功能[^1]。 ```java // 正确做法:分离不同职责到不同的类中 class User { private String name; public void setName(String newName){ this.name = newName; } } ``` #### 开闭原则 (OCP) 开闭原则强调软件实体应对扩展开放而对修改关闭。这意味着可以通过添加新代码的方式使系统行为发生改变而不必改动现有源码。利用接口或抽象基类可以很好地支持这一特性[^3]。 ```csharp public interface IShape{ double GetArea(); } public class Circle : IShape{/*...*/} public class Rectangle : IShape{/*...*/} // 新增形状无需更改原有逻辑 List<IShape> shapes = new List<IShape>(); shapes.Add(new Circle()); shapes.Add(new Rectangle()); foreach(var shape in shapes){ Console.WriteLine(shape.GetArea()); } ``` #### 里氏替换原则 (LSP) 该原则规定子类型必须能够完全替代它们的父类型。任何原本使用基类对象的地方都可以直接替换成派生类的对象而不影响程序正确性。这有助于提高继承结构的安全性和灵活性[^2]。 ```cpp class Bird { virtual void fly()=0; }; class Sparrow : public Bird {/* 实现fly方法 */}; class Ostrich : public Bird {/* 不实现fly,违背此原则 */} ``` #### 接口隔离原则 (ISP) 接口隔离原则提倡客户端不应该依赖于那些他们不使用的接口;多个特定客户专用的小接口优于一个通用的大接口。这样做可以让各个组件之间的耦合更加松散,便于后期维护和升级。 ```typescript interface IPrinterOperations { print():void; } interface IFaxOperations { sendFax(faxData:string):boolean; } class ModernPrinter implements IPrinterOperations,IFaxOperations {/* ... */} ``` #### 依赖倒置原则 (DIP) 高层模块不应依赖低层模块,二者都应该依赖于抽象;具体而言就是面向接口编程而非具体的实现。这样的架构使得整个应用程序更易于测试、重构以及适应未来需求的变化。 ```python from abc import ABCMeta, abstractmethod class Switchable(metaclass=ABCMeta): @abstractmethod def turn_on(self)->None: pass def switch_power(device:Switchable): device.turn_on() ``` #### 迪米特法则/最少知道原则 (LoD) 迪米特法则是指一个对象应当对其它对象有尽可能少的了解。换句话说,尽量减少相互间的交互关系,保持较低程度的耦合状态。这样做的好处是可以简化调试过程并增强系统的健壮性。 ```php <?php class LightBulb { function on(){/*...*/} function off(){/*...*/} } $lightbulb=new LightBulb(); // 避免过度暴露内部属性给外部调用者 echo $lightbulb->on(); ?> ``` #### 合成聚合复用原则 (CARP) 合成聚合复用原则建议优先考虑组合/聚合方式重用已有组件的功能,而不是通过继承机制来达到目的。因为前者通常具有更好的可读性和更高的内聚力,同时也更容易理解和管理。 ```xml <!-- XML配置文件 --> <person> <name>John Doe</name> <!-- 使用地址作为组成部分 --> <address street="Main St." city="Springfield"/> </person> ```
评论 82
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值