设计模式七大原则

设计模式背后的七大原则是软件开发过程中必须遵循的黄金法则,为我们构建高质量的软件架构奠定了坚实基础。本文将深入剖析这七大原则,带您领略其深刻内涵与实际应用。

一、单一职责原则(Single Responsibility Principle, SRP)

2.1 原则定义

一个类应该仅有一个引起它变化的原因,即一个类应该只负责一项职责。

2.2 示例分析

以一个简单的用户管理系统为例,假设我们有一个 UserService 类,它既负责用户信息的存储(如将用户数据写入数据库),又负责用户信息的验证(如验证用户名是否合法、密码强度是否符合要求)。当数据库存储方式发生变化时,UserService 类需要修改;当用户验证规则改变时,UserService 类同样需要修改。这就违背了单一职责原则。

按照单一职责原则,我们应该将其拆分为两个类:UserStorageService 负责用户信息的存储操作,UserValidationService 负责用户信息的验证操作。这样,当某一项职责发生变化时,只需要修改对应的类,而不会影响到其他职责相关的代码。

2.3 优势

  • 提高可维护性:当一个类只负责一项职责时,代码逻辑更加清晰,修改某个功能时不容易影响到其他功能,从而降低维护成本。
  • 增强可扩展性:如果需要增加新的职责,只需要创建新的类来承担该职责,而不需要对现有类进行大规模修改。

二、开闭原则(Open - Closed Principle, OCP)

3.1 原则定义

软件实体(类、模块、函数等)应该对扩展开放,对修改关闭。即当软件需要变化时,我们应该通过扩展代码来实现变化,而不是修改现有的代码。

3.2 示例分析

假设我们正在开发一个图形绘制系统,目前有一个 Shape 类和一个 DrawShapes 类。Shape 类是所有图形类的基类,DrawShapes 类负责绘制各种形状。最初系统只有圆形(Circle)和矩形(Rectangle)两种图形。

// 基类Shape
class Shape {
    public void draw() {
        // 空实现,具体图形类实现
    }
}

// 圆形类
class Circle extends Shape {
    @Override
    public void draw() {
        System.out.println("绘制圆形");
    }
}

// 矩形类
class Rectangle extends Shape {
    @Override
    public void draw() {
      
### 设计模式七大原则详解 #### 单一职责原则 (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> ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值