【前言】
做了几个可大可小的项目,或多或少的接触了代码复用,代码解耦,代码高扩展等一系列优秀的代码的实用性,提高了代码的可读性,可扩展性,维护成本,复杂的业务问题。而我们生活上也是如此,如果一件事情,总要不断重复去做,虽然我们可以把事情做好,但是总是杂乱无章,这不免会浪费我们的时间成本,对生活深度分析,并且用代码实现这种思想,不断思考,思想与代码并驾齐驱,灵活运用设计模式,理清应该有的脉络,才更加有趣。最近在设计模式之禅里面看到作者提了一系列问题来引入学习设计模式的历程:这个定义是这样吗?是应该用抽象类还是用接口?为什么在这里不能抽取抽象呢?为什么在项目中这个模式要如此蜕化?相信我们都会有这样的疑问,这篇博客,我们拿出来几个典型的模式来做一下。
【六大原则】
单一职责原则:一个接口只干一件事情,例如一个接口定义了拨通电话和通话以及挂电话三个方法,
如果是按照打
电话这件事情来说,这三个方法可以放到一个接口中,如果按照另一种方式解释的话:它可以包含
两个职责:协议管理以及数据传送,通话为数据传送,拨通电话和挂电话为协议管理。
里氏转化原则:只要父类能出现的地方子类就可以出现,而且替换为子类也不会出现任何错误或异
常,使用者可能根本不需要知道是父类还是子类。但是,反过来就不行了,有子类出现的地方,
父类未必就能适应。
依赖倒置原则:模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是
通过接口活抽象类产生的;接口或抽象类不依赖于实现类;实现类依赖接口或抽象类。
接口隔离原则:建立单一接口,不建立臃肿庞大的接口。在符合单一职责原则上,进行接口隔离
原则。
迪米特法则:我的知识,你知道的越少越好 、
开闭原则:对扩展开发,对修改关闭
【简单工厂,工厂方法,抽象工厂】
简单工厂核心代码:
public class SimpleFactory {
public Milk getMilk(String name){
if("特仑苏".equals(name)){
return new Telunsu();
}else if("伊利".equals(name)){
return new Yili();
}else if("蒙牛".equals(name)){
return new Mengniu();
}else {
System.out.print