设计模式之开篇

这篇具有很好参考价值的文章主要介绍了设计模式之开篇。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

设计模式之开篇,技术专项能力,设计模式,java,开发语言

在软件开发的世界里,设计模式有如一本精妙的工程艺术指导准则,为我们提供了解决常见问题的优雅实现方案。然而,有些程序员可能会认为设计模式太过繁琐,一个简单的 if/else 语句就能解决问题,何必费心去学习这些看似复杂的概念呢?在这个系列的文章里,我和大家一起探讨为什么设计模式是值得的,以及如何在实际开发中去融入设计模式的思想。

一、为什么学设计模式

1、代码质量和可维护性

拥有设计模式的思维方式,意味着你不仅仅是在写能够工作的代码,更是在构建具有良好结构的、易于理解和维护的代码。设计模式是过去经验的总结,它们提供了在各种场景下验证过的最佳实践,有助于避免常见的陷阱和错误。

2、可扩展性和灵活性

需求总是在变化的,永远不可能存在一层不变的需求,而设计模式可以为你的代码提供更好的扩展性。通过采用开放封闭等设计原则,你的代码可以更容易地适应新的功能需求,而不需要对原有的代码进行大规模修改。

3、团队协作

设计模式是一种通用的编程语言,它提供了一种共享的术语和理解方式,有助于团队成员更容易理解和协作。当所有人都熟悉常见的设计模式时,交流就会变得更加高效,合作更加顺畅。

二、怎么样学设计模式

1、刻意实践

在日常编码中刻意使用设计模式是学习的最佳途径。不要觉得使用设计模式会让代码变得复杂和难以理解,相反,它会使你的代码更加清晰、模块化,易于维护。逐渐将设计模式的思想融入到自己的编程风格中,形成个性化的代码风格。

2、实战演练

学以致用是掌握设计模式的关键。在实际项目中应用设计模式,从而更好地理解其实际应用场景。实战中的经验往往比理论知识更加深刻和有说服力。

3、逐步演进

不要急于一时,逐步演进是掌握设计模式的关键。从一段已有的代码开始,尝试用设计模式和SOLID原则进行重构。通过对比前后的代码,你将会发现自己在设计和编写代码方面的进步。

4、重点理解设计原则

设计模式的基石是设计原则,例如开放封闭原则、单一职责原则等。深入理解这些原则,能够更好地指导你在实际项目中的设计和编码过程。设计原则是设计模式的根基,也是培养良好代码习惯的关键。

三、设计原则的补充说明

一般的书籍和文章讲到设计原则,都讲的是 SOLID 原则,而我这里要说的是七原则:SOLID + CARP + LoD

1 、SRP(Single responsibility Principle)单一职责原则

SRP 是一项简单易懂且重要的原则,但是在实际过程中往往最容易忽略的,它强调在应用中,一个类应该只有一个引起变化的原因,只有一个职责。

SRP 是基于康威定律的推导结论:软件系统的最佳结构高度依赖于开发这个系统的组织的内部结构,每个软件模块都有且只有一个需要被改变的理由。

优点
  • 降低类之间的耦合:将不同职责分解为不同的类,降低类之间的依赖关系,提高系统的灵活性和可维护性
  • 提升类的可维护性和可重用性:当一个类只有一个职责时,修改该职责不会影响到其他职责,使得类更加稳定,易于维护和重用
  • 简化设计过程:SRP 原则使得类的设计更加清晰,每个类都专注于解决一个问题,降低了设计的复杂性
示例代码

多职责的类设计

public class UserService {
    /*** 运营部员工绩效计算 */
    public BigDecimal calculateKPIResultForOperation() { }
    
    /*** 商务员工绩效计算 */
    public BigDecimal calculateKPIResultForBusiness() { }
    
    /*** 产品部员工绩效计算 */
    public BigDecimal calculateKPIResultForProduct() { }
    
    /*** 技术部员工绩效计算 */
    public BigDecimal calculateKPIResultForTechnology() { }
}

SRP 后的类设计

public interface UserService {
    public BigDecimal calculateKPIResult();
}

// 不同部门实现接口
public class OperationUserService implement UserService {}
public class BusinessUserService implement UserService {}
public class ProductUserService implement UserService {}
public class TechnologyUserService implement UserService {}
注意点
  • 拆分多职责类:如果一个类承担了多个职责,就一定要拆分为多个类,确保每个类只有一个职责
  • 识别变化原因:识别引起类变化的原因,然后职责分配到对应的类,确保每个类的变化原因是明确的
  • 避免过度设计:尽可能简单,避免过度设计和复杂性,SRP 的目标是简化设计,而不是增加不必要的结构

2 、OCP(Open/Close Principle) 开闭原则

OCP 的核心思想是通过扩展已有的代码,增加新的行为和功能,而不是修改已有的代码。

优点
  • 提高代码的可维护性和可重用性:允许系统通过扩展已有的代码来应对新的需求,而不是修改已有的代码,降低引入错误的风险
  • 减少代码的耦合度:模块化的设计使得系统个部分之间的耦合度降低,一个模块的修改不会对其他模块产生影响
  • 提高系统的可扩展性和可升级性:新功能可以通过添加新的类或模块来实现,而不是修改已有的代码,使得系统更容易扩展和升级
示例代码

无 OCP 的代码

public class Calculator {  
    public int add(int a, int b) {  
        return a + b;  
    }  
      
    public int subtract(int a, int b) {  
        return a - b;  
    }  
      
    public int multiply(int a, int b) {  
        return a * b;  
    }  
      
    public int divide(int a, int b) {  
        return a / b;  
    }  
}

有 OCP 的代码

public interface Operation {  
    int calculate(int a, int b);  
}  
  
public class AddOperation implements Operation {  
    public int calculate(int a, int b) {  
        return a + b;  
    }  
}  
  
public class SubtractOperation implements Operation {  
    public int calculate(int a, int b) {  
        return a - b;  
    }  
}  
  
public class MultiplyOperation implements Operation {  
    public int calculate(int a, int b) {  
        return a * b;  
    }  
}  
  
public class DivideOperation implements Operation {  
    public int calculate(int a, int b) {  
        return a / b;  
    }  
}
注意点
  • 使用 OCP 原则:把实体设计成可扩展,通过新加类、模块或者函数来扩展功能和行为
  • 抽象化已有代码:对已有代码进行抽象,将具体的实现细节封装,对外仅提供抽象的接口
  • 避免过度设计:OCP 原则的目标是简化设计而不是增加不必要的结构

3 、LSP(Liskov Substitution Principle)里氏替换原则

LSP 强调在软件中,子类必须能够替换其父类,即子类应该具有与父类相同的行为和功能,而不仅仅是继承父类的属性和方法。

优点
  • 提高代码的可读性和可维护性:子类与父类具有一致的行为和功能,使得代码更易于理解和维护
  • 减少代码的冗余和复杂性:子类继承父类的方法和属性,可以避免重复编写相似的代码
  • 提高系统的可扩展性和可升级性:新的子类可以无缝地替换父类,不会影响系统的其他部分
示例代码

无 LSP 代码

class Shape {  
    void draw() {  
        System.out.println("Drawing a shape");  
    }  
}  
  
class Circle extends Shape {  
    void draw() {  
        System.out.println("Drawing a circle");  
    }  
}

有 LSP 代码

interface Drawable {  
    void draw();  
}  
   
class Shape implements Drawable {  
    public void draw() {  
        System.out.println( "Drawing a shape");  
    }  
}  
  
class Circle extends Shape {  
    public void draw() {  
        System.out.println("Drawing a circle");  
    }  
} 
注意点
  • 子类具有一致的行为和功能:子类必须具有与父类相同的行为和功能,但不能改变父类的行为和功能
  • 抽象类定义抽象方法:抽象类应该定义抽象方法,具体方法在子类中实现
  • 避免继承滥用:避免使用继承来共享行为,继承是用来实现多态行为的,而不是为了代码的重用。如果子类需要不同的功能和行为,那应该通过重写父类方法来实现

4 、ISP(Interface Segregation Principle)接口隔离原则

ISP 强调在应用中使用多个特定的接口,而不是一个单一的总接口,从而避免端侧就不需要被强制依赖他们不需要的接口。

优点
  • 提高代码的可维护性和可重用性,特定接口提供特定服务,代码可以更加模块化和可定制化
  • 减少端侧的复杂性,端侧只需要依赖实际使用的接口,避免对不相关接口的强制依赖
  • 提高系统的可扩展性和可升级性,新的接口可以被添加而不会影响实际使用的接口,使得系统更容易扩展和升级
示例代码

无 ISP 代码

interface ShoppingCart {  
    void addItem(Product product, int quantity);  
    void removeItem(Product product);  
    void updateQuantity(Product product, int quantity);  
}  
  
class ShoppingCartImpl implements ShoppingCart {  
    private Map<Product, Integer> items = new HashMap<>();  
      
    @Override  
    public void addItem(Product product, int quantity) {  
        items.put(product, quantity);  
    }  
      
    @Override  
    public void removeItem(Product product) {  
        items.remove(product);  
    }  
      
    @Override  
    public void updateQuantity(Product product, int quantity) {  
        int currentQuantity = items.get(product);  
        items.put(product, currentQuantity + quantity);  
    }  
}

有 ISP 代码

interface AddToCart {  
    void addItem(Product product, int quantity);  
}  
  
interface RemoveFromCart {  
    void removeItem(Product product);  
}  
  
interface UpdateQuantity {  
    void updateQuantity(Product product, int quantity);  
}  
  
class ShoppingCartImpl implements AddToCart, RemoveFromCart, UpdateQuantity {  
    private Map<Product, Integer> items = new HashMap<>();  
      
    @Override  
    public void addItem(Product product, int quantity) {  
        items.put(product, quantity);  
    }  
      
    @Override  
    public void removeItem(Product product) {  
        items.remove(product);  
    }  
      
    @Override  
    public void updateQuantity(Product product, int quantity) {  
        int currentQuantity = items.get(product);  
        items.put(product, currentQuantity + quantity);  
    }  
}
注意点
  • 接口定义尽可能小:每个接口提供有限的服务,方法尽可能少,不要妄想一个接口走遍天下
  • 分离不相关功能:如果接口中提供的功能不相关,需要将接口进行分离操作,形成独立接口,代码可更模块化和可定制化
  • 避免使用过大的总接口:总接口应该根据需要提供适当的功能,而不是一刀切提供所有功能

5 、DIP(Dependency Inversion Principle)依赖倒置原则

DIP 强调在应用中,高层模块不应该依赖于底层模块,它们应该依赖于抽象。

优点
  • 提高代码的可读性和可维护性:高层模块依赖于抽象,而不是具体实现,使得代码更灵活和易于理解
  • 降低类之间的耦合度:依赖抽象不依赖具体实现,减少了高层模块和底层模块之间的直接依赖,提高了系统的灵活性
  • 提高系统的可扩展性和可升级性:新的实现可以通过实现抽象来引入,不需要修改高层模块的代码
示例代码

无 DIP 代码

class UserService {  
    private UserDao userDao;  
      
    public UserService(UserDao userDao) {  
        this.userDao = userDao;  
    }  
      
    public User getUserById(int userId) {  
        return userDao.getUserById(userId);  
    }  
}  
  
class UserDao {  
    public User getUserById(int userId) {  
        // 具体实现逻辑,如从数据库中获取用户信息  
        return new User(userId, "John Doe");  
    }  
}

有 DIP 代码

interface UserDataAccess {  
    User getUserById(int userId);  
}  
  
class UserDao implements UserDataAccess {  
    @Override  
    public User getUserById(int userId) {  
        // 具体实现逻辑,如从数据库中获取用户信息  
        return new User(userId, "John Doe");  
    }  
}  
  
class UserService {  
    private UserDataAccess userDataAccess;  
      
    public UserService(UserDataAccess userDataAccess) {  
        this.userDataAccess = userDataAccess;  
    }  
      
    public User getUserById(int userId) {  
        return userDataAccess.getUserById(userId);  
    }  
}
注意点
  • 通过接口或抽象类定义依赖关系:使用接口或抽象类来定义高层模块和底层模块之间的依赖关系
  • 避免直接依赖具体类:如果直接依赖具体类,一旦有修改,依赖元就要同步改动,影响和成本都较高
  • 使用依赖注入解耦:使用依赖注入来解耦类之间的依赖关系,通过注入抽象的实现来实现高层模块对底层模块的依赖

6 、CARP(Composition/Aggregation Reuse Principle)合成/聚合复用原则

CARP 强调在应用设计过程中优先使用合成/聚合的关系,而不是继承的关系来实现复用。

优点
  • 更好地代码封装:通过使用合成/聚合,可以将对象的不同部分封装在不同的类中,更好地隐藏细节,提高代码的模块化和可维护性
  • 更灵活的代码结构:通过使用合成/聚合,可以更容易地改变对象的行为和结构,只需要修改相关的类,不需要修改整个继承体系
  • 更好的可重用性:通过使用合成/聚合,可以根据需要组合不同的对象来实现代码的可重用性,且合成/聚合本身是一种松耦合,可以更便捷地组装新的对象类型
  • 更好的可扩展性:通过使用合成/聚合,更便捷地添加新的功能和行为到应用中,这种灵活的关系,可以更容易适应新的需求和变化
示例代码

无 CARP 代码

class Car {  
    private Engine engine;  
    private Transmission transmission;  
    private Wheel wheel;  
    private Door door;  
  
    public Car(Engine engine, Transmission transmission, Wheel wheel, Door door) {  
        this.engine = engine;  
        this.transmission = transmission;  
        this.wheel = wheel;  
        this.door = door;  
    }  
  
    public void start() {  
        engine.start();  
    }  
  
    public void shift(int gear) {  
        transmission.shift(gear);  
    }  
  
    public void turn(int degrees) {  
        wheel.turn(degrees);  
    }  
  
    public void open() {  
        door.open();  
    }  
}

有 CARP 代码

interface Engine {  
    void start();  
}  
interface Transmission {  
    void shift(int gear);  
}  
interface Wheel {  
    // 可以添加一些方法,例如 rotate() 和 brake() 等  
}  
interface Door {  
    void open();  
}  
class Car {  
    private Engine engine;  
    private Transmission transmission;  
    private Wheel wheel;  
    private Door door;  
  
    public Car(Engine engine, Transmission transmission, Wheel wheel, Door door) {  
        this.engine = engine;  
        this.transmission = transmission;  
        this.wheel = wheel;  
        this.door = door;  
    }  
}
注意点
  • 封装变化:将变化的部分封装起来,使得变化对其他部分的影响最小
  • 强调组合/聚合:首选使用组合/聚合关系,而不是直接继承关系,以提高灵活性和可维护性
  • 松耦合:合成/聚合是一种松耦合关系,允许系统更容易地适应变化

7 、LoD(Law of Demeter)迪米特法则

LoD 强调在应用中应该尽量减少对象之间的直接依赖关系,降低耦合度,提高可维护性和可重用性。

核心思想是一个对象对其他对象保持最少的了解,并且只和那些和自己最有直接关系的对象进行交互。

一个对象只暴露必要的接口给其他对象,并且应该通过这些接口与其他对象进行交互。

优点
  • 降低耦合度:减少对象之间的直接依赖关系,使得系统更容易扩展和维护
  • 提高可维护性:对象之间的松耦合关系使得修改一个对象的内部实现不会影响其他对象
  • 提高可重用性:松耦合关系允许对象更容易地被独立重用在不同的上下文中
示例代码

无 LoD 代码

class Account {  
    private User user;  
    private List<Transaction> transactions;  
  
    public Account(User user, List<Transaction> transactions) {  
        this.user = user;  
        this.transactions = transactions;  
    }  
  
    public double getBalance() {  
        double balance = 0.0;  
        for (Transaction transaction : transactions) {  
            balance += transaction.getAmount();  
        }  
        return balance;  
    }  
  
    public void debit(double amount) {  
        user.setBalance(user.getBalance() - amount);  
    }  
}

有 LoD 代码

interface UserService {  
    double getBalance(User user);  
}  
  
interface TransactionService {  
    void debit(User user, double amount);  
}  
  
class Account {  
    private UserService userService;  
    private TransactionService transactionService;  
  
    public Account(UserService userService, TransactionService transactionService) {  
        this.userService = userService;  
        this.transactionService = transactionService;  
    }  
  
    public double getBalance() {  
        return userService.getBalance(userService.getUser());  
    }  
  
    public void debit(double amount) {  
        transactionService.debit(userService.getUser(), amount);  
    }  
}
注意点
  • 定义接口:将对象的相关操作定义在接口中,而不是直接依赖于具体的实现
  • 通过接口交互:对象应该通过接口进行交互,而不是直接调用其他对象的方法
  • 减少依赖关系:一个对象应该只与其直接的朋友发生交互,避免依赖过多的对象

接下来会逐一介绍各个设计模式。

我在介绍每一个设计模式的时候都会采用统一的框架,如下:

1、什么是 XXX 设计模式?

2、为什么使用 XXX 设计模式?

3、如何实现 XXX 设计模式?

4、是否存在缺陷和不足?

5、如何缓解缺陷和不足?文章来源地址https://www.toymoban.com/news/detail-767813.html

到了这里,关于设计模式之开篇的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • JAVA设计模式----原型设计模式

    定义 :用原型实例指定创建对象的种类,并通过拷贝这些原型创建新的对象。 类型 :创建类模式 类图 : 原型模式主要用于对象的复制,它的核心是就是类图中的原型类Prototype。Prototype类需要具备以下两个条件: 实现Cloneable接口。在java语言有一个Cloneable接口,它的作用只

    2024年02月13日
    浏览(49)
  • Java设计模式 (三) 代理设计模式

    什么是代理设计模式? 代理设计模式是一种结构型设计模式,它允许创建一个代理对象,用于控制对其他对象的访问。代理模式通常用于在访问对象时添加一些附加操作,而不是直接访问真实对象。代理模式可以在不改变原始类代码的情况下,通过引入代理类来增强功能。 代

    2024年02月12日
    浏览(41)
  • 【设计模式】Java设计模式详细讲解

    一、概述 Java设计模式是Java程序设计中一种重要的最佳实践,它提供了一种框架和结构,可以帮助开发者更好地理解和设计复杂的系统。设计模式不仅仅是一种语法规则,更是一种思想和方法论,它能够帮助开发者更好地分析、设计和实现软件系统。 设计模式的概念最早由

    2024年02月10日
    浏览(51)
  • Java设计模式 (一) 模板方法设计模式

    什么是模板方法设计模式? 模板方法设计模式是一种行为型设计模式,它定义了一个算法的骨架,并将一些步骤的具体实现延迟到子类中。模板方法模式可以帮助确保在算法的不同部分中保持一致性,同时也允许子类根据需要进行具体实现。 模板方法模式的关键特点包括:

    2024年02月12日
    浏览(41)
  • 安卓基础巩固(四):设计原则、安卓主流技术框架MVC/MVP/MVVM、设计模式

    模块化功能:使得程序模块化,即内部高聚合,模块之间低耦合 提高开发效率:开发人员只需要专注于一点(视图显示、业务逻辑、数据处理) 提高测试效率:后期测试时可以迅速根据报错反馈,定位到问题出现的位置。 六大设计原则是设计模式的理论,设计模式是设计原

    2024年02月06日
    浏览(53)
  • Java设计模式-命令模式

    命令模式,将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化。对请求排队或记录请求日志,以及支持可撤销的操作。 命令模式乍一看,有点懵懵的。即使这个定义看完,也是不明所以。但是结合例子来讲的话,就比较容易理解了。 其实它就是把一个

    2024年02月15日
    浏览(33)
  • Java设计模式-原型模式

    原型模式是一种创建型设计模式,它允许在运行时通过复制现有对象来创建新对象,而不是通过构造函数创建。这个模式的核心思想是基于一个现有的对象克隆一个新的对象,这个过程对外部世界是透明的,就像对象从未被克隆过一样。 原型模式的一个关键优点是可以避免在

    2024年02月03日
    浏览(45)
  • Java设计模式——策略模式

    1. 策略模式简介 策略模式: 策略模式是一种行为型模式, 它将对象和行为分开, 将行为定义为一个行为接口和具体行为的实现 策略模式最大的特点是行为的变化, 行为之间可以相互替换 每个if判断都可以理解为一个策略. 本模式是的算法可独立于使用它的用户而变化 2. 模式结构

    2024年02月11日
    浏览(50)
  • java设计模式---策略模式

    策略设计模式是一种行为设计模式。当在处理一个业务时,有多种处理方式,并且需要再运行时决定使哪一种具体实现时,就会使用策略模式。 策略模式的类图: 在支付业务中,有三种付款方式,程序运行时使用哪种方式由用户选择,根据用户选择执行不同的逻辑。 首先,

    2024年02月10日
    浏览(44)
  • Java设计模式-桥接模式

    桥接模式是将抽象部分与它的实现部分分离,使它们都可以独立地变化。 这个概念听着那是相当拗口了,其实通过例子解释后,就能很好的理解了。 下面先看一个例子,这个例子表现了手机与手机软件之间的关系 2.1HandsetSoft类 这个类是手机软件的抽象类 2.2HandSetGame类 这个是

    2024年02月16日
    浏览(42)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包