# DesignPatternJavaCode

**Repository Path**: jhr6666/DesignPatternJavaCode

## Basic Information

- **Project Name**: DesignPatternJavaCode
- **Description**: 设计模式，大话设计模式Javav代码
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2023-10-15
- **Last Updated**: 2024-01-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# DesignPatternJavaCode
## 大话设计模式Java版本代码实现
+ demo01 简单工厂模式 实现计算器功能
+ demo02 收银软件的实现（简单工厂模式）--20231024改造使用策略模式+工厂模式结合实现
+ demo03 策略模式的简单实现，根据此demo，对demo02 进行改造，改为使用策略模式实现收银软件。
  + 更新使用策略模式与简单工厂模式结合（TestCashContext2），直接调用CashContext，降低了耦合，使具体的收费算法与客户端分离。
  + 总结：策略模式是一种定义了一系列算法的方法，从概念上看，所有的这些算法都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各类算法类与使用算法类之间的耦合（DPE）
  + 优点：策略模式的Strategy类层次为Context定义了一系列的可供重用的算法或者行为。继承有助于解析取出这些算法中的公共功能。对于打折、返利或者其他的算法，其实都是对商品收费的一种计算方式，通过继承，可以获取到他们的公共功能，即：获取计算费用的结果GetResult,这使得算法间有了抽象的父类CashSuper。
  + 策略模式的另一个优点就是简化了单元测试。因为每个算法都有自己的类。可以通过自己的接口单独测试。每个算法可以保证它没有错误，修改其中任何一个时也不会影响其他的算法。(20231024)
+ demo04 拍摄UFO—--单一职责原则(20231025)
  + **单一职责 SRP** 的准确解释是：就一个类而言，应该仅有一个引起它变化的原因。
+ demo05 第四章：开放封闭原则
  + **开放-封闭原则**，就是说软件实体（类，模块，函数等）应该是可以扩展，但是不能修改。
  + 这个原则有两个特征，一个是说‘**对于扩展是开放的（Open for Extension）**’,另一个是说‘**对于更改是封闭的(Closed for Modififcation)**'。
  + 我们在做任何系统的时候，都不要指望系统一开始时需求确定，就再也不会变化，这个是不现实，也是不科学的想法，而既然需要是一定会变化的，那么在面对需求的变化时，设计的软件可以相对容易修改，不至于说，新的需求一来，就要把整个程序推倒重来，**怎样的设计才能面对需求的改变却可以保持相对的稳定，从而使系统可以在第一个版本以后不断地退出新的版本呢？**。开放封闭原则给了我们答案。即多扩展少修改。

+ demo06 第五章：依赖倒转（也有叫依赖倒置）原则:**抽象不应该依赖细节，细节应该依赖于抽象**，说白了，就是要**针对接口编程，而不是对实现编程**。
  + 依赖倒转原则A：高层模块不应该依赖底层模块，两个都应该依赖抽象
  + 依赖倒转原则B：抽象不应该依赖细节。细节应该依赖抽象。
  
  > 里氏代换原则（LSP）：子类必须能够替换掉它的父类型。
  ---
  具体的解释就是**一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出来父类对象和子类对象的区别，也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。**

+ demo07 第六章--装饰模式
  + 示例：设计一个可以给人搭配不同的服饰的系统；第二版本，利用开放封闭原则，给服饰设计子类。第一个版本，使用前面的策略模式实现。这里有一些问题：例如这些功能不能按照正确的顺序串联起来进行控制，因此使用装饰模式，动态添加职责；
  + **装饰模式(Decorator)**,动态的给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更加的灵活。
    + 具体代码在demo7下的decorator包下：Component是定义一个对象接口，可以给这些对象动态的添加职责，ConcreteComponent是定义了一个具体的对象，也可以给这个对象添加一些职责。Decorator,装饰抽象类，继承了Component，从外类来扩展Component类的功能，但是对于Component来说，是无需知道Decorator的存在的，至于ConcreteDecorator就是具体的装饰对象，起到给Component添加职责的功能。