设计模式之六大设计原则

已于 2024-05-27 18:40:37 修改
阅读量545 收藏 5
点赞数 8
文章标签： 设计模式 开发语言 android java
于 2024-05-24 23:08:04 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Patrick_yuxuan/article/details/139186364
版权

文章目录

高内聚低耦合

提高代码的可读性、可维护性和可扩展性，降低开发和维护的成本，并减少系统的风险

内聚：

内聚表示一个模块内部各个元素之间相互关联的程度。

高内聚意味着模块内部的功能紧密相关，所有部分都共同完成一个特定的任务或功能。

低内聚则意味着模块内部包含多种不相关的功能。

耦合：

耦合表示不同模块之间相互依赖的程度。

高耦合意味着模块之间相互依赖紧密，一个模块的变化会影响到其他模块。

低耦合则意味着模块之间相对独立，一个模块的变化对其他模块的影响较小。

举个例子：

汽车是由许多不同的部件组成的，比如发动机、轮胎、刹车等等。

在高内聚低耦合的设计中，每个部件都应该专注于自己的功能，同时尽可能减少与其他部件之间的依赖关系。

高内聚意味着每个部件都应该有一个清晰的责任和功能。发动机的责任是提供动力，而刹车系统的责任是提供制动。这样设计的好处是，每个部件都可以独立工作，而不需要过多依赖其他部件的内部细节。

低耦合意味着部件之间的相互依赖应该尽可能减少。刹车系统不需要知道发动机如何工作，它只需要知道何时需要制动。这样设计的好处是，如果需要更改或替换一个部件，不会对其他部件产生太大影响，因为它们之间的依赖关系很少。

高内聚：意味着一个类或模块的内部元素（包括变量、方法和属性）应该紧密相关，并且共同服务于一个明确且集中的目的。

低耦合：模块或类之间的依赖关系应该尽可能少

  • 内紧（高内聚）：程序内的模块或类应该紧密相关，形成一个高效的功能单元。
  • 外松（低耦合）：程序之间的模块或类应该尽可能不关联，各自实现各自的功能。

设计原则

在进行软件系统设计时所要遵循的一些经验准则，应用该准则的目的通常是为了避免某些经常出现的设计缺陷，提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性

包括单一职责原则，开放封闭原则，里氏替换原则，依赖倒置原则，迪米特原则，接口隔离原则

开闭原则

（Open-Closed Principle, OCP）

定义：类，模块，函数等应该是可以拓展的，但是不可修改

对扩展开放，对修改关闭。

我们需要使用抽象实现（接口和抽象类）达到这样的效果。

因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。

而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。

举个例子

//AbstractSkin.java
public abstract class AbstractSkin {
    //显示皮肤
    public abstract void display();
}

//DefaultSkin.java
public class DefaultSkin extends AbstractSkin{
    @Override
    public void display() {
        System.out.println("默认皮肤");
    }
}

//WhiteSkin.java
public class WhiteSkin extends AbstractSkin{
    @Override
    public void display() {
        System.out.println("白色皮肤");
    }
}

//SougouInput.java
public class SougouInput {
    private AbstractSkin skin;

    public AbstractSkin getSkin() {
        return skin;
    }
	//通过setSkin方法设置不同的皮肤实现
    public void setSkin(AbstractSkin skin) {
        this.skin = skin;
    }

    public void display() {
        skin.display();
    }
}

//Client.java
public class Client {
    public static void main(String[] args) {
        //1.创建输入法对象
        SougouInput input = new SougouInput();
        //2.创建皮肤对象
        DefaultSkin skin = new DefaultSkin();
      //WhiteSkin skin = new WhiteSkin();
        //3.将皮肤设置到输入法中
        input.setSkin(skin);
        //4.显示皮肤
        input.display();
    }
}

SougouInput 类通过其 setSkin 方法允许添加不同类型的皮肤（如 DefaultSkin 或 WhiteSkin），这体现了对扩展的开放性。

由于 SougouInput 类依赖于 AbstractSkin 抽象类而不是具体的皮肤实现类，因此添加新的皮肤类型只需要创建新的子类并实现 AbstractSkin 的 display 方法，而不需要修改 SougouInput 类的代码。这体现了对修改的封闭性。

皮肤的类不用修改，再创建新皮肤，让他继承AbstractSkin抽象类，在客户端类代码进行修改即可。

作用：

  1. 提高软件的可维护性
  2. 增强软件的扩展性
  3. 减少代码的耦合度

单一职责原则

（Single Responsibility Principle，SRP）

定义：一个类（或模块、函数等）应该只有一个引起它变化的原因。换句话说，一个类应该只负责一个功能领域中的相关职责，或者变化的原因应该只有一个。

下面是不符合单一职责原则的例子：

public class TelPhone {
    public void Dial(String phone_number){
        System.out.println("给"+phone_number+"打电话");
    }

    public void HangUp(String phone_number) {
        System.out.println("挂断" + phone_number + "打电话");
    }

    public void SendMessage(String message) {
        System.out.println("发送" + message);
    }

    public void ReceiveMessage(String message) {
        System.out.println("接收" + message);
    }
}

可能发生的变化：

  1. 内部的变化，如果 TelPhone 类中的任何一个方法发生改变，，都需要修改TeIPhone、由于它负责了多个职责，所以一个职责的变化可能会导致其他无关职责的代码也需要被修改或重新测试。

  2. 外部的变化，如果TeIPhone要添加新的的方法，需要修改TeIPhone类

为了符合单一职责原则，我们可以做出如下修改：

但中间的依然不符合，存在一个以上引起类变化的原因，所以我们可以考虑最右边的，一个类中只有一个方法

yuanze2

但这样比较极端，会导致类的数量大幅增加，使得管理和维护代码变得复杂。

因此，我们通常要在单一职责原则和实际应用之间找到一个平衡点。

实现方式：

给每个方法，都提炼成一个接口，抽象成一种能力，然后分别写类，去实现接口，最终在TelPhone中只进行调用。

package com.feng.test01;

interface Dialer {
    void Dial(String phoneNumber);
}

interface Hanger {
    void HangUp();
}

interface Sender {
    void SendMessage(String text);
}

interface Receiver {
    void ReciveMessage(String text);
}


class DialerImpl implements Dialer {
    public void Dial(String phoneNumber) {
        System.out.println("给 " + phoneNumber + " 打电话");
    }
}

class HangerImpl implements Hanger {
    public void HangUp() {
        System.out.println("挂断电话");
    }
}

class SenderImpl implements Sender {
    public void SendMessage(String text) {
        System.out.println("发送 " + text);
    }
}

class ReceiverImpl implements Receiver {
    public void ReciveMessage(String text) {
        System.out.println("接收 " + text);
    }
}

class TelPhone {
    private Dialer dialer;
    private Hanger hanger;
    private Sender sender;
    private Receiver receiver;

    public TelPhone(Dialer dialer, Hanger hanger, Sender sender, Receiver receiver) {
        this.dialer = dialer;
        this.hanger = hanger;
        this.sender = sender;
        this.receiver = receiver;
    }

    public void Dial(String phoneNumber) {
        dialer.Dial(phoneNumber);
    }

    public void HangUp() {
        hanger.HangUp();
    }

    public void SendMessage(String text) {
        sender.SendMessage(text);
    }

    public void ReciveMessage(String text) {
        receiver.ReciveMessage(text);
    }
}

public class Main {
    public static void main(String[] args) {
        // 创建接口实现类实例
        Dialer dialer = new DialerImpl();
        Hanger hanger = new HangerImpl();
        Sender sender = new SenderImpl();
        Receiver receiver = new ReceiverImpl();

        // 创建 TelPhone 对象并使用其接口
        TelPhone telphone = new TelPhone(dialer, hanger, sender, receiver);

        // 电话呼叫操作
        telphone.Dial("123456789");
        telphone.HangUp();

        // 消息操作
        telphone.SendMessage("Hello, World!");
        telphone.ReciveMessage("Hi there!");
    }
}

好处：

  1. 提高代码的可读性，提高系统的可维护性。
  2. 降低类的复杂性，一个模块只负责一个职责，提高系统的可扩展性和可维护性。
  3. 降低变更引起的风险。变更是不然的，如果单一职责做得好，当修改一个功能的时候可以显著的降低对另一个功能的影响。

里氏代换原则

（Liskov Substitution Principle，LSP）

里氏代换原则：任何基类可以出现的地方，子类一定可以出现。

通俗理解：子类可以扩展父类的功能，但不能改变父类原有的功能。

要点：

功能保持：子类应当能够替代基类，并且子类对象应能代替基类对象使用，而不会导致程序运行出现问题。

行为一致：子类可以扩展基类的功能，但不能改变基类的功能。即子类的行为应该与基类保持一致

要求：

  1. 子类可以实现父类的抽象方法，但不要去覆盖（重写）父类的非抽象方法
  2. 子类可以增加自己特有的方法
  3. 当子类的方法重写父类的方法时，方法的前置条件（即方法的输入/入参）要比父类方法的输入参数更宽松
  4. 当子类的方法实现父类的方法时（重写或实现抽象方法），方法的后置条件（即方法的输出/返回值）要比父类更严格或与父类一样
package com.feng.test05;

public abstract class Coder {
    public void coding() {
        System.out.println("我会敲代码！");
    }
}

class JavaCoder extends Coder {
    public void play() {
        System.out.println("喜欢玩XXXX");
    }
    //重写了父类的非抽象方法
    public void coding() {
        System.out.println("我只会敲JAVA代码！");
    }
}

里氏代换原则指出，如果程序中的对象使用的是基类（父类）的话，那么无论是使用基类对象还是其子类对象，程序的行为都是一致的。

用 JavaCoder 替代 Coder 时，本来会敲很多代码，但现在只会敲JAVA了。

所以尽量不要去重写父类非抽象方法，不要改变父类原有的功能。

可以这样修改：

  1. 保留父类方法的行为，并且扩展子类方法的功能
    public void coding() {
        super.coding(); // 调用父类的coding方法
        System.out.println("我会敲JAVA代码！");
    }
  1. 或者再写一个javaCoding方法
  2. 写JavaCoder和Coder的抽象父类People，把coding这一行为定义在People中，放弃JavaCoder和Coder的继承关系

好处：

  1. 开放性：是实现开放封闭原则的的具体手段之一
  2. 提高代码的可复用性

依赖倒置原则

（Dependence Inversion Principle，DIP）

定义：高层模块不应该依赖低层模块，两者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。

旨在通过依赖于抽象而不是具体实现来降低系统的耦合度，提高系统的可维护性和可扩展性。

下面是一个违背依赖倒置原则的例子

package com.feng.test04;

class FuelCar{
    public void run(){
        System.out.println("开的是燃油车");
    }
}

class Driver{
    public void drive(FuelCar car) {
        car.run();
    }
}

public class Client {
    public static void main(String[] args) {
        FuelCar fuelCar = new FuelCar();
        Driver xiaowang = new Driver();
        xiaowang.drive(fuelCar);
    }
}

Driver 类直接依赖于 FuelCar 类，而没有使用抽象，违反了依赖倒置原则。

如果我们想要支持其他类型的车辆，比如电动车或者公交车，就需要修改 Driver 类，这样会增加代码的耦合度和维护成本。

高层模块（Driver）不应该直接依赖于低层模块（FuelCar），而是应该依赖于抽象。在这个例子中，Driver 类应该依赖于一个抽象的 ICar 接口，而不是具体的 FuelCar 类。

我们可以引入一个接口来表示所有类型的车，并让FuelCar实现这个接口。然后，Driver的drive方法可以接受任何实现了ICar接口的对象作为参数。

package com.feng.test04after;

interface ICar {
    void run();
}

class FuelICar implements ICar {
    @Override
    public void run() {
        System.out.println("开的是燃油车");
    }
}

class ElectricICar implements ICar {
    @Override
    public void run() {
        System.out.println("开的是电车");
    }
}

class Driver {
    public void drive(ICar car) {
        car.run();
    }
}

public class Client {
    public static void main(String[] args) {
        ICar su7 = new ElectricICar();
        ICar benz = new FuelICar();
        
        Driver driver = new Driver();
        
        driver.drive(su7);
        driver.drive(benz);
    }
}

作用：

  1. 提高代码的可维护性
  2. 降低代码的耦合度
  3. 提高系统的可扩展性

迪米特原则

（Law of Demeter，LoD）

也称为最少知识原则：一个对象应该对其他对象有最少的了解。

定义：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用

一个对象应该对其他对象知之甚少，只与“朋友”通信，而不与“陌生人”直接通信。

  • 租房者-中介-房东
  • 要做软件的公司-软件公司-软件工程师

这里的“朋友”指的是当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等

这些对象同当前对象存在关联、依赖、聚合或组合关系，可以直接访问这些对象的方法。

下面是一个

import java.util.ArrayList;
import java.util.List;

class Product {
    private String name;
    private double price;

    public Product(String name, double price) {
        this.name = name;
        this.price = price;
    }

    public String getName() {
        return name;
    }

    public double getPrice() {
        return price;
    }
}

// 购物车类
class ShoppingCart {
    private List<Product> products;

    public ShoppingCart() {
        this.products = new ArrayList<>();
    }

    // 添加商品到购物车
    public void addProduct(Product product) {
        products.add(product);
    }

    // 打印购物车中的商品信息
    public void printCart() {
        for (Product product : products) {
            System.out.println("商品：" + product.getName() + " 价格：" + product.getPrice());
        }
    }
}

public class Test {
    public static void main(String[] args) {
        Product product1 = new Product("banana", 2);
        Product product2 = new Product("apple", 5);

        ShoppingCart cart = new ShoppingCart();

        cart.addProduct(product1);
        cart.addProduct(product2);

        cart.printCart();
    }
}

ShoppingCart 类对 Product 类的了解仅限于 getName 和 getPrice 方法，这是符合迪米特原则的。ShoppingCart 不需要知道 Product 类的内部实现细节，也不需要与其他任何与 Product 类相关的“陌生人”对象进行交互。

好处：

  1. 降低耦合性
  2. 提高模块独立性
  3. 增强系统的可维护性

接口隔离原则

（Interface Segregation Principle，ISP）

定义：一个类对另一个类的依赖应该建立在最小的接口上。

建立单一接口，不要建立庞大臃肿的接口；尽量细化接口，接口中的方法尽量少。

也就是说，我们要为各个类建立专用的接口，而不要试图建立一个很庞大的接口件所有依赖它的类通用。

下面是一个不符合接口隔离原则的例子：

package com.feng.test03;

interface Device {
    String getCpu();
    String getType();
    String getMemory();
}
class computer implements Device{

    @Override
    public String getCpu() {
        return "i7";
    }

    @Override
    public String getType() {
        return "笔记本电脑";
    }

    @Override
    public String getMemory() {
        return "16GB";
    }
}

class fan implements Device{

    @Override
    public String getCpu() {
        return null; //不需要的方法
    }

    @Override
    public String getType() {
        return "电风扇";
    }

    @Override
    public String getMemory() {
        return null; //不需要的方法
    }
}

虽然定义了一个Device接口，但是由于此接口的粒度不够细化，类依赖于不需要的方法。虽然比较契合电脑这种设备，但是不适合风扇，要对其进行更细粒度的划分。

接口的粒度：描述了接口所提供功能的大小和复杂度

下面是一个符合接口隔离原则粒度更细的代码：

// 通用设备接口  
interface GenericDevice {  
    String getType();  
}  
  
// 电脑设备接口  
interface ComputerDevice extends GenericDevice {  
    String getCpu();  
    String getMemory();  
}  
  
// 风扇设备接口  
interface FanDevice extends GenericDevice {
    void adjustSpeed(int speed);  
}

注意：

  1. 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计的灵活性；但是如果过小，则会造成接口数量过多，使设计复杂化。所以，接口的大小一定要适度。
  2. 为依赖接口的类定制服务，只暴露给调用的类需要的方法，不需要的方法则隐藏起来只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
  3. 提高内聚，减少对外交互。接口方法尽量少用public修饰。接口是对外的承诺，承诺越少，对系统的开发越有利，变更风险也会越少。

作用：

  1. 降低耦合性
  2. 提高灵活性
  3. 增强可维护性
  1. 开闭原则：抽象架构，扩展实现
  2. 单一职责：一个类和方法只做一件事
  3. 里氏替换： 多态，子类可扩展父类
  4. 依赖倒置：细节依赖抽象，下层依赖上层
  5. 接口隔离：建立单一接口
  6. 迪米特原则：最少知道，降低耦合

参考：

  1. 14.设计模式-设计原则(依赖倒转原则概述和案例)
  2. 【设计模式】六大原则详解
  3. 六大设计原则超详细介绍
  4. 面向对象设计原则

如有错误烦请指正。

感谢您的阅读

去看全世界的云
关注
  • 8
    点赞
  • 踩
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Java设计模式六大原则
流楚丶格念的博客
10-16 1475
单一职责原则：一个类，应当只有一个引起它变化的原因；即一个类应该只有一个职责里氏替换原则：所有引用基类的地方必须能透明地使用其子类对象。依赖倒置原则：高层模块不应该依赖低层模块，两者都依赖其抽象；抽象不依赖细节；细节应该依赖于抽象。接口隔离原则：客户端不应该依赖它不需要的接口，类间的依赖关系应该建立在最小的接口上。迪米特法则：是一个对象应当对其他对象尽可能少的了解，如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用；
设计模式六大原则
01-31
解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。说到单一职责原则，...
JAVA设计模式之六大设计原则
程铭程铭你快成名的博客
10-16 4899
在程序设计中，我们通常要遵循以下六大原则： 单一职责原则 官方定义： 就一个类(接口、结构体、方法等等)而言，有且仅有一个引起它变化的原因。 个人理解： 通俗的来讲做一件事就是专注做一件事，不可以三心二意。任务对象只是专注于一项职责，不去承担太多的责任。当任务对象的职责发生变化时，不会对其他的对象产生影响。 遵循单一职责原的优点： 可以大大降低耦合度。 降低类的复杂度。 提高类的...
设计模式六大原则详解
eyes++的博客
01-26 3318
Single-Responsibilitiy Principle（SRP）：对一个类而言，应该仅有一个引起它变化的原因。如果存在多于一个动机去改变一个类，那么这个类就具有多于一个的职责，就应该把多余的职责分离出去，再去创建一些类来完成每一个职责。
java设计模式的六大原则
m0_71674867的博客
07-24 2367
其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。依赖倒转原则是基于这样的设计理念相对于细节的多变性，抽象的东西要稳定的多。用抽象构建框架，用实现扩展细节。里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题。使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。...
设计模式 - 六大设计原则之LSP（里氏替换）
小工匠
01-23 2万+
里氏替换原则（Liskov Substitution Principle , LSP） 由麻省理工学院计算机科学西教授 Barbara Liskov 于1987年提出， 她提出：继承必须确保超类所拥有的性质在子类中仍然成立。
设计模式（一）——六大原则
m0_47743175的博客
11-28 2123
设计模式六大原则
六大设计模式原则-迪米特法则
qq_34222160的博客
03-16 1万+
一、迪米特法则定义 迪米特法则又最少知识原则，其定义如下： 迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少的与其他实体发生相互作用。 二、迪米特法则描述 如果一个系统满足迪米特法则，那么当其中一个软件实体发生变化时，就会尽量少的影响其他软件实体，扩展会相对容易，这是对软件实体之间通信的限制，迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可以降低系统的耦合度，使类与类之间保持松耦合状态。 迪米特法则还有几种定义形式，包括：不要和"陌生人"说话、只与你的直接朋友通信等
设计模式的六大原则
热门推荐
心猿意碼
05-16 4万+
目录 一、单一职责原则（Single Responsibility Principle） 二.开闭原则(Open-Closed Principle, OCP) 三、里氏代换原则(Liskov Substitution Principle, LSP) 四、依赖倒置原则（Dependence Inversion Principle，DIP） 五、接口隔离原则(Interface Se...
设计模式之六大原则详解，Markdown笔记
11-18
详细介绍了设计模式六大原则，配有示例代码和图片，有开闭原则，单一职责原则，里氏替换原则，依赖倒置原则，接口隔离原则，迪米特法则等等。
设计模式6大原则.doc
02-27
对设计模式六大原则的一点总结，欢迎免费下载。
设计模式分类以及六大原则
05-27
设计模式分类以及六大原则整理
设计模式六大原则.doc
05-06
设计模式六大原则（1）：单一职责原则 设计模式六大原则（2）：里氏替换原则 设计模式六大原则（3）：依赖倒置原则 设计模式六大原则（4）：接口隔离原则 设计模式六大原则（5）：迪米特法则 设计模式六大原则...
设计模式6大原则.zip
09-10
对设计模式六大原则的一点总结，欢迎免费下载。
设计模式+六大原则pdf
04-23
孙玉山主编的设计模式所有设计模式+体系结构题目案例源码
（二）设计模式的六大原则
01-08
（二）设计模式的六大原则4.依赖倒置原则5.接口隔离原则6.开闭原则 4.依赖倒置原则 依赖倒置原则：高层模块不应该依赖于低层模块，应该通过抽象依赖，而不是依赖低层，这里的抽象指的是抽象类/接口，细节指的就是...
设计模式六大原则及优点
最新发布
06-05
六大原则是 SOLID 原则，这些原则有助于编写可扩展、灵活且易于维护的代码。以下是 SOLID 原则及其优点： 1. 单一职责原则（Single Responsibility Principle, SRP）: 每个类只做一件事，使其更易于测试和理解。...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值