![](https://img-blog.csdnimg.cn/20201014180756928.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
软件构造
浮世清欢ㄡ
这个作者很懒,什么都没留下…
展开
-
软件构造-可维护性-备忘录模式
意图:不违反封装,通过外部控制对象内部的状态,可以回到某个状态;即记住对象的历史状态,以便于“回滚”。图示如下:Originator类:需要“备忘”的类;Memento类:备忘录,记录Originator对象的一个历史状态;Caretaker类:保留一系列的历史状态。举例:Originator类:Memento类:非常简单的类,只记录一个历史状态。Caretaker类:Client:结果:...原创 2020-06-10 21:14:43 · 111 阅读 · 0 评论 -
软件构造-可维护性-状态模式
最好不要使用if/else结构在ADT内部实现状态转换(考虑将来的扩展和修改);而是应该使用delegation,将状态转换的行为委派到独立的state对象去完成。图示如下:State接口:定义了引起状态转换的操作;ConcreteState类:具体的状态,实现了State接口;Context类:使用状态的上下文环境。举例:状态图:State接口:public interface State { public State move(char c); // 状态转换 public原创 2020-06-10 20:41:06 · 154 阅读 · 0 评论 -
软件构造-可维护性-Visitor模式
定义:将作用于某种数据结构中的各元素的操作分离出来封装成独立的类,使其在不改变数据结构的前提下可以添加作用于这些元素的新的操作,为数据结构中的每个元素提供多种访问方式。它将对数据的操作与数据结构进行分离,是行为类模式中最复杂的一种模式。优点:扩展性好。能够在不修改对象结构中的元素的情况下,为对象结构中的元素添加新的功能;复用性好。可以通过访问者来定义整个对象结构通用的功能,从而提高系统的复用程度;灵活性好。访问者模式将数据结构与作用于结构上的操作解耦,使得操作集合可相对自由地演化而不影响系统的数据原创 2020-06-10 18:07:37 · 153 阅读 · 0 评论 -
软件构造-可维护性-Observer模式
subject:类似于“偶像”;observer:类似于“粉丝”;“粉丝”对“偶像”感兴趣,希望随时得知偶像的一举一动;“粉丝”到“偶像”那里注册,“偶像”一旦有新闻发生,就推送给已注册的粉丝(回调callback“粉丝”的特定功能)。java已经提供了Observer接口和Observable类,我们利用此实现观察者模式。举例:subject:import java.util.Observable;public class Subject extends Observable { //原创 2020-06-10 17:21:32 · 179 阅读 · 0 评论 -
软件构造-可维护性-代理模式
定义:某个对象比较“敏感”/“私密”/“贵重”,不希望被client直接访问到,故设置代理,在两者之间建立防火墙。目的:隔离对复杂对象的访问,降低难度/代价,定位在“访问/使用行为”。图示如下:Image接口:为了便于改变,访问抽象接口;RealImage类:本应直接访问,但受限于代价大;ProxyImage类:创建的代理,可以降低代价;client:客户端。举例:Image接口:public interface Image { // Image接口 public void dis原创 2020-06-10 16:10:19 · 106 阅读 · 0 评论 -
软件构造-可维护性-抽象工厂模式
定义:提供接口以创建一组相关/相互依赖的对象,但不需要指明其具体类。抽象工厂模式创建的不是一个完整产品,而是“产品族”(遵循固定搭配规则的多类产品的实例),得到的结果是:多个不同产品的对象,各产品创建过程对client可见,但“搭配”不能改变。本质上,抽象工厂模式是把多类产品的工厂方法组合在一起。(工厂方法模式可以看我的另一篇文章)举例:抽象产品类:具体产品类:抽象工厂类:具体工厂类:Client:...原创 2020-06-10 15:31:50 · 103 阅读 · 0 评论 -
软件构造-可维护性-工厂方法模式
意图:定义一个用于创建对象的接口,让子类决定实例化哪一个类。工厂方法是一个类的实例化延迟到其子类。当client不知道要创建哪个具体类的实例,或者不想在client代码中指明要具体创建的实例时,用工厂方法。优点:更符合开闭原则:新增一种产品时,只需要增加相应的具体产品类和相应的工厂子类即可;符合单一职责原则:每个具体工厂类只负责创建对应的产品。缺点:添加新产品时,除了增加新产品类外,还要提供与之对应的具体工厂类,系统类的个数将成对增加,在一定程度上增加了系统的复杂度;同时有更多的类需要编译原创 2020-06-10 14:51:56 · 169 阅读 · 0 评论 -
软件构造-可复用性-Iterator模式
定义:提供一个对象来顺序访问聚合对象中的一系列数据,而不暴露聚合对象的内部表示。它是一种对象行为型模式。优点:访问一个聚合对象的内容而无需暴露其内部表示;遍历任务交给迭代器完成,这简化了聚合类;它支持以不同方式遍历一个聚合,甚至可以自定义迭代器的子类以支持新的遍历;增加新的聚合类和迭代器类都很方便,无需修改原有代码;封装性良好,为遍历不同的聚合结构提供了一个统一的接口。缺点:增加了类的个数,这在一定程度上增加了系统的复杂性。图示如下:Aggregate接口:抽象聚合角色,定义存储、添原创 2020-06-10 13:20:41 · 109 阅读 · 0 评论 -
软件构造-可复用性-Template模式
问题:不同的客户端具有相同的算法步骤,但是每个步骤的具体实现不同。Template模式:在父类中定义通用的逻辑和个步骤原创 2020-06-10 09:50:38 · 108 阅读 · 0 评论 -
软件构造-可复用性-Strategy模式
问题:针对特定任务存在多种算法,调用者需要根据上下文环境动态的选择和切换。Strategy模式:定义一个算法的接口,每个算法用一个类来实现,客户端针对接口编写程序。图示如下:Stategy接口:算法接口;ConcreteStategyA类:具体算法A;ConcreteStategyB类:具体算法B;ConcreteStategyC类:具体算法C;Context类:上下文语境。举例:Stategy接口:public interface PaymentStategy { // Stateg原创 2020-06-10 09:20:36 · 153 阅读 · 0 评论 -
软件构造-可复用性-Façade模式
定义:是一种通过为多个复杂的子系统提供一个一致的接口,而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口,外部应用程序不用关心内部子系统的具体的细节,这样会大大降低应用程序的复杂度,提高了程序的可维护性。优点:降低了子系统与客户端之间的耦合度,使得子系统的变化不会影响调用它的客户类。对客户屏蔽了子系统组件,减少了客户处理的对象数目,并使得子系统使用起来更加容易。降低了大型软件系统中的编译依赖性,简化了系统在不同平台之间的移植过程,因为编译一个子系统不会影响其他的子系统,也不会影响外观对象原创 2020-06-06 23:11:54 · 176 阅读 · 0 评论 -
软件构造-可复用性-Decorator模式
定义:指在不改变现有对象结构的情况下,动态地给该对象增加一些职责(即增加其额外功能)的模式,它属于对象结构型模式。主要优点有:采用装饰模式扩展对象的功能比采用继承方式更加灵活。可以设计出多个不同的具体装饰类,创造出多个不同行为的组合。主要缺点是:装饰模式增加了许多子类,如果过度使用会使程序变得很复杂。图示如下:Component接口:定义装饰物执行的公共操作;ConcreteComponent类:实现Component接口;Decorator抽象类:是所有装饰类的基类,里面包含的成员变原创 2020-06-06 22:44:37 · 138 阅读 · 0 评论 -
软件构造-可复用性-Adapter模式
意图:将类的接口转换为客户端期望的另一个接口。解决类之间接口不兼容的问题;为已有的类提供新的接口;目标:对旧的不兼容的组件进行包装,在新系统中使用旧的组件。图示如下:Adaptee是现有的类;ITarget是我们需要的新的接口;Adapter继承自Adaptee类,并实现了ITarget接口。请注意:它的Request方法是通过调用Adaptee的SpecificRequest方法实现的。举例:Adaptee:public class Consultant { // 现有的类原创 2020-06-06 21:36:03 · 165 阅读 · 0 评论