这是我看的第一本设计模式,由于觉得个人代码量不多,一直没有看,现在也只是了解为主,平时稍加注意,过一两年再详细研究。由于本人粗心大意,写在word里没有保存我就重装系统。。。这里只记下了下半部分。
《设计模式之禅》这本书,讲的还是比较浅显易懂,这种java这种强类型语言,讲究封装和继承,用于讲解设计模式再合适不过了。例子引入对于初学者而言还是挺不错的,可惜后文讲解有点流于表面了。下面我就贴出笔记。
#装饰模式(Decorator Pattern)
动态的给一个对象添加职责,就增加功能来说,装饰模式比生成子类更加灵活.装饰类是对兄弟类(均继承自同一个最原始,需要被修改的abstract class)的一种修饰或者说是补充,可以有多个ConcreteDecorator class 每个具体负责一类修饰原则,修饰后的具体原始类作为下一个类的输入,需要有一个私有属性表示待修饰的对象,同时显式调用父类方法,层层修饰,层层调用父类方法,就将整个修饰链运作起来.
特点:
#策略模式(Strategy Pattern)
定义一组算法,并将它们封装起来,使之可以互换.将每个算法,或者说策略封装起来,屏蔽高层模块(避免场景中显示调用)直接访问,比如计算器,可以将加减乘除法进行各自封装成Class,在Context类中进行调用,这是调用策略的入口.
和代理模式非常相同,但是区别在于,策略模式的封装角色和被封装角色 不是同一个接口(???how to understand interface here.)
#适配器模式(Adapter Pattern)
将一个类的接口变换成客户端所期待的另一个接口,从而使原本因接口不匹配而无法在一起工作的两个类一起工作.分为对象适配器和类适配器,前者通过对象联合实现(引用其他对象),后者通过继承.
#迭代器模型(Iterator Pattern)
它提供一种方法,访问容器中的内容,而不暴露容器内的细节.个人理解为把foreach转换成一种OOP化的编程,在具体类中,容器作为构造函数参数,初始化迭代器,迭代器遍历容器.
#组合模式(Composite Pattern)
将对象组合成树形结构以表示"部分-整体"的层次结构,使得用户对单个对象或组合对象的使用一致.个人理解:原本平行的对象,可以抽象成树形结构,这样这些对象可以提取出抽象类,同相同的接口处理诸多对象.分为透明的(组合使用的方法放到抽象中)和不透明的,前者可以减少类型转换(通用吗?How?)
#观察者模式(Observer Pattern)
Define a one-to-many dependency between object so that when one object changes state,all its dependents are notified and updated automatically.在被观察者中,定义有自己的状态监听者,一旦状态改变则显示调用监听者,通知其处理,如果需要返回结果,可能造成整个处理链过长,可以采用异步或者缓存(预先开辟资源)
#门面模式(Facade Pattern)
要求一个子系统的外部与其内部的通信必须通过统一的对象进行.门面模式提供了一个高层次的借口,使子系统易于使用.个人理解:封装子系统的内部逻辑,理解为调用该系统的API,注意接口不要包含子系统的业务逻辑,否则造成子系统对接口的依赖,这是不合理的,要保证子系统对外的完全的隐藏.
#备忘录模式(Memento Pattern)
Without violating encapsulation, capture and externalize an object`s internal state so that the object can be restored to this state later.通俗讲,将一个对象的状态保存起来,以便恢复.单独的备忘录类(甚至保存多个状态,clone或者遍历对象,放入Map,指定Key以区别它们) ,备忘录管理类.该模式的核心在于需要一个保存以前状态的Map或者Array.
#访问者模式(Visitor Pattern)
封装某种作用于数据结构中的一些操作,它可以在不改变现有数据结构的前提下,定义新的操作.一个访问者类,一个被访问者类,关键点在于被访问者有一个设置访问者的借口,在接口内: Visitor.visit(this); Visitor是该接口的参数,这样能在访问者中得到被访问者的内部结构,因此这也是访问者模式的一个弊病:访问者知道被访问者的内部结构.迭代器模式只能访问同类或者同接口的对象,访问者模式可以遍历不同对象,这也是访问者模式重要用途之一.对迭代器模式的有效补充.
#状态模式(State Pattern)
当一个对象内的状态改变时,允许其行为改变,这个对象看起来好像改变了其类.一个对象可以在不同状态间转换,以改变其动作,不使用设计模式时,需要一大堆if/else或者switch/case语句,根据当前状态判断下一步动作.现在将个个状态封装成类,继承自同一个接口,重写每个状态下能够执行的动作,这样就替代了状态判断语句.动作的执行交给Context类,每个状态类有一个受保护的属性 _context = new Context(),某个状态执行动作时,设置新通过_context设置新装,_context.state.handle(),真正的执行者在Context类里面.
状态模式改变程序结构,消除if/switch语句,可维护性提高.封装良好.动态扩展状态类;容易造成状态类膨胀.
#解释器模式(Interpreter Pattern)
给定一门语言,定义它的文法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中的例子.比如字符串计算式(采用堆栈)
#享元模式(Flyweight Pattern)
Use sharing to support large number of fine-grained objects effectively.将数量众多的对象,提取共有属性,以属性作为key(多个属性的话就排列组合),对象作为值,放在池中,额外属性在赋值.这里需要注意,池中的对象是复用的,也就是说在高并发情况下,不同请求很可能访问相同的对象,造成数据被篡改.需要生成足以支持业务数量的对象个数,根据实际情况而定.
#桥梁模式(Bridge Pattern)
将抽象与现实解耦,使得两者可以独立的变化.怎样结构抽象和现实?抽象和现实怎么理解?I don`t know.抽象角色引用实现角色,具体动作有实现角色去做.