沈阳做网站多少钱,wordpress按钮拨电话,wordpress免费插件下载地址,清廉医院建设网站点击进入我的博客 3.1 适配器模式 适配器模式把一个类的接口变换成客户端所期待的另一种接口#xff0c;使得原本因接口不匹配而无法在一起工作的两个类能够在一起工作。 3.1.1 类的适配器结构 目标#xff08;Target#xff09;角色#xff1a;这就是所期待得到的接口使得原本因接口不匹配而无法在一起工作的两个类能够在一起工作。 3.1.1 类的适配器结构 目标Target角色这就是所期待得到的接口由于是类适配器模式因此目标不可以是类。源Adaptee角色现有需要适配的接口。适配器Adapter角色适配器类是本模式的核心必须是具体类。interface Target {void operation1();void operation2();
}class Adaptee {public void operation1() {}
}class Adapter extends Adaptee implements Target {Overridepublic void operation2() {}
} 类的适配器 类的适配器模式把被的类的API转换成目标类的API。是通过继承实现的。类的适配器效果 使用一个具体类把源适配到目标中。这样如果源以及源的子类都使用此类适配就行不通了。由于适配器是源的子类因此可以在适配器中重写源的一些方法。由于引进了一个适配器类因此只有一个线路到达目标类是问题得到简化。3.1.2 对象的适配器结构 目标Target角色这就是所期待得到的接口因此目标可以是具体或抽象的类。源Adaptee角色现有需要适配的接口。适配器Adapter角色适配器类是本模式的核心必须是具体类。interface Target {void operation1();void operation2();
}class Adaptee {public void operation1() {}
}class Adapter implements Target {private Adaptee adaptee;public Adapter(Adaptee adaptee) {this.adaptee adaptee;}Overridepublic void operation1() {adaptee.operation1();}Overridepublic void operation2() {// do something}
} 对象的适配器 对象的适配器是通过依赖实现的推荐使用该方法对象的适配器效果 一个适配器可以把多种不同的源适配到同一个目标即同一个适配器可以把源类和它的子类都适配到目标接口与类的适配器模式相比要想置换源类的方法就不容易。增加新的方法方便的多3.1.3 细节 使用场景 系统需要使用现有的类而此类的接口不符合系统的需要想要建立一个可以重复使用的类用于与一些彼此间没有太大关联的一些类包括一些可能在将来引进的类一起工作。对对象的适配器儿模式而言在设计里需要改变多个已有的子类的接口如果使用类的适配器模式就需要针对每个子类做一个适配器类这不太实际。优点 可以让任何两个没有关联的类一起运行。提高了类的复用。增加了类的透明度。灵活性好。缺点 过多地使用适配器会让系统非常零乱不易整体进行把握。比如明明看到调用的是 A 接口其实内部被适配成了 B 接口的实现一个系统如果太多出现这种情况无异于一场灾难。因此如果不是很有必要可以不使用适配器而是直接对系统进行重构。由于 JAVA 至多继承一个类所以至多只能适配一个适配者类而且目标类必须是抽象类。注意点 目标接口可以忽略此时目标接口和源接口实际上是相同的适配器类可以是抽象类可以有带参数的适配器模式3.1.4 一个充电器案例 // 充电器只能接受USB接口
public class Charger {public static void main(String[] args) throws Exception{USB usb new SuperAdapter(new TypeC());connect(usb);usb new SuperAdapter(new Lightning());connect(usb);}public static void connect(USB usb) {usb.power();usb.data();}
}// 充电器的接口都是USB的假设有两个方法分别是电源和数据
interface USB {void power();void data();
}// IOS的Lightning接口
class Lightning {void iosPower() {System.out.println(IOS Power);}void iosData() {System.out.println(IOS Data);}
}// TYPE-C接口
class TypeC {void typeCPower() {System.out.println(TypeC Power);}void typeCData() {System.out.println(TypeC Data);}
}// 超级适配器可以适配多种手机机型
class SuperAdapter implements USB {private Object obj;public SuperAdapter(Object obj) {this.obj obj;}Overridepublic void power() {if(obj.getClass() Lightning.class) {((Lightning)obj).iosPower();} else if(obj.getClass() TypeC.class) {((TypeC)obj).typeCPower();}}Overridepublic void data() {if(obj.getClass() Lightning.class) {((Lightning)obj).iosData();} else if(obj.getClass() TypeC.class) {((TypeC)obj).typeCData();}}
} 3.2 缺省适配模式 缺省适配模式为一个接口提供缺省实现这样子类型可以从这个缺省实现进行扩展而不必从原有接口进行扩展。 3.2.1 缺省适配模式结构 简单的例子 下面程序中Monk接口定义了两个方法于是它的子类必须实现这两个方法。但出现了一个LuZhiShen他只能实现一部分方法另一部分方法无法实现所以需要一个抽象的适配类MonkAdapter实现此Monk接口此抽象类给接口所有方法都提供一个空的方法LuZhiShen只需要继承该适配类即可。// 和尚
interface Monk {void practiceKungfu();void chantPrayer();
}abstract class MonkAdapter implements Monk {Overridepublic void practiceKungfu() {}Overridepublic void chantPrayer() {}
}class LuZhiShen extends MonkAdapter {Overridepublic void practiceKungfu() {System.out.println(拳打镇关西);}
} 3.2.2 细节 使用场景 任何时候不准备实现一个接口中所有方法的时候作用 缺省适配器模式可以使所需要的类不必实现不需要的接口。 核心点 缺省适配的类必须是抽象类因为这个类不应当被实例化缺省适配的类提供的方法必须是具体的方法而不是抽象的方法。3.3 组合模式 组合模式就是在一个对象中包含其他对象这些被包含的对象可能是终点对象不再包含别的对象也有可能是非终点对象其内部还包含其他对象。我们将对象称为节点即一个根节点包含许多子节点这些子节点有的不再包含子节点而有的仍然包含子节点以此类推。很明显这是树形结构终结点叫叶子节点非终节点叫树枝节点第一个节点叫根节点。 3.3.1 安全式的合成模式结构 安全式的合成模式要求管理集合的方法只出现在树枝结点Composite中而不出现在树叶结点中。 抽象构建Component角色这是一个抽象角色他给参加组合的对象定义出公共的接口及其默认行为可以用来管理所有的子对象。树叶Leaf角色树叶是没有子对象的对象定义出参加组合的原始对象的行为。树枝Composite角色代表参加组合的有下级子对象的对象。树枝构件类给出所有管理子对象的方法。3.3.2 透明的合成模式结构 透明的合成模式要求所有的具体构建类都符合一个固定的接口。 3.4 装饰器模式 装饰器模式Decorator允许向一个现有的对象添加新的功能同时又不改变其结构。这种类型的设计模式属于结构型模式它是作为现有的类的一个包装。 3.4.1 装饰器结构 抽象构件Component角色给出一个抽象结构以规范准备接受附加责任的对象。具体构件Concrete Component角色定义一个要接受附加责任的类装饰Decorator角色持有一个构件对象的实例并定义一个与抽象构件接口一致的接口。具体装饰Concrete Decorator角色负责给构件对象“贴上”附加的责任。3.4.2 装饰器细节 使用场景 需要扩展一个类的功能需要动态地给一个对象增加功能这些功能可以再动态的插销需要增加由一些基本功能的排列组合而产生非常大量的功能优点 更加灵活装饰模式和继承关系的目的都是要扩展对象的功能但是装饰模式比继承更加灵活 多样性通过使用不同具体装饰类及其排列组合可以创造出不同的行为 动态扩展装饰器可以动态扩展构件类缺点 会产生比继承关系更多的对象比继承更加容易出错注意点 装饰类的接口必须与被装饰类的接口相容。尽量保持抽象构件Component简单。可以没有抽象的Component此时装饰器Decorator一般是具体构件Concrete Component的一个子类。装饰Decorator和具体装饰Concrete Decorator可以合并。InputStream及其子类 抽象构件Component角色InputStream 具体构件Concrete Component角色ByteArrayInputStream、PipedInputStream、StringBufferInputStream等原始流处理器。装饰Decorator角色FilterInputStream 具体装饰Concrete Decorator角色DateInputStream、BufferedInputStream、LineNumberInputStream OutputStream及其子类 也用到类装饰器模式 3.4.3 例子 // Component一个艺人
interface Artist {void show();
}// Concrete Component一个歌手
class Singer implements Artist {Overridepublic void show() {System.out.println(Let It Go);}
}// 装饰后的歌手不仅会唱歌还会讲笑话和跳舞
class SuperSinger implements Artist {private Artist role;public SuperSinger(Artist role) {this.role role;}Overridepublic void show() {System.out.println(Tell Jokes);role.show();System.out.println(Dance);}
} 3.5 代理模式 代理模式给某一个对象提供一个代理对象并由代理对象控制对原对象对引用。 3.5.1 代理模式结构 抽象主题Subject角色声明了真实主题和代理主题的共同接口代理主题Proxy角色代理主题角色内部含有对真实主题的引用从而可以在任何时候操作真实主题对象代理主题角色提供一个与真实主题角色相同的接口以便可以在任何时候都可以替代真实主题控制对真实主题的引用负责在需要的时候创建真实主题对象和删除真实主题对象代理角色通常在将客户端调用传递给真实的主题之前或之后都要执行某个操作而不是单纯地将调用传递给真实主题对象。真实主题RealSubject角色定义了代理角色所代表的真实对象。public class Test {public static void main(String[] args) {Subject subject new RealSubject();Subject proxy new ProxySubject(subject);proxy.request(); // 此处通过代理类来执行}
}interface Subject {void request();
}class RealSubject implements Subject {Overridepublic void request() {System.out.println(RealSubject);}
}class ProxySubject implements Subject {private Subject subject;public ProxySubject(Subject subject) {this.subject subject;}Overridepublic void request() {System.out.println(ProxySubject);}
} 3.5.2 动态代理 自从JDK 1.3以后Java在java.lang.reflect库中提供了一下三个类直接支持代理模式Proxy、InvocationHander、Method。 动态代理步骤 创建一个真实对象创建一个与真实对象有关的调用处理器对象InvocationHandler 创建代理把调用处理器和要代理的类联系起来Proxy.newInstance() 在调用处理对象的invoke()方法中执行相应操作public class Test {public static void main(String[] args) {// 创建要被代理的实例对象Subject subject new RealSubject();// 创建一个与被代理实例对象有关的InvocationHandlerInvocationHandler handler new ProxySubject(subject);// 创建一个代理对象来代理subject被代理的对象subject的每个方法执行都会调用代理对象proxySubject的invoke方法Subject proxySubject (Subject) Proxy.newProxyInstance(Subject.class.getClassLoader(), new Class[]{Subject.class}, handler);// 代理对象执行proxySubject.request();}
}interface Subject {void request();
}class RealSubject implements Subject {Overridepublic void request() {System.out.println(RealSubject);}
}class ProxySubject implements InvocationHandler {private Subject subject;public ProxySubject(Subject subject) {this.subject subject;}/*** param proxy 要代理的* param method* param args* return*/Overridepublic Object invoke(Object proxy, Method method, Object[] args) throws Throwable {System.out.println(Before Proxy);Object obj method.invoke(subject, args);System.out.println(After Proxy);return obj;}
} 可以使用范型来创建ProxySubject 可以使用匿名内部类减少代码数量请查看14.7节 3.5.3 细节 优点 代理类和真实类分离职责清晰。在不改变真是累代码的基础上扩展了功能。缺点 由于在客户端和真实主题之间增加了代理对象因此有些类型的代理模式可能会造成请求的处理速度变慢。实现代理模式需要额外的工作有些代理模式的实现非常复杂。和适配器模式的关系 适配器模式的用意是改变所考虑对象的接口而代理模式不能改变。 和装饰模式 装饰模式应当为所装饰的对象提供增强功能代理模式对对象的使用施加控制并不提供对象本身的增强功能虚拟代理 虚拟代理模式Virtual PRoxy会推迟真正所需对象实例化时间。在需要真正的对象工作之前如果代理对象能够处理那么暂时不需要真正对象来出手。当一个真实主题对象的加载需要耗费资源时一个虚拟代理对象可以代替真实对象接受请求并展示“正在加载”的信息并在适当的时候加载真实主题对象。3.6 享元模式 享元模式以共享的方式高效地支持大量的细粒度对象。 3.6.1 单纯享元模式 单纯享元模式中所有的享元对象都是可以共享的。 抽象享元Flyweight角色是所有具体享元角色的超类并为这些类规定公共接口。具体享元Concrete Flyweight角色实现抽象享元的接口。如果由内蕴状态的话必须负责为内蕴状态提供空间。享元工厂Flyweight Factory角色负责创建和管理享元角色。如果系统中有了则返回该角色没有则创建。客户端Client角色维护一个所有享元对象的引用。存储所有享元对象的外蕴状态。3.6.2 复合享元模式 抽象享元Flyweight角色 给出一个抽象接口以规定出所有具体享元角色需要实现的方法。具体享元ConcreteFlyweight角色实现抽象享元角色所规定出的接口。如果有内蕴状态的话必须负责为内蕴状态提供存储空间。复合享元ConcreteCompositeFlyweight角色 复合享元角色所代表的对象是不可以共享的但是一个复合享元对象可以分解成为多个本身是单纯享元对象的组合。复合享元角色又称作不可共享的享元对象UnsharedConcreteFlyweight。享元工厂(FlyweightFactory)角色 负责创建和管理享元角色。当一个客户端对象调用一个享元对象的时候如果已经有了享元工厂角色就应当提供这个已有的享元对象如果系统中没有一个适当的享元对象的话享元工厂角色就应当创建一个合适的享元对象。3.6.3 细节 内蕴状态和外蕴状态 内蕴状态是存储在享元对象内部的不会随环境改变而改变的。一个享元可以具有内蕴状态并可以共享。外蕴状态随环境改变而改变、不可以共享的状态。享元对象的外蕴状态必须由客户端保存并在享元对象被创建之后在需要使用的时候再传入到享元对象内部。 不变模式 享元模式中的对象不一定非要是不变对象但大多数享元对象的确是这么设计的。 享元工厂 使用单例模式一般只需要一个享元工厂可以设计成单例的。备忘录模式享元工厂负责维护一个表通过这个表把很多相同的实例与它们的一个对象联系起来。优点 减少对象的创建降低内存消耗 缺点 提高了系统的复杂度为了使对象可以共享需要将一些状态外部化需要将一些状态外部化而读取外部状态是的运行时间稍微变长使用场景 一个系统中有大量对象。这些对象消耗大量内存。这些对象的状态大部分可以外部化。这些对象可以按照内蕴状态分为很多组当把外蕴对象从对象中剔除出来时每一组对象都可以用一个对象来代替。系统不依赖于这些对象身份换言之这些对象是不可分辨的。Java应用 String对象有则返回没有则创建一个字符串并保存数据库的连接池3.6.4 案例 依旧是熟悉的KFC点餐为例 外蕴状态点餐的顾客内蕴状态顾客点的食物具体享元角色维护内蕴状态客人要点的食物。public class KFC {public static void main(String[] args) {OrderFactory orderFactory OrderFactory.getInstance();Order order orderFactory.getOrder(Food.MiniBurger);order.operation(李雷);order orderFactory.getOrder(Food.MiniBurger);order.operation(韩梅梅);}
}enum Food {MiniBurger,MexicanTwister,CornSalad,HotWing,PepsiCola
}// Flyweight角色
interface Order {// 传入的是外蕴对象顾客void operation(String customer);
}// ConcreteFlyweight角色
class FoodOrder implements Order {// 内蕴状态private Food food;// 构造方法传入享元对象的内部状态的数据public FoodOrder(Food food) {this.food food;}Overridepublic void operation(String customer) {System.out.println(顾客[ customer ]点的是 food.toString());}
}// FlyweightFactory角色
class OrderFactory {private MapFood, Order orderPool new HashMap();private static OrderFactory instance new OrderFactory();private OrderFactory() {}public static OrderFactory getInstance() {return instance;}// 获取Food对应的享元对象public Order getOrder(Food food) {Order order orderPool.get(food);if (null order) {order new FoodOrder(food);orderPool.put(food, order);}return order;}
} 3.7 门面模式 门面模式Facade Pattern要求一个子系统的外部与其内部通信必须通过一个统一的门面对象进行。 3.7.1 门面模式结构 门面模式没有一个一般化的类图描述可以用下面的例子来说明。 门面Facade角色外部可以调用这个角色的方法。此角色知道子系统的功能和责任。子系统Subsystem角色可以有多个子系统子系统不需要知道门面的存在。3.7.2 细节 门面数量 通常只需要一个门面类而且只有一个实例因此可以设计称单例模式。当然也可有多个类。 使用场景 为一个复杂的子系统提供一个简单的接口使子系统和外部分离开来构建一个层次化系统时可以使使用Facade模式定义系统中每一层实现分层。优点 减少系统之间的相互依赖。提高了安全性。缺点 不符合开闭原则如果要改东西很麻烦继承重写都不合适。Java例子 MVC三层结构 3.7.3 KFC例子 假如没有服务员门面顾客外部系统要点一个套餐需要知道每个套餐包含的食物子系统种类这样就会非常麻烦所以最好的方式是直接告诉服务员套餐名称就好了。 public class Customer {public static void main(String[] args) {Waiter waiter new Waiter();ListFood foodList waiter.orderCombo(Combo1);}
}abstract class Food {}
class MiniBurger extends Food {}
class MexicanTwister extends Food {}
class CornSalad extends Food {}
class HotWing extends Food {}
class PepsiCola extends Food {}class Waiter {public ListFood orderCombo(String comboName) {ListFood foodList;switch (comboName) {case Combo1 : foodList Arrays.asList(new MiniBurger(), new CornSalad(), new PepsiCola()); break;case Combo2:foodList Arrays.asList(new MexicanTwister(), new HotWing(), new PepsiCola());break;default:foodList new ArrayList();}return foodList;}
} 3.8 过滤器模式 过滤器模式使用不同的条件过滤一组对象并通过逻辑操作以解耦方式将其链接。这种类型的设计模式属于结构模式因为该模式组合多个标准以获得单个标准。 3.8.1 细节 步骤 创建一个要过滤的普通类要有获得其私有属性的get方法创建一个接口规定过滤方法实现接口可以依需要重写过滤方法参数传递的一般是存储过滤类的容器类复杂过滤类可以通过设置传递接口参数复用其他基础过滤类来实现多重过滤Java8 Java8中的lambda表达式可以更简单的实现过滤器 ListMovie movies Stream.of(new Movie(大话西游,comedy),new Movie(泰囧, comedy),new Movie(禁闭岛, suspense)).filter(var - comedy.equals(var.getType())).collect(Collectors.toList()); 3.8.2 电影的例子 创建被过滤的类Movie根据它的type属性实现过滤创建接口Criteria规定过滤方法创建喜剧电影过滤器ComedyMovieCriteria根据comedymovie.type来过滤出需要的喜剧电影public class Test {public static void main(String[] args) {ListMovie movies new ArrayList(){{add(new Movie(大话西游,comedy));add(new Movie(泰囧, comedy));add(new Movie(禁闭岛, suspense));}};System.out.println(new ComedyMovieCriteria().meetCriteria(movies));}
}// 被筛选的对象
class Movie {private String name;// 电影类型private String type;public Movie(String name, String type) {this.name name;this.type type;}// getters setters toString
}// 过滤器接口
interface Criteria {/*** param movies 要被筛选的电影* return 筛选后的结果*/ListMovie meetCriteria(ListMovie movies);
}// 过滤喜剧电影的过滤器要求是movie.typecomedy
class ComedyMovieCriteria implements Criteria {Overridepublic ListMovie meetCriteria(ListMovie movies) {ListMovie result new ArrayList();for (Movie movie : movies) {if (comedy.equals(movie.getType())) {result.add(movie);}}return result;}
} 3.9 桥接模式 桥接模式是将抽象化与实现化解耦使两者可以独立地变化。桥接模式有助于理解面向对象的设计原则包括开闭原则以及组合聚合复用原则。 3.9.1 桥接模式结构 这个系统含有两个等级结构 由抽象化角色和修正抽象化角色组成的抽象化等级结构。由实现化角色和两个具体实现化角色所组成的实现化等级结构。桥接模式所涉及的角色 抽象化Abstraction角色抽象化给出的定义并保存一个对实现化对象的引用。修正抽象化Refined Abstraction角色扩展抽象化角色改变和修正父类对抽象化的定义。实现化Implementor角色这个角色给出实现化角色的接口但不给出具体的实现。必须指出的是这个接口不一定和抽象化角色的接口定义相同实际上这两个接口可以非常不一样。实现化角色应该只给出底层操作而抽象化角色应该只给出基于底层操作的更高一层的操作。具体实现化Concrete Implementor角色这个角色给出实现化角色接口的具体实现。3.9.2 细节 抽象化、实现化、解耦 抽象化存在于多个实体中的共同的概念性联系通过忽略一些信息把不同的实体当作相同的实体来对待。实现化抽象化给出的具体实现就是实现化。一个类的实例就是这个类的实现化一个子类就是它超类的实现化。解耦耦合就是两个实体的某种强关联把它们的强关联去掉就是解耦。强关联与弱关联所谓强关联就是在编译期已经确定的无法在运行期动态改变的关联所谓弱关联就是可以动态地确定并且可以在运行期动态地改变的关联。继承是强关联而聚合关系是弱关联。 核心理解 桥接模式中的脱耦就是在抽象化和实现化之间使用组合关系而不是继承关系从而使两者可以相对独立的变化。 优点 实现抽象化和实现化的分离。提高了代码的扩展能力。实现细节对客户透明。缺点 桥接模式的引入会增加系统的理解与设计难度由于聚合关联关系建立在抽象层要求开发者针对抽象进行设计与编程。使用场景 如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性避免在两个层次之间建立静态的继承联系通过桥接模式可以使它们在抽象层建立一个关联关系。抽象化角色和实现化角色可以以继承的方式独立扩展而互不影响在程序运行时可以动态将一个抽象化子类的对象和一个实现化子类的对象进行组合即系统需要对抽象化角色和实现化角色进行动态耦合。一个类存在两个独立变化的维度且这两个维度都需要进行扩展。虽然在系统中使用继承是没有问题的但是由于抽象化角色和具体化角色需要独立变化设计要求需要独立管理这两者。对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统桥接模式尤为适用Java例子 大多数的驱动器Driver都是桥接模式的应用使用驱动程序的应用系统就是抽象化角色而驱动器本身扮演实现化角色。 3.9.3 发送消息的案例 下面案例中SendMsg及其子类是按照发送消息的方式进行扩展的而Send是按照发送消息的时间进行扩展的两者互不影响。 Send持有类一个SendMsg对象并可以使用此对象的方法。// Implementor角色
interface SendMsg {void sendMsg();
}// Concrete Implementor角色
class EmailSendMsg implements SendMsg {Overridepublic void sendMsg() {System.out.println(Send Msg By Email);}
}// Concrete Implementor角色
class WeChatSendMsg implements SendMsg {Overridepublic void sendMsg() {System.out.println(Send Msg By WeChat);}
}// Abstraction 角色
abstract class Send {protected SendMsg sendMsg;public Send(SendMsg sendMsg) {this.sendMsg sendMsg;}public abstract void send();
}// Concrete Implementor角色
class ImmediatelySend extends Send {public ImmediatelySend(SendMsg sendMsg) {super(sendMsg);}Overridepublic void send() {sendMsg.sendMsg();System.out.println(Send Msg Immediately);}
}// Concrete Implementor角色
class DelayedlySend extends Send {public DelayedlySend(SendMsg sendMsg) {super(sendMsg);}Overridepublic void send() {sendMsg.sendMsg();System.out.println(Send Msg DelayedlySend);}
}
