设计模式在系统分析和设计的阶段非常的重要,学习设计模式的目的是为了能够结合具体的需求写出复用可扩展的代码.个人觉得在学习设计模式的过程中,不必拘泥于记忆特定的UML结构,主要在于理解各个角色直接的联系,及其解决的应用场景.同样设计模式也不可生搬硬套,结合具体的需求场景可以做些相应的修改. 介绍以下几种设计模式之前,先来了解一下面相对象的几个设计原则:
依赖倒转原则: 以前的面相过程的开发模式,都是上层api依赖于底层的api,上层接口通常表达的业务及模型,底层的接口则更多的侧重于与计算机底层的交互,这样的缺点是依赖于具体,程序不稳定. 而依赖倒转的原则说的就是将上述这种依赖反过来, 让具体的实现依赖于上层的抽象,上层的抽象再依赖于更高层的抽象,这样的关系更为稳定,因为在一个领域内概念是稳定的,即抽象也是稳定的.
开闭原则: 好的面相对象的软件应该是 对修改是关闭的,对扩展是开放的
接口隔离原则: 也叫接口最小化原则. 接口即规范,是对客户端的承诺. 如果所包含的承诺越多,所要履行的职责也就越多. 定义接口时,应根据客户端的接口需求,反复斟酌提炼接口定义,而不是想到什么就添加什么,接口定义是需要反复思考的.
以下分别介绍一些常见的设计模式,这也是我在阅读<<java与模式>>一书中的读书笔记. 书还未读完,后续会加以补充..
适配器模式
1.分为类适配器模式和对象适配器模式，前者利用继承实现，后者利用组合实现。
2. 实现原理都是 通过定义好通用的接口规范，委托已有实现，实现客户端要的接口形式，因组合优于继承，推荐使用对象适配模式
合成模式
1. 是结构类的一种设计模式，通过统一接口的方式来使得客户端平等对待对象的组成部分
2. 主要有三个角色： component(对组成部分的高度抽象，是一个中间层的角色，提供客户端所需方法)； composit（“树枝”节点组合“组件”）；leaf（最小的组成单元，由于平等对待，也实现component接口）
2.根据实现的不同分为安全类型的合成模式和透明类型的合成模式，前者将“树枝”和“树叶”区分对待, 将访问集合的一些方法（addChild（）等）放在composit（树枝节点中）, 而不放在“树叶”节点中，component接口中只定义一些客户端期望的方法即可； 而后者对“树枝”和“树叶”角色平等对待，都继承至统一的抽象类，访问集合一些方法都规定在component 抽象类中。
3. 适用于一些递归的场景中。整体和部分从抽象的角度上来说是一致的，可以想到的一个例子是：假设有一个大盒子，由很多的小盒子组成，如果想要将这个大盒子装满的话，其实就是将每一个小盒子装满，如果对大盒子和小盒子适当的抽象下的话，其实它们都是可装东西的构件（component），所以说实现的时候可以定义一个包含客户端所需的方法的抽象类（component），里面包含一个“装东西”的方法，那么如果调用composit 的“装东西”的方法时，迭代调用composit中包含组件的” 装东西方法“即可。--例子也是临时想的，可能不太到位。。
工厂模式
工厂其实是把客户端代码中依赖于具体实现的代码隔离到具体的工厂中, 避免了客户端代码中违反依赖倒转的行为,即new 后跟具体实现类的代码. .工厂模式分为以下三中:
简单工厂(静态工厂): 根据客户端情况,生产具体的产品类,需要一个抽象产品作为返回值, 优点是结构简单,无论产品的结构怎么变,只需要根据约定修改工厂类即可.
工厂方法: 其实就是在简单工厂的基础上,将工厂具体类抽象了一下,每个具体的工厂类生产特定的具体产品.
抽象工厂: 适用于生产一套产品,而这一套产品中的产品之间存在某种约束规则,规定抽象工厂类,在抽象工厂中定义要生产的所有产品,再定义组装者,在组装者中聚合抽象的工厂类,组装者委托抽象的工厂类提取这一套产品中的各个产品进行组装,这样的好处是保证了这一套产品中各个产品之间的约束关系.举个例子.假设要生产一台电脑,并且
这台电脑A规格的cpu就不能配B规格的主板只能配相同规格的主板,那在这种情况下,如果使用简单的工厂模式为每一个组件分别定义一个工厂类的话,那么就有可能出现 A规格cpu配B规格的主板的情况. 转变思路,为一个组成相对稳定的产品规定一个抽象的工厂类就保证了生产出来的各个组件的规格都是相同的. 因为在实例化抽象类的时候,已经统一指定了每个构件的规格,保证了每个组件的规格一致. 以上的这一点我觉得应该是抽象工厂设计的初衷.
单例模式： 分为懒汉和饿汉模式，区别就在于懒汉请求时才实例化，而饿汉则是初始化时就已经实例化（final static ClassName a= xxx）,为了适应多线程环境下的情况，可以使用同步关键字实现同步
构建者模式
要实现构建的过程统一，当构建的内容不一致. 主要的角色有导演类, 构造者,和具体的产品类.产品类一般会实现一个统一的标示接口,便于产品的链式构造. 但在实际的应用中如果对系统的把握比较大,比如明确知道产品的构成成分是稳定的,这时就可以将产品与构造者的角色统一合并至产品角色中. 总的来说,构建者的主要思想就是将构建的指导过程由导演者角色担当, 构建过程由构建者担当, 让客户端感觉不到产品族的构造过程. 具体的类结构可以看情况有所不同.它与抽象工厂的区别在于,抽象工厂要生产就生产一整套, 而构建者模式这是产品成分的动态组合,具体要组合哪些个产品成分可以有客户端控制
不变模式:
这里主要讲的是强不变模式: 即final 关键字修饰的不变类.好处是不需要额外的同步,多线程下安全. 缺点是如果需要中间结果时,只能创建不变对象的副本. 像那些从创建后,状态就不会改变的类就应该设计为不变类.不变类的内部不应该提供可以改变自身状态的方法.
缺省模式：
这个很好理解，就是为接口的实现类提供一个默认的抽象实现，具体的实现类继承至该'适配类‘，只需要关注自己的方法即可。
代理模式：
代理类和代理类都继承于同一个接口，代理类内部聚合一个被代理对象。客户端请求代理对象的方法，从而使得方法得以加强。这个是静态代理的主要机制。
有的书上又将代理模式分为多种类型: 如智能应用类型就是最常见的一种类型，其代码结构如上所述。