首页 > 其他分享 >设计模式之六大设计原则

设计模式之六大设计原则

时间：2024-05-25 22:02:35浏览次数：18  
标签：六大 String 原则 void 接口 class 设计模式 public out

文章目录

高内聚低耦合

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

内聚：

表示内部间聚集、关联的程度

耦合：

块间联系，指软件系统结构中各模块间相互联系紧密程度的一种度量。

模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。

举个例子：

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

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

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

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

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

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

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

设计原则

在进行软件系统设计时所要遵循的一些经验准则，应用该准则的目的通常是为了避免某些经常出现的设计缺陷。

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

开闭原则

（Open-Closed Principle, OCP）

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

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

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

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

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

举个例子，阅读下面代码

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

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

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

//SougouInput
public class SougouInput {
    private AbstractSkin skin;

    public AbstractSkin getSkin() {
        return skin;
    }

    public void setSkin(AbstractSkin skin) {
        this.skin = skin;
    }

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

//Client
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 抽象类而不是具体的皮肤实现类，因此添加新的皮肤类型（如 BlackSkin、RedSkin 等）时，只需要创建新的子类并实现 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);
    }
}

可能发生的变化：

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

变化二：外部的变化，如果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("喜欢玩第五人格");
    }
    //重写了父类的非抽象方法
    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);
    }
}

没有直接体现依赖倒置原则

假设我们想驾驶不同的，比如开电车，开公交的话，就不是很灵活。

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

package com.feng.test04after;

interface ICar {
    void run();
}

interface IDriver {
    void drive(ICar car);
}

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

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

class Driver implements IDriver {
    @Override
    public void drive(ICar car) {
        car.run();
    }
}

public class Client {
    public static void main(String[] args) {
        ICar su7 = new ElectricICar();
        ICar benz = new FuelICar();
        
        IDriver xiaoduyyy = new Driver();
        
        xiaoduyyy.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();
    }
}

好处：

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

如有错误烦请指正。

感谢您的阅读

标签：六大,String,原则,void,接口,class,设计模式,public,out
From： https://blog.csdn.net/Patrick_yuxuan/article/details/139186364

相关文章

  • 七种常见的面向对象设计原则
     设计原则名称定义使用频率单一职责原则一个类只负责一个功能领域中的相应职责 四颗星开闭原则软件实体应对扩展开发，而对修改关闭 五颗星 里氏代换原则所有引用基类对象的地方能够透明地使用其子类的对象 五颗星依赖倒转原则抽象不应该依赖于细节......
  • c++ 设计模式：建造者模式
    建造者模式（BuilderPattern）是一种创建型设计模式，它允许你构造复杂对象步骤分解。你可以不同的步骤中使用不同的方式创建对象，且对象的创建与表示是分离的。这样，同样的构建过程可以创建不同的表示。举例说明：#include<iostream>//#include<map>//#include<stack>#include<......
  • 重构MQ处理架构：MVEL表达式和责任链设计模式应用实践
    重构MQ处理架构：MVEL表达式和责任链设计模式应用实践https://mp.weixin.qq.com/s/_UZhfi1BiGNHQAHWhGus8Q 3.责任链设计模式【3.1定义】责任链模式（ChainofResponsibility）又名职责链模式，是一种行为设计模式，它允许你构建一个由多个对象组成的链，每个对象都有机会处理请求，或者......
  • 测试环境建设原则和问题对策
    《Pattern:ServiceMesh》测试环境建设原则和管理实践测试环境不稳定&复杂的必然性及其对策......
  • Spring框架中都用到了哪些设计模式？
    这是一道相对有难度的题目，你不仅要回设计模式，还要知道每个设计模式在Spring中是如何使用的。简单工厂模式：Spring中的BeanFactory就是简单工厂模式的体现。根据传入一个唯一的标识来获得Bean对象，但是在传入参数后创建还是传入参数前创建，要根据具体情况来定。工厂模式：Spring......
  • 设计模式06----桥接模式
    桥接模式（BridgePattern）属于结构型设计模式，用于将一个大类或一系列紧密相关的类拆分为抽象和实现两个独立的层次结构，使得这两层能够独立地扩展。桥接模式通常包含以下角色：抽象化（Abstraction）：定义抽象类的接口，维护对实现化对象的引用。细化抽象（RefinedAbstraction）：扩展抽象化角色，......
  • Java核心面试知识集—设计模式
    设计模式知识点笔记汇总1.单例模式（SingletonPattern）2.工厂模式3.抽象工厂模式（AbstractFactoryPattern）4.模板方法模式（TemplateMethodPattern）5.建造者模式（BuilderPattern）6.代理模式（ProxyPattern）7.原型模式（PrototypePattern）8.中介者模式9.命令模式10.责任链模式11......
  • 设计原则和设计模式
    一.六大设计原则 1.单一职责原则 一个类或者模块只完成一个职责 微服务架构 2.里氏替换原则： 核心思想：减少对具体类的依赖，增加对抽象（接口或者实现类）依赖，降低类之间的耦合性，提高系统的可维护性和扩展性 多用组合，少用继承 3.依赖倒置原则（SpringIOC具体体现） 依赖倒置不会只在......
  • 软件设计原则—合成复用原则
    继承可以提高代码的复用性，但是继承会带来很多问题合成复用原则是指：尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。通常类的复用分为继承复用和合成复用两种。继承复用虽然有简单和易实现的优点，但它也存在以下缺点：继承复用破坏了类的封装性。因为继承......
  • 软件设计原则—接口隔离原则
    B类需要方法1好处是b类继承A类后就有了方法1的功能，问题是B类被迫有了它不使用的方法2这个其实是根据方法的职责细分接口，只需要依赖其中一个接口就可以了客户端不应该被迫依赖于它不使用的方法；一个类对另一个类的依赖应该建立在最小的接口上。下面看一个例子来理解接口隔离......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99