设计模式这个东西,永远不是单单从书本上就能获取到的东西.曾经看到一个比喻,比喻的就很巧妙,文艺复兴时期的教学方式,那时候诞生了很多巨匠,达芬奇,莫开朗基罗,拉斐尔都是在这个时期绽放光芒的巨星.有一种说法是当时的教学方式和今天的不同,那时候采取的是小作坊中师徒相授,口耳相传的方式来实现知识的传递,但是,在当下的如今,这种学习方式已然被世人所遗忘.
经济学上个世纪有一句话真的很有道理,反对黑板上的经济学,但是现在...我们是否依然在黑板上呢.
先随便聊聊吧,相对于代码开发过程中,重构的过程其实更加有趣,因为总有一种化腐朽于神奇的感觉,有一种智力上的优越感.
记得以前,学习设计模式是通过闫宏博士的"java与模式"一书中粗略地了解,但是越到代码开发阶段,其中的想法就越深入人心.一如既往,我并不希望罗列案例,我依然希望透过现象看本质,为什么通过这样那样的设计模式能够提高的代码的复用率,能够让我们在代码维护阶段能够更省力并且不会顾此失彼,改掉一个bug又出现一个新的bug.
1.策略模式:定义的方法族,分别封装起来.让他们之间可以互相替换,此模式让算法的变化独立于使用算法的客户.
该模式主要为开闭原则服务,为了让已经封装好的类不再被人反复鞭尸,所以需要把变化的部分(常常为随着需求变化的行为)进行封装.
首先定义特征接口,将变化的行为使用重构的方法先进行分类,将方法和方法解耦,由此分离出多个不同的行为.为每个行为定义一个抽象的接口或抽象类,这里使用接口或许更加合适,毕竟java是基于单继承模型的这样一种语言.
在类的初始化的时候,将实例化的接口传入,在需要执行行为的时候使用接口所定义的方法,策略模式就完成了.
2.观察者模式:在对象之间定义一对多的依赖,这样一来,当一个对象改变状态,依赖他的对象都会接到通知
主要目的是为了解耦,关键两个接口为Observable和Observer,分别对应订阅者和被订阅者.
核心思想是Observer中定义了响应Observable中监控的对象变化时,Observer所执行的响应方法.Observable通过List之类的数据结构来管理订阅的Observer列表.
3.装饰者模式:动态地将责任附加到对象上.想要扩展功能,装饰者提供有别于继承的另一种选择.
这个模式和继承有着很微妙的孽缘,举个例子吧:你进到一家奶茶店里面去买奶茶,那么问题来了,奶茶店里到底该如何管理各种配方的类呢?这里正常人会想到两个方案,
一.使用继承的方式,在父类中添加两个方法,获取组成成分和获取价格,然后让子类去实现他们.这样的方法会出现以下问题:
类爆炸,每一种配方都需要特地去添加一个全新的类,到最后会按照排列组合的数据增长速度来增加类的个数,类的"空间复杂度 过高"
二.存在一堆行为的重复逻辑,这部分逻辑不能很好的复用所以一旦逻辑出现问题,就会导致项目的大幅度改动
基于此,装饰者模式提供了一个全新的思路,也就是继承的另外一个使用手法,通过同时使用"组合和继承"的方式实现"配方的复用问题",也就是基于已经实现的装饰来进一步实现下一步装饰操作.
isA和hasA真的是很得当的比喻.
4.简单工厂模式(静态工厂模式):
简单工厂模式是通过在类中定义静态方法的方式进行类的创建过程，当然，因为是使用静态方法的原因，就缺乏了多态和继承的拓展性。但是这种方法真的很直观，而且在很多场合下，并不非要使用继承的方式来构造项目，割鸡焉用牛刀呢。
5.工厂方法模式和抽象工厂模式，这两个设计模式因为名称挺像，所以很容易弄混的样子
工厂方法模式：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟刀子类。
常常听到其他开发人员说：工厂方法让子类决定要实例化的类是哪一个。所谓的“决定”，并不是指模式允许子类本身在运行时做决定，而是指在编写创建者时不需要知道实际创建的产品是哪一个。选择使用了哪一个子类，自然就决定了实际创建的产品是什么。
抽象工厂模式：定义了一个接口，用于创建爱你相关或依赖对象的家族，而不需要明确指定具体类。
这两个类其实最大的区别就是工厂方法模式更关心具体的产品的创建，但是抽象工厂模式更关心工厂的构成和结构。而且往往抽象工厂的继承树和实际的产品树有几分神似。
