结构型模式描述了如何把类和对象组合起来以形成更大的结构。我是这么理解的:程序大体框架已基本形成了,只是对其代码和结构进行了优化。提高了代码的复用性,降低了系统内部的耦合性。
该类型模式主要包括:适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式、代理模式。
1.适配器模式:更换接口,使其成为适应用户需求的接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。(系统的数据和行为都是正确的,但接口不符时,我们应该考虑用适配器,目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些现存的类,但是接口又与复用环境要求不一致的情况。)当使用一个已经存在的类,但如果它的接口也就是它的方法和你的要求不同时,就应该考虑使用适配器模式。客户代码可以统一调用同一接口。
现实生活中这样的例子很多,前段时间买了个键盘,由于自己的疏忽把键盘买错了,应该是USB接口的,我却买成了台式机的圆头的,跟卖家交谈的时候,人家推荐我用USB转换器就可以解决问题啦。一样的道理,适配器模式就是要解决这个问题,就算是转弯抹角也要达到目的。
2.桥接模式:将抽象部分和它的实现部分分离,使它们都可以独立的变化。(抽象类和它的派生类用来实现自己的对象)我的理解是:实现系统可能有多角度分类,每一种分类都有可能变化,那么就把这多角度分离出来让他们变化,减少他们之间的耦合。这里用到了合成/聚合复用原则(尽量使用合成/聚合,尽量不要使用类的继承:优先使用对象的合成/聚合将有助于你保持每个类被封装,并被集中在单个任务上。这样类和继承层次会保持较小规模,并且不可能增长为不可控制的庞然大物。)
说实话,刚开始不太理解什么是抽象和实现分离,从网上找了一个例子说服了自己:就拿汽车在路上行驶的来说。即有小汽车又有公共汽车,它们都不但能在市区中的公路上行驶,也能在高速公路上行驶。这你会发现,对于交通工具(汽车)有不同的类型,然而它们所行驶的环境(路)也在变化,在软件系统中就要适应两个方面的变化?怎样实现才能应对这种变化呢?在软件系统中,某些类型由于自身的逻辑,它具有两个或多个维度的变化,那么如何应对这种“多维度的变化”?如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化,而又不引入额外的复杂度?这就要使用Bridge模式。