From 0967a9ab23771596ee3122e92fab321d8f122066 Mon Sep 17 00:00:00 2001 From: CyC2018 <1029579233@qq.com> Date: Fri, 16 Mar 2018 23:38:49 +0800 Subject: [PATCH] auto commit --- notes/设计模式.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/notes/设计模式.md b/notes/设计模式.md index cdfec950..aaa3427b 100644 --- a/notes/设计模式.md +++ b/notes/设计模式.md @@ -51,15 +51,15 @@ **4. 设计原则** -**封装变化** 在这里变化的是鸭子叫和飞行的行为方式。 +封装变化 ：在这里变化的是鸭子叫和飞行的行为方式。 -**针对接口编程，而不是针对实现编程** 变量声明的类型为父类，而不是具体的某个子类。父类中的方法实现不在父类，而是在各个子类。程序在运行时可以动态改变变量所指向的子类类型。 +针对接口编程，而不是针对实现编程 ：变量声明的类型为父类，而不是具体的某个子类。父类中的方法实现不在父类，而是在各个子类。程序在运行时可以动态改变变量所指向的子类类型。 运用这一原则，将叫和飞行的行为抽象出来，实现多种不同的叫和飞行的子类，让子类去实现具体的叫和飞行方式。

-**多用组合，少用继承** 组合也就是 has-a 关系，通过组合，可以在运行时动态改变实现，只要通过改变父类对象具体指向哪个子类即可。而继承就不能做到这些，继承体系在创建类时就已经确定。 +多用组合，少用继承：组合也就是 HAS-A 关系，通过组合，可以在运行时动态改变实现，只要通过改变父类对象具体指向哪个子类即可。而继承就不能做到这些，继承体系在创建类时就已经确定。 运用这一原则，在 Duck 类中组合 FlyBehavior 和 QuackBehavior 类，performQuack() 和 performFly() 方法委托给这两个类去处理。通过这种方式，一个 Duck 子类可以根据需要去初始化 FlyBehavior 和 QuackBehavior 的子类对象，并且也可以动态地进行改变。 @@ -71,7 +71,7 @@ **6. 模式定义** -**策略模式** 定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。 +策略模式：定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。 **7. 实现代码** @@ -202,7 +202,7 @@ FlyBehavior.FlyNoWay **5. 设计原则** -**为交互对象之间的松耦合设计而努力** ：当两个对象之间松耦合，它们依然可以交互，但是不清楚彼此的细节。由于松耦合的两个对象之间互相依赖程度很低，因此系统具有弹性，能够应对变化。 +为交互对象之间的松耦合设计而努力：当两个对象之间松耦合，它们依然可以交互，但是不清楚彼此的细节。由于松耦合的两个对象之间互相依赖程度很低，因此系统具有弹性，能够应对变化。 **6. 实现代码** @@ -334,7 +334,7 @@ StatisticsDisplay.update:1.0 1.0 1.0 **5. 设计原则** -**类应该对扩展开放，对修改关闭。** 也就是添加新功能时不需要修改代码。在本章问题中该原则体现在，饮料可以动态添加新的配料，而不需要去修改饮料的代码。观察则模式也符合这个原则。不可能把所有的类设计成都满足这一原则，应当把该原则应用于最有可能发生改变的地方。 +类应该对扩展开放，对修改关闭：也就是添加新功能时不需要修改代码。在本章问题中该原则体现在，饮料可以动态添加新的配料，而不需要去修改饮料的代码。观察则模式也符合这个原则。不可能把所有的类设计成都满足这一原则，应当把该原则应用于最有可能发生改变的地方。 **6. Java I/O 中的装饰者模式** @@ -513,7 +513,7 @@ PizzaStore 有 orderPizza() 方法，顾客可以用它来下单。下单之后 **5. 设计原则** -**依赖倒置原则** ：要依赖抽象，不要依赖具体类。听起来像是针对接口编程，不针对实现编程，但是这个原则说明了：不能让高层组件依赖底层组件，而且，不管高层或底层组件，两者都应该依赖于抽象。例如，下图中 Pizza 是抽象类，PizzaStore 和 Pizza 子类都依赖于 Pizza 这个抽象类。 +依赖倒置原则：要依赖抽象，不要依赖具体类。听起来像是针对接口编程，不针对实现编程，但是这个原则说明了：不能让高层组件依赖底层组件，而且，不管高层或底层组件，两者都应该依赖于抽象。例如，下图中 Pizza 是抽象类，PizzaStore 和 Pizza 子类都依赖于 Pizza 这个抽象类。

@@ -1052,7 +1052,7 @@ gobble! **5. 设计原则** -**最少知识原则** ：只和你的密友谈话。也就是客户对象所需要交互的对象应当尽可能少。 +最少知识原则：只和你的密友谈话。也就是客户对象所需要交互的对象应当尽可能少。 **6. 代码实现** @@ -1086,7 +1086,7 @@ prepareRecipe() 方法就是模板方法，它确定了其它四个方法的具 **5. 设计原则** -**好莱坞原则** ：别调用（打电话给）我们，我们会调用（打电话给）你。这一原则可以防止依赖腐败，即防止高层组件依赖低层组件，低层组件又依赖高层组件。该原则在模板方法的体现为，只有父类会调用子类，子类不会调用父类。 +好莱坞原则：别调用（打电话给）我们，我们会调用（打电话给）你。这一原则可以防止依赖腐败，即防止高层组件依赖低层组件，低层组件又依赖高层组件。该原则在模板方法的体现为，只有父类会调用子类，子类不会调用父类。 **6. 钩子** @@ -1787,7 +1787,7 @@ No gumball dispensed # 与设计模式相处 -定义：在某 **情境** 下，针对某 **问题** 的某种 **解决方案**。 +定义：在某情境下，针对某问题的某种解决方案。 过度使用设计模式可能导致代码被过度工程化，应该总是用最简单的解决方案完成工作，并在真正需要模式的地方才使用它。