《设计模式之禅》--摘要

Posted 嘉禾世兴

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了《设计模式之禅》--摘要相关的知识,希望对你有一定的参考价值。

No1:

单一职责原则提出了一个编写程序的标准,用“职责”或“变化原因”来衡量接口或类设计得是否优良,但是“职责”和“变化原因”都是不可度量的,因项目而异,因环境而异。

No2:

在类中调用其他类时务必要使用父类或接口,如果不能使用父类或接口,则说明类的设计已经违背了LSP原则

No3:

如果子类不能完整地实现父类的方法,或者父类的某些方法在子类中已经发生“畸变”,则建议断开父子继承关系,采用依赖、聚集、组合等关系代替继承。

No4:

子类方法的前置条件必须与超类中被覆写的方法的前置条件相同或者更宽松

No5:

依赖的三种写法

1)构造函数传递依赖对象

2)Setter方法传递依赖对象

3)接口声明依赖对象

No6:

根据接口隔离原则拆分接口时,首先必须满足单一职责原则。

No7:

迪米特法则要求类“羞涩”一点,尽量不要对外公布太多的public方法和非静态的public变量,尽量内敛,多使用private、package-private、protected等访问权限。

No8:

如果一个方法放在本类中,既不增加类间关系,也对本类不产生负面影响,那就放置在本类中

No9:

开闭原则对扩展开放,对修改关闭,并不意味着不做任何修改,低层模块的变更,必然要有高层模块进行耦合,否则就是一个孤立无意义的代码片段

No10:

抽象方法中已经不再需要传递相关参数了,因为每一个具体的工厂都已经非常明确自己的职责:创建自己负责的产品类对象

No11:

有N个产品族,在抽象工厂类中就应该有N个创建方法

有M个产品等级就应该有M个实现工厂类,在每个实现工厂中,实现不同产品族的生产任务

No12:

在软件开发过程中,如果相同的一段代码复制过两次,就需要对设计产生怀疑,架构师要明确地说明为什么相同的逻辑要出现两次或更多次

No13:

为了防止恶意的操作,一般模板方法都加上final关键字,不允许被覆写。

No14:

抽象模板中的基本方法尽量设计为protected类型,符合迪米特法则,不需要暴露的属性或方法尽量不要设置为protected类型。实现类若非必要,尽量不要扩大父类中的访问权限

No15:

要实现动态代理的首要条件是:被代理类必须实现一个接口,回想一下前面的分析吧。当然了,现在也有很多技术如CGLIB可以实现不需要接口也可以实现动态代理的方式

No16:

这种不通过new关键字来产生一个对象,而是通过对象复制来实现的模式就叫做原型模式

No17:

对象拷贝时构造函数确实没有被执行,这点从原理来讲也是可以讲得通的,Object类的clone方法的原理是从内存中(具体地说就是堆内存)以二进制流的方式进行拷贝,重新分配一个内存块,那构造函数没有被执行也是非常正常的了

No18:

使用原型模式时,引用的成员变量必须满足两个条件才不会被拷贝:一是类的成员变量,而不是方法内变量;二是必须是一个可变的引用对象,而不是一个原始类型或不可变对象

No19:

深拷贝和浅拷贝建议不要混合使用,特别是在涉及类的继承时,父类有多个引用的情况就非常复杂,建议的方案是深拷贝和浅拷贝分开实现

No20:

要使用clone方法,类的成员变量上不要增加final关键字

No21:

为什么同事类要使用构造函数注入中介者,而中介者使用getter/setter方式注入同事类呢?这是因为同事类必须有中介者,而中介者却可以只有部分同事类

No22:

在责任链模式中一个请求发送到链中后,前一节点消费部分消息,然后交由后续节点继续处理,最终可以有处理结果也可以没有处理结果,读者可以不用理会什么纯的、不纯的责任链模式。

No23:

在装饰模式中,必然有一个最基本、最核心、最原始的接口或抽象类充当Component抽象构件。

No24:

原始方法和装饰方法的执行顺序在具体的装饰类是固定的,可以通过方法重载实现多种执行顺序

No25:

策略枚举是一个非常优秀和方便的模式,但是它受枚举类型的限制,每个枚举项都是public、final、static的,扩展性受到了一定的约束,因此在系统开发中,策略枚举一般担当不经常发生变化的角色

No26:

开发系统时,迭代器的删除方法应该完成两个逻辑:一是删除当前元素,二是当前游标指向下一个元素

No27:

只要是树形结构,就要考虑使用组合模式,这个一定要记住,只要是要体现局部和整体的关系的时候,而且这种关系还可能比较深,考虑一下组合模式吧

No28:

组合模式有两种不同的实现:透明模式和安全模式。

透明模式是把用来组合使用的方法放到抽象类中,比如add()、remove()以及getChildren等方法,不管叶子对象还是树枝对象都有相同的结构,通过判断是getChildren的返回值确认是叶子节点还是树枝节点,如果处理不当,这个会在运行期出现问题,不是很建议的方式(解决方法是抛异常);

安全模式就不同了,它是把树枝节点和树叶节点彻底分开,树枝节点单独拥有用来组合的方法,这种方法比较安全

No29:

定义被观察者必须实现的职责,它必须能够动态地增加、取消观察者。它一般是抽象类或者是实现类,仅仅完成作为被观察者必须实现的职责:管理观察者并通知观察者。

No30:

观察者模式和责任链模式的最大区别就是观察者广播链在传播的过程中消息是随时更改的,它是由相邻的两个节点协商的消息结构;而责任链模式在消息传递过程中基本上保持消息不可变,如果要改变,也只是在原有的消息上进行修正

No31:

在对象池中,对象一旦产生,必然有一个唯一的、可访问的状态标志该对象,而且池中的对象声明周期是由池容器决定,而不是由使用者决定的

No32:

在程序开发中,确认只需要一次赋值的属性则设置为final类型,避免无意修改导致逻辑混乱,特别是Session级的常量或变量

No33:

如果把一个对象作为Map类的键值,一定要确保重写了equals和hashCode方法,否则会出现通过键值搜索失败的情况,例如map.get(object)、map.contains(object)等会返回失败的结果

No34:

dos窗口命令nslookup--查看域名对应的IP地址

No35:

设计原则只是一个理论,而不是一个带有刻度的标尺,因此在系统设计中不应该把它视为不可逾越的屏障,而是应该把它看成是一个方向标,尽量遵守,而不是必须恪守

No36:

拦截器是会影响系统性能的,所有的Action在执行前后都会被拦截器过滤一遍,即使不符合拦截条件的也会被检查一遍,所以非必要情况不要使用拦截器。

No37:

父类依赖子类的情景只有在非常明确不会发生变化的场景中存在,它不具备扩展性,是一种固化而不可变化的结构。

以上是关于《设计模式之禅》--摘要的主要内容,如果未能解决你的问题,请参考以下文章

《设计模式之禅》--策略扩展:策略枚举

《设计模式之禅》--代理扩展:强制代理

《设计模式之禅》--代理扩展:动态代理

设计模式之禅-设计准则

《设计模式之禅》Strategy_Pattern--策略模式

《设计模式之禅》--空对象模式