diff --git a/docs/content/design_pattern/bridge.md b/docs/content/design_pattern/bridge.md index 15e23e9..14d2b22 100644 --- a/docs/content/design_pattern/bridge.md +++ b/docs/content/design_pattern/bridge.md @@ -1,12 +1,12 @@ # 桥接模式 -## 问题引入 +## 模式引入 ### 问题描述 对于不同品牌的手机，软件基本无法兼容。因此如果手机需要增加软件，就需要针对不同品牌的手机分别实现软件功能。 -### **模式定义** +### 模式定义 桥接模式是将抽象部分与其实现部分分离，使它们都可以独立地变化。 @@ -24,21 +24,24 @@ 包括以下四个角色： -1.Abstraction(抽象类)：用于定义抽象类的接口，其中定义了一个具有关联关系的Implementor的对象。 - -2.RefinedAbstraction(扩充抽象类)：继承并实现抽象类中的接口，并在其中调用Implementor对象的相关业务方法。 - -3.Implementor(实现类)：用于定义实现类的接口，提供基本的业务方法供抽象类调用，以完成复杂的操作。 - -4.ConcreteImplementor(具体实现类)：继承并实现Implementor的接口，在不同的具体实现类中提供不同的操作方法，通过向上转型的方式完成方法的调用。 +- Abstraction（抽象类）：用于定义抽象类的接口，其中定义了一个具有关联关系的Implementor 的对象。 +- RefinedAbstraction（扩充抽象类）：继承并实现抽象类中的接口，并在其中调用Implementor 对象的相关业务方法。 +- Implementor（实现类）：用于定义实现类的接口，提供基本的业务方法供抽象类调用，以完成复杂的操作。 +- ConcreteImplementor（具体实现类）：继承并实现 Implementor 的接口，在不同的具体实现类中提供不同的操作方法，通过向上转型的方式完成方法的调用。 ### 代码实现 +`HandsetSoft` 实现类： + ```java public abstract class HandsetSoft { public abstract void run(); } +``` + +`HandsetSoft` 具体实现类： +```java public class HandsetGame extends HandsetSoft { @Override public void run() { @@ -52,7 +55,11 @@ public class HandsetAddressList extends HandsetSoft { System.out.println("运行手机通讯录"); } } +``` + +`HandsetBrand` 抽象类： +```java public abstract class HandsetBrand { protected HandsetSoft soft; @@ -62,7 +69,11 @@ public abstract class HandsetBrand { public abstract void run(); } +``` +`HandsetBrand` 扩展抽象类： + +```java public class HandsetBrandM extends HandsetBrand { @Override public void run() { @@ -76,7 +87,11 @@ public class HandsetBrandN extends HandsetBrand { soft.run(); } } +``` +`Main` 方法： + +```java public class Main { public static void main(String[] args) { HandsetBrand ab; @@ -99,33 +114,40 @@ public class Main { } ``` -### **结构**组成 +执行结果： -![image-20221017164911912](img/bridge/bridge.JPG) - -## 模式评价 +```bash +运行手机游戏 +运行手机通讯录 +运行手机游戏 +运行手机通讯录 +``` -**适合场景** +### 结构组成 -1.对于使用较多类继承问题而导致紧耦合、扩展性差的系统。 +![image-20221017164911912](img/bridge/bridge.JPG) -2.对于存在多个独立变化并需要灵活扩展维度的需求。 +## 模式评价 -**实际应用** +### 适合场景 -1.JDBC 规范和不同数据库厂商驱动的实现 +- 对于使用较多类继承问题而导致紧耦合、扩展性差的系统。 +- 对于存在多个独立变化并需要灵活扩展维度的需求。 -2.spring中可以根据客户的需求能够动态切换不同的数据源。 +### 实际应用 -3.Nginx的模块架构就应用了桥接模式，使用了nginx_module_t定义模块，结构体里有若干函数指针和扩展字段，然后桥接实现了丰富多彩的core、conf、event、stream、http等功能模块，搭建起整个Nginx框架。 +- JDBC 规范和不同数据库厂商驱动的实现。 +- Spring 中可以根据客户的需求能够动态切换不同的数据源。 +- Nginx 的模块架构就应用了桥接模式，使用了`nginx_module_t` 定义模块，结构体里有若干函数指针和扩展字段，然后桥接实现了丰富多彩的 core、conf、event、stream、http 等功能模块，搭建起整个 Nginx 框架。 -**模式优点** +### 优点缺点 -1.避免了继承导致的类爆炸问题 +模式优点： -2.具备灵活的可扩展性 +- 避免了继承导致的类爆炸问题。 +- 具备灵活的可扩展性。 -**模式缺点** +模式缺点： -将抽象和实现分离会增加设计的难度 +- 将抽象和实现分离会增加设计的难度。 diff --git a/docs/content/design_pattern/chain_of_responsibility.md b/docs/content/design_pattern/chain_of_responsibility.md index 663cb06..d599f23 100644 --- a/docs/content/design_pattern/chain_of_responsibility.md +++ b/docs/content/design_pattern/chain_of_responsibility.md @@ -1,6 +1,6 @@ # 职责链模式 -## 问题引入 +## 模式引入 ### 问题描述 @@ -14,7 +14,7 @@ 如果将管理者创建成为一个类，那么该类会具有太多的责任，比如经理、总监以及总经理的审批和上报功能，就违背了单一职责原则。而且以后的需求可能会增加新的管理类别，比如项目经理、部门经理、人事总监等，那么就势必会修改管理者类以完成扩展，就违背了开放封闭原则。 -## 模式介绍 +## 模式实现 ### 解决方案 @@ -26,22 +26,43 @@ ConcreteHandler(具体处理者类)：处理它所负责的请求，可访问它 ### 代码实现 +`Request` 类： + ```java -public abstract class Manager { - protected String name; - protected Manager superior; +public class Request { + private String requestType; + private String requestContent; + private int number; - protected Manager(String name) { - this.name = name; + public String getRequestType() { + return requestType; } - public void SetSuperior(Manager superior) { - this.superior = superior; + public void setRequestType(String requestType) { + this.requestType = requestType; } - public abstract void requestApplications(Request request); + public String getRequestContent() { + return requestContent; + } + + public void setRequestContent(String requestContent) { + this.requestContent = requestContent; + } + + public int getNumber() { + return number; + } + + public void setNumber(int number) { + this.number = number; + } } +``` +`Manager` 类： + +```java public abstract class Manager { protected String name; protected Manager superior; @@ -56,7 +77,11 @@ public abstract class Manager { public abstract void requestApplications(Request request); } +``` +`ConcreteManager` 类： + +```java public class GeneralManager extends Manager { protected GeneralManager(String name) { super(name); @@ -91,36 +116,27 @@ public class MajorDemo extends Manager { } } -public class Request { - private String requestType; - private String requestContent; - private int number; - - public String getRequestType() { - return requestType; - } - - public void setRequestType(String requestType) { - this.requestType = requestType; - } - - public String getRequestContent() { - return requestContent; - } - - public void setRequestContent(String requestContent) { - this.requestContent = requestContent; - } - - public int getNumber() { - return number; +public class MajorDemo extends Manager { + protected MajorDemo(String name) { + super(name); } - public void setNumber(int number) { - this.number = number; + @Override + public void requestApplications(Request request) { + if(request.getRequestType() == "请假" && request.getNumber() <= 5) { + System.out.println(name + "：" + request.getRequestContent() + " 数量" + request.getNumber() + " 被批准" ); + }else { + if(superior != null) { + superior.requestApplications(request); + } + } } } +``` + +`Main` 方法： +```java public class Main { public static void main(String[] args) { CommonManager jinli = new CommonManager("金利"); @@ -154,42 +170,45 @@ public class Main { jinli.requestApplications(request4); } } +``` + +执行结果： +```bash +金利：小菜请假 数量1 被批准 +宗剑：小菜请假 数量4 被批准 +钟精励：小菜请求加薪 数量500 被批准 +钟精励：小菜请求加薪 数量1000 再说吧 ``` -### **结构**组成 +### 结构组成 ![image-20221017164911912](img/chain_of_responsibility/chain_of_responsibility.JPG) -## 使用场景 +## 模式评价 -**适合场景** +### 适用场景 一个请求有多个对象可以处理，但每个对象的处理条件或权限不同。 -**实际应用** - -1.netty中Pipeline与ChannelHandler通过责任链来组织代码逻辑。 - -2.tomcat中servlet过滤器使用了责任链模式。 - -3.spring中切面编程和安全机制都使用了责任链模式。 - -## 模式评价 - -**模式优点** +### 实际应用 -1.能够简化对象的相互连接，接收者和发送者都没有对方的明确信息，且链中的对象也不知道链的结构。 +- Netty 中 Pipeline 与 ChannelHandler 通过责任链来组织代码逻辑。 +- Tomcat 中 Servlet 过滤器使用了责任链模式。 +- Spring 中切面编程和安全机制都使用了责任链模式。 -2.避免了请求的发送者和接受者之间的耦合关系。 +### 优点缺点 -3.能够随时修改请求的结构，增强了给对象指派职责的灵活性 +模式优点： -**模式缺点** +- 能够简化对象的相互连接，接收者和发送者都没有对方的明确信息，且链中的对象也不知道链的结构。 +- 避免了请求的发送者和接受者之间的耦合关系。 +- 能够随时修改请求的结构，增强了给对象指派职责的灵活性 -1.请求可能到了链的末端都得不到处理，或者因为没有正确配置得不到处理。 +模式缺点： -2.较长的责任链可能会影响到系统的性能。 +- 请求可能到了链的末端都得不到处理，或者因为没有正确配置得不到处理。 +- 较长的责任链可能会影响到系统的性能。 diff --git a/docs/content/design_pattern/composite.md b/docs/content/design_pattern/composite.md index e64f5af..1223c4a 100644 --- a/docs/content/design_pattern/composite.md +++ b/docs/content/design_pattern/composite.md @@ -1,6 +1,6 @@ # 组合模式 -## 设计动机 +## 模式引入 ### 问题描述 diff --git a/docs/content/design_pattern/mediator.md b/docs/content/design_pattern/mediator.md index 317f268..548f63e 100644 --- a/docs/content/design_pattern/mediator.md +++ b/docs/content/design_pattern/mediator.md @@ -1,6 +1,6 @@ # 中介者模式 -## 问题引入 +## 模式引入 ### 问题描述 @@ -14,7 +14,7 @@ 将系统分割成许多对象通常可以增加其复用性，但是对象之间大量的连接又使得对象之间的耦合性更强，导致对系统的行为进行较大的改动就比较困难。 -## 模式介绍 +## 模式实现 ### 解决方案 @@ -30,32 +30,127 @@ ConcreteColleague(具体同时类)：每个具体同事只知道自己的行为 ### 代码实现 +`Mediator` 类： + +```java +abstract class Mediator { + //定义一个抽象的发送消息方法，得到同事对象和发送消息 + public abstract void send(String message,Colleague colleague); +} +``` + +`ConcreteMediator` 类： + +```java +public class ConcreteMediator extends Mediator{ + public ConcreteColleague1 concreteColleague1; + public ConcreteColleague2 concreteColleague2; + + public void setColleague1(ConcreteColleague1 value){ + this.concreteColleague1 = value; + } + public void setColleague2(ConcreteColleague2 value){ + this.concreteColleague2 = value; + } + @Override + public void send(String message, Colleague colleague) { + if(colleague == concreteColleague1){ + concreteColleague2.notify(message); + }else{ + concreteColleague1.notify(message); + } + } +} +``` + +`Colleague` 类： + +```java +public class Colleague { + protected Mediator mediator; + // 构建方法，得到中介者对象 + public Colleague(Mediator mediator){ + this.mediator = mediator; + } +} +``` + +`ConcreteColleague` 类： + +```java +public class ConcreteColleague1 extends Colleague { + public ConcreteColleague1(Mediator mediator) { + super(mediator); + } + public void send(String message){ + this.mediator.send(message,this); + } + public void notify(String message){ + System.out.println("同事1得到信息:"+message); + } +} + +public class ConcreteColleague2 extends Colleague { + public ConcreteColleague2(Mediator mediator) + { + super(mediator); + } + public void send(String message) + { + this.mediator.send(message,this); + } + public void notify(String message) + { + System.out.println("同事2得到信息:"+message); + } +} +``` + +`Main` 方法： + ```java +public class main { + public static void main(String[] args){ + ConcreteMediator m =new ConcreteMediator(); + ConcreteColleague1 c1 = new ConcreteColleague1(m); + ConcreteColleague2 c2 = new ConcreteColleague2(m); + m.setColleague1(c1); + m.setColleague2(c2); + c1.send("吃过饭了吗？"); + c2.send("没有呢，你打算请客？"); + } +} +``` +执行结果： + +```bash +同事2得到信息:吃过饭了吗？ +同事1得到信息:没有呢，你打算请客？ ``` -### **结构组成** +### 结构组成 ![image-20221017164911912](img/mediator/mediator.JPG) ## 模式评价 -**适合场景** +### 适合场景 中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合。以及想定制一个分布在多个类中的行为，而又不想生成太多的子类的场合。 -**实际应用** +### 实际应用 nginx_http_upstream_module里定义的upstream框架就是中介者模式（同时也应用了模板模式），它协调load-balance模块和upstream模块共同工作，获取上游服务器的地址，然后转发下游的请求和上游的响应数据。 -**模式优点** - -中介者减少了各个业务类的耦合，使得可以独立的改变和复用各个业务类和中介者类。 +### 优点缺点 -中介者的实现类控制了集中化，把对象群交互的复杂性变为中介者的复杂性。 +模式优点： -当系统出现多对多交互复杂的对象群，可以考虑使用中介这模式。 +- 中介者减少了各个业务类的耦合，使得可以独立的改变和复用各个业务类和中介者类。 +- 中介者的实现类控制了集中化，把对象群交互的复杂性变为中介者的复杂性。 +- 当系统出现多对多交互复杂的对象群，可以考虑使用中介这模式。 -**模式缺点** +模式缺点： -中介者对象会较为复杂 \ No newline at end of file +- 中介者对象会较为复杂。 \ No newline at end of file diff --git a/homework/hw1.md b/homework/hw1.md new file mode 100644 index 0000000..e69de29 diff --git a/homework/hw2.md b/homework/hw2.md new file mode 100644 index 0000000..e69de29