精华内容
下载资源
问答
  • 创建型模式这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式,而不是使用新的运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。工厂模式与抽象工厂模式 (Factory ...
    创建型模式

    这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式,而不是使用新的运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。

    • 工厂模式与抽象工厂模式 (Factory Pattern)(Abstract Factory Pattern):不同条件下创建不同实例
    • 单例模式 (Singleton Pattern):保证一个类仅有一个实例,适用于只需要一个对象的情况
    • 建造者模式 (Builder Pattern)将一个复杂的构建过程与其具表示细节相分离,使得同样的构建过程可以创建不同的表示,创建复杂对象
    • 原型模式 (Prototype Pattern)通过拷贝原型创建新的对象,复制对象,包括深度复制和浅度复制,深度复制重建引用对象,浅度复制不创建

    结构型模式

    这些设计模式关注类和对象的组合。

    • 适配器模式 (Adapter Pattern)使得原本由于接口不兼容而不能一起工作的那些类可以一起工作,开发阶段不考虑,适用于后期维护时添加功能
    • 装饰器模式 (Decorator Pattern)保持接口,增强性能,说白了就是实现接口,扩展方法功能,可在方法执行前后加代码
    • 桥接模式 (Bridge Pattern)两个维度独立变化,依赖方式实现抽象与实现分离:需要一个作为桥接的接口/抽象类,多个角度的实现类依赖注入到抽象类,使它们在抽象层建立一个关联关系,通过setXxx方法任意修改引用实例,调用同样方法实现不同功能
    • 外观模式 (Facade Pattern)在客户端和复杂系统之间再加一层,这一次将调用顺序、依赖关系等处理好。即封装底层实现,隐藏系统的复杂性,并向客户端提供了一个客户端可以访问系统的高层接口
    • 代理模式 (Proxy Pattern)为其他对象提供一种代理以控制对这个对象的访问,调用引用对象方法实现自身功能
    • 过滤器模式 (Filter、Criteria Pattern)使用不同的标准来过滤一组对象,通过逻辑运算以解耦的方式把它们连接起来
    • 组合模式 (Composite Pattern)用户对单个对象和组合对象的使用具有一致性的统一接口,部分与整体,常用于表示树形结构
    • 享元模式 (Flyweight Pattern)维护资源集合,经典案例:数据库连接池,避免重新开启数据库链接的开销

    行为型模式

    这些设计模式特别关注对象之间的通信。

    • 责任链模式(Chain of Responsibility Pattern)拦截的类都实现统一接口,每个接收者都包含对下一个接收者的引用。将这些对象连接成一条链,并且沿着这条链传递请求,直到有对象处理它为止。依次引用,依次执行.
    • 观察者模式(Observer Pattern)目标方法被调用,通知所有观察者
    • 模板模式(Template Pattern)父类定义公共方法,不同子类重写父类抽象方法,得到不同结果
    • 命令模式(Command Pattern)将"行为请求者"与"行为实现者"解耦:调用者依赖命令,命令依赖接收者,调用者Invoker→命令Command→接收者Receiver,各司其职,逐层调用,有点像三层架构
    • 解释器模式(Interpreter Pattern):定义解释类,解释包装对象
    • 迭代器模式(Iterator Pattern):迭代器实现原理
    • 中介者模式(Mediator Pattern)对象与对象之间存在大量的关联关系,将对象之间的通信关联关系封装到一个中介类中单独处理,从而使其耦合松散,可以独立地改变它们之间的交互,中介类维护对象行为。主程序直接调用中介对象即可
    • 策略模式(Strategy Pattern)定义多个不同的实现类,这些类实现公共接口,通过调用接口调用不同实例得到不同结果
    • 状态模式(State Pattern)通过改变状态,改变行为
    • 备忘录模式(Memento Pattern):建立原始对象副本,用于存储恢复原始对象数据。
    展开全文
  • 状态对于我们开发者而言是相当熟悉的,平常开发中总是离不开对象的状态,比如我们审核流程,就是一个状态不断流转的过程,订单流程也是一个状态不断流转的过程,而状态模式就是为了更好地解决我们状态流转过程中的...

    设计模式系列总览

    设计模式飞机票
    三大工厂模式登机入口
    策略模式登机入口
    委派模式登机入口
    模板方法模式登机入口
    观察者模式登机入口
    单例模式登机入口
    原型模式登机入口
    代理模式登机入口
    装饰者模式登机入口
    适配器模式登机入口
    建造者模式登机入口
    责任链模式登机入口
    享元模式登机入口
    组合模式登机入口
    门面模式登机入口
    桥接模式登机入口
    中介者模式登机入口
    迭代器模式登机入口
    状态模式登机入口
    解释器模式登机入口
    备忘录模式登机入口
    命令模式登机入口
    访问者模式登机入口
    软件设计7大原则和设计模式总结登机入口

    前言

    状态对于我们开发者而言是相当熟悉的,平常开发中总是离不开对象的状态,比如我们审核流程,就是一个状态不断流转的过程,订单流程也是一个状态不断流转的过程,而状态模式就是为了更好地解决我们状态流转过程中的业务处理逻辑。

    什么是状态模式

    状态模式(State Pattern)也称为状态机模式(State Machine Pattern),是允许对象在内部状态发生改变的同时改变对象的行为,使得看起来像是修改了类一样。

    状态模式中的类的行为是由状态决定的,不同的状态有不同的行为。状态模式的意图是让一个对象在其内部改变时行为也随之一起改变。

    状态模式的核心就是给每一种状态绑定一种行为。

    好了,装逼时刻又到了:Talk is cheap,Show you the code,先看一个非常简单的例子。

    状态模式示例

    下面我们就以订单状态的流转来写一个简单的示例,我们假设订单只有三个状态:待支付,待收货,已收货(完成)。

    1、首先建立一个抽象的状态类,这个类需要定义所有状态的所有行为:

    package com.zwx.design.pattern.state;
    
    public abstract class AbstractOrderState {
        protected OrderContext orderContext;
    
        public AbstractOrderState(OrderContext orderContext) {
            this.orderContext = orderContext;
        }
    
        public abstract void payOrder();
    
        public abstract void deliver();
    
        public abstract void receiveGoods();
    }
    

    注意这里面集成了一个OrderContext对象,这个对象是用来负责状态的切换的。

    2、因为有三个状态,所以我们新建三个具体的状态类来实现抽象状态类:

    • 待支付状态类:
    package com.zwx.design.pattern.state;
    
    public class WaitPaidOrderState extends AbstractOrderState {
        public WaitPaidOrderState(OrderContext orderContext) {
            super(orderContext);
        }
    
        @Override
        public void payOrder() {//相当于待支付的状态绑定了支付行为
            System.out.println("支付成功");
            this.orderContext.setState(this.orderContext.waitDeliver);//切换状态
        }
    
        @Override
        public void deliver() {
            System.out.println("对不起,请先付钱");
        }
    
        @Override
        public void receiveGoods() {
            System.out.println("对不起,请先付钱");
        }
    }
    
    • 待发货状态类:
    package com.zwx.design.pattern.state;
    
    public class WaitDeliverOrderState extends AbstractOrderState {
        public WaitDeliverOrderState(OrderContext orderContext) {
            super(orderContext);
        }
    
        @Override
        public void payOrder() {
            System.out.println("你已经付过钱了");
        }
    
        @Override
        public void deliver() {
            System.out.println("商品已发货并送达目的地");
            this.orderContext.setState(this.orderContext.receiveGoods);//切换状态
        }
    
        @Override
        public void receiveGoods() {
            System.out.println("请稍等,商品即将发货");
        }
    }
    
    • 已收货状态类:
    package com.zwx.design.pattern.state;
    
    public class ReceiveGoodsOrderState extends AbstractOrderState{
        public ReceiveGoodsOrderState(OrderContext orderContext) {
            super(orderContext);
        }
    
        @Override
        public void payOrder() {
            System.out.println("您已经付过钱啦,不要重复付钱哦");
        }
    
        @Override
        public void deliver() {
            System.out.println("商品已发货并送达,请不要重复发货");
        }
    
        @Override
        public void receiveGoods() {
            System.out.println("用户已收到商品,此次交易结束");
        }
    }
    

    我们可以看到,每个状态都绑定了一个行为(也可以支持绑定多个),并且在对应的行为处理完毕之后会流转到下一个状态,对于不属于当前状态的行为则做出相应的回应。

    3、再建立一个状态上下文环境类,用来负责具体状态的切换:

    package com.zwx.design.pattern.state;
    
    /**
     * @author zwx
     * @version 1.0
     * @date 2020/10/5
     * @since jdk1.8
     */
    public class OrderContext {
        AbstractOrderState waitPaid;
        AbstractOrderState waitDeliver;
        AbstractOrderState receiveGoods;
    
        AbstractOrderState currState;//当前状态
    
        public OrderContext() {
            this.waitPaid = new WaitPaidOrderState(this);
            this.waitDeliver = new WaitDeliverOrderState(this);
            this.receiveGoods = new ReceiveGoodsOrderState(this);
            currState = waitPaid;
        }
    
        void setState(AbstractOrderState state){
            this.currState = state;
        }
    
        public void payOrder(){
            currState.payOrder();
        }
    
    
        public void deliver(){
            currState.deliver();
        }
    
        public void receiveGoods(){
            currState.receiveGoods();
        }
    }
    

    可以看到,这个类里面也有点委派模式的影子,不同的行为委派给对应的对象进行处理而自己不做处理,只负责状态的切换。

    4、最后再新建一个测试类进行测试:

    package com.zwx.design.pattern.state;
    
    public class TestState {
        public static void main(String[] args) {
            OrderContext orderContext = new OrderContext();
            orderContext.payOrder();
            orderContext.deliver();
            orderContext.receiveGoods();
        }
    }
    

    输出结果为:

    支付成功
    商品已发货并送达目的地
    用户已收到商品,此次交易结束
    

    状态模式角色

    从上面示例中,我们可以得出状态模式主要有3个角色:

    • 环境类角色(Context):定义客户端需要的接口,内部维护一个当前状态实例,并负责具体状态的切换。
    • 抽象状态角色(State):定义每个状态下对应的行为,可以有一个或者多个行为。
    • 具体状态角色(ConcreteState):具体实现该状态对应的行为,并且在需要的情况下实现状态的切换。

    状态模式与责任链模式

    看这个状态模式的实现是有点和责任链模式相似,都是一条链去处理,可以这么说在某种场景下这两种模式可以互相替换,但是这两种模式也是有本质区别的。

    • 状态模式:
      状态模式的下一个节点是各个状态对象已经了解的,而且状态的流转就是由内部进行流转,客户端无法决定。
    • 责任链模式
      “链路”上的对象并不知道下一个节点处理人是谁,而是由客户端自行组装决定的。

    状态模式与策略模式

    状态模式和策略模式都能用来消除大量的if/else场景,但是也有本质区别。策略模式中各个策略之间是独立的,相互可以替换的,任意选择其中一个策略就能满足需求,而且是由客户端自己做出选择。而状态模式客户端只能选择初始节点,后续就会自动流转,各个状态是一个整体,不存在可以互相替换的状态。

    状态模式应用场景

    当控制一个对象状态的条件表达式过于复杂的时候,就可以考虑使用状态模式,通过把状态的判断逻辑转移到表示不同状态的一系列类中,这样就可以把复杂的逻辑简单化,使得对象的行为依赖于它的状态,并且会随着状态的改变而同时改变行为。
    状态模式主要应用于以下场景:

    • 1、对象的行为需要随着状态的改变而改变时。
    • 2、当我们一个操作中需要根据状态来写大量的if/else逻辑时

    状态模式优缺点

    优点:

    • 1、通过将每个状态设置为独立的对象,消除了代码中存在的大量if/else等判断分支,使得代码更加简洁,更容易维护。
    • 2、将不同的状态通过不同的类来表示,使得状态切换时相比较于用数字或者字符串来表示时更加直观,转换目的也更加明确。
    • 3、每个状态类的职责单一明确,易于扩展。

    缺点

    • 1、状态过多会引起类膨胀(事实上这也是大部分设计模式的通病)。
    • 2、状态模式的结构与实现相对较为复杂,容易造成代码混乱。
    • 3、对于支持状态切换的状态类违反了开闭原则,因为一旦状态修改或者中间要新增状态,则需要修改对应的源代码,否则会出现状态切换错误。

    总结

    本文主要介绍了状态模式的定义,并通过一个简单的示例来实现了一个简单的状态模式,最后将状态模式和责任链模式进行了对比分析,明确了其和策略模式,责任链模式的区别。

    请关注我,和孤狼一起学习进步

    展开全文
  • 【设计模式系列23】设计模式的终极BOSS:访问者模式

    千次阅读 热门讨论 2020-11-01 11:08:23
    设计模式系列到这里已经是23种设计模式的最后一个设计模式了,访问者模式也可以说是所有设计模式中最难的一种设计模式了,当然我们平常也很少会用到它。设计模式的作者是这么评价访问者模式的:大多情况下,你并不...

    设计模式系列总览

    设计模式飞机票
    三大工厂模式登机入口
    策略模式登机入口
    委派模式登机入口
    模板方法模式登机入口
    观察者模式登机入口
    单例模式登机入口
    原型模式登机入口
    代理模式登机入口
    装饰者模式登机入口
    适配器模式登机入口
    建造者模式登机入口
    责任链模式登机入口
    享元模式登机入口
    组合模式登机入口
    门面模式登机入口
    桥接模式登机入口
    中介者模式登机入口
    迭代器模式登机入口
    状态模式登机入口
    解释器模式登机入口
    备忘录模式登机入口
    命令模式登机入口
    访问者模式登机入口
    软件设计7大原则和设计模式总结登机入口

    前言

    设计模式系列到这里已经是23种设计模式的最后一个设计模式了,访问者模式也可以说是所有设计模式中最难的一种设计模式了,当然我们平常也很少会用到它。设计模式的作者是这么评价访问者模式的:大多情况下,你并不需要使用访问者模式,但是一旦需要使用它时,那就真的需要使用了。

    什么是访问者模式

    访问者模式(Vistor Pattern)是一种将数据结构与数据操作分离的的设计模式。是指封装一些作用于某种数据结构中的各种元素的操作,它可以在不改变数据结构的前提下定义作用于这些元素的新操作,访问者模式属于行为型模式。

    访问者模式的基本思想是针对系统中拥有的某些固定类型的对象结构(元素),在其内提供一个accept()方法用来接受访问者对象的访问。不同的访问者对同一元素的访问内容不同,使得相同的元素集合可以产生不同的元素结果。accept()方法可以接受不同的访问者对象,然后在内部将自己转发到访问者对象visit()方法内。

    访问者模式的核心思想是解耦数据结构与数据操作,使得对元素的操作具备优秀的扩展性,我们可以通过扩展不同的数据操作类型(访问者)实现对相同元素的不同操作。

    看了这一大堆的理论概念,是不是感觉有点晕,这个听起来确实是有点抽象,别急,继续往下看:

    装逼时刻又到了:Talk is cheap,Show you the code,我们通过一个例子来看看访问者模式的写法。

    访问者模式示例

    我们以餐厅点菜的时候,顾客需要通过菜单查看点菜为例子,在这个例子里面顾客就是访问者,而菜品就是访问者需要访问的信息。

    1、首先建立一个菜品(食谱)接口,只定义一个接受访问者来访问的方法:

    package com.zwx.design.pattern.visitor;
    
    public interface IRecipe {
        void accept(ICustomer customer);
    }
    

    接下来我们只列举两种视频,一种红烧肉,一种时蔬。所以需要两个类:

    package com.zwx.design.pattern.visitor;
    
    public class Meat implements IRecipe {
        @Override
        public void accept(ICustomer customer) {
            customer.visit(this);
        }
    
        public String getPrice(){
            return "88元/份";
        }
    }
    
    package com.zwx.design.pattern.visitor;
    
    public class Cabbage implements IRecipe {
        @Override
        public void accept(ICustomer customer) {
            customer.visit(this);
        }
    
        public String getPrice(){
            return "44元/份";
        }
    }
    

    这两个类里面除了实现了accept方法,另外都提供了一个查看价格的方法。

    3、这时候我们需要建立一个抽象的访问者:

    package com.zwx.design.pattern.visitor;
    
    public interface ICustomer {
        void visit(Meat meat);
        void visit(Cabbage cabbage);
    }
    

    里面定义两个方法名相同的方法,但是参数不同,参数对应元素,理论上我们上面有几个菜品这里就需要定义几个方法,也就是方法个数和要访问元素的个数要相等。

    4、接下来再建立一个顾客A的具体访问者角色来实现抽象访问者:

    package com.zwx.design.pattern.visitor;
    
    public class CustomerA implements ICustomer{
        @Override
        public void visit(Meat meat) {
            System.out.println("肉类:" + meat.getPrice());
        }
    
        @Override
        public void visit(Cabbage cabbage) {
            System.out.println("时蔬:" + cabbage.getPrice());
        }
    }
    

    现在访问者有了,菜品也有了,那么还少一个菜单,因为顾客需要通过菜单去查看菜品信息,然后点菜,所以我们还需要菜单类来管理所有菜品。

    5、新建一个菜单类:

    package com.zwx.design.pattern.visitor;
    
    import java.util.ArrayList;
    import java.util.List;
    
    public class RestaurantMenu {
        private List<IRecipe> recipeList = new ArrayList<>();
    
        public RestaurantMenu(IRecipe recipe) {
            recipeList.add(recipe);
        }
    
        public void addRecipe(IRecipe recipe){
            recipeList.add(recipe);
        }
    
        public void display(ICustomer customer){
            for (IRecipe recipe : recipeList){
                recipe.accept(customer);
            }
        }
    }
    

    菜单类里面通过一个list维护了所有菜品,然后通过display方法来展示所有菜品信息。

    6、接下来我们建立一个测试类来测试一下:

    package com.zwx.design.pattern.visitor;
    
    public class TestVistor {
        public static void main(String[] args) {
            IRecipe recipe = new Meat();
            RestaurantMenu menu = new RestaurantMenu(recipe);
            menu.addRecipe(new Cabbage());
            menu.display(new CustomerA());
        }
    }
    

    输出如下信息:

    肉类:88/份
    时蔬:44/

    这就是一个访问者模式,上面因为访问者肯定是经常变化的,但是我们只需要再增加顾客类就行了,非常方便。

    如果大家是第一次接触访问者模式,可能会觉得示例还是有点抽象,那么我建议大家是对照例子自己多写几遍,慢慢就会找到感觉。

    访问者模式角色

    从上面示例中,我们可以得出访问者模式主要有5个角色:

    • 抽象访问者(Vistor):接口或者抽象类都可以(如示例中的ICustomer)。这个角色主要是定义对具体元素的visit方法,参数就是具体元素,理论上来说方法数等于元素个数。所以说如果元素不稳定经常变化的话,那么访问者是要一直修改的,并不适合使用访问者模式,所以访问者模式适用于元素结构比较稳定的场景。
    • 具体访问者(ConcreteVistor):实现对具体元素的访问(如示例中的CustomerA)。
    • 抽象元素(Element):接口或者抽象类。定义了一个接受访问者访问的方法accept(如示例中的IRecipe)。
    • 具体元素(ConcreteElement):提供接受访问者访问的具体实现,通常都是采用visitor.visit()来实现(如示例中的Cabbage和Meat)。
    • 结构对象(ObjectStruture):用来维护元素,并提供一个方法来接受访问者访问所有的元素(如示例中的RestaurantMenu)。

    访问者模式适用场景

    访问者模式适用于以下场景:

    • 1、数据结构要稳定,但是作用于数据结构上的操作经常变化(如上面示例中如果菜谱经常发生变化,那么每次变化都要修改访问者对象)。
    • 2、需要对不同数据类型(元素)进行操作,而不使用分支判断具体类型的场景。

    访问者模式优缺点

    优点:

    • 1、解耦了数据结构和数据操作,使得操作集合可以独立变化。
    • 2、访问者角色非常易于扩展。
    • 3、每种角色各司其职,符合单一职责原则。
      缺点
    • 1、增加元素类型困难,如果元素类型变化就需要修改访问者源码,违反了开闭原则,也不利于维护。
    • 2、违背了依赖倒置原则,比如我们示例中的访问者接口,定义的方法依赖的是具体元素而不是抽象元素。

    总结

    本文主要介绍了GoF23种设计模式中的最后一种设计模式,也是最难的一种设计模式,堪称为设计模式的终极BOSS,通过了一个示例来示范了访问者模式的写法,最后归纳总结了访问者模式的角色及其优缺点。

    请关注我,和孤狼一起学习进步

    展开全文
  • 总体来说设计模式分为三大类... 行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。  其实还有两类:并发

      总体来说设计模式分为三大类:
      创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
      结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
      行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
      其实还有两类:并发型模式和线程池模式。
      这章开始,讲下7种结构型模式:适配器模式(Adapter)、桥接模式(Bridge)、组合模式(Composite)、装饰模式(Decorator)、外观模式(Facade)、享元模式(Flyweight)、代理模式(Proxy)。其中对象的适配器模式是各种模式的起源,我们看下面的图:

    1、适配器模式

      适配器模式(Adapter)将某个类的接口转换成客户端期望的另一个接口表示,目的是消除由于接口不匹配所造成的类的兼容性问题。主要分为三类:类的适配器模式、对象的适配器模式、接口的适配器模式。
      

    1.1、类的适配器模式

      也是适配器模式的通常代码:
      1.目标角色

    public interface Target {
    
        // 目标角色有自己的方法
        void request();
    }

      2.目标角色的实现类

    public class ConcreteTarget implements Target {
        public void request() {
             // 实现
        }
    }

      3.源角色

    public class Adaptee {
        // 原有的业务逻辑
        public void doSomething(){
        }
    }

      4.适配器角色:最核心

    public class Adapter extends Adaptee implements Target{
    
        public void request() {
            super.doSomething();
        }
    }

      场景类

        @Test
        public void test() {
            // 原有的业务逻辑
            Target target = new ConcreteTarget();
            target.request();
    
            // 现在增加了适配器角色的业务逻辑
            Target target2 = new Adapter();
            target2.request();
        }

    1.2、对象的适配器模式

      基本思路和类的适配器模式相同,只是将Adapter类作修改,这次不继承Adaptee类,而是持有Adaptee类的实例,以达到解决兼容性的问题。如果要适配多个对象,就要用这种

    public class Adapter implements Target{
        private Adaptee adaptee1;
        private Adaptee adaptee2;
    
        public Adapter(Adaptee adaptee12 private Adaptee adaptee2){  // 持有实例
            super();  
            this.adaptee1 = adaptee1;  
            this.adaptee2 = adaptee2; 
        }  
    
        public void request() {
            super.doSomething();
        }
    }

    1.3、接口的适配器模式

      第三种适配器模式是接口的适配器模式,接口的适配器是这样的:有时我们写的一个接口中有多个抽象方法,当我们写该接口的实现类时,必须实现该接口的所有方法,这明显有时比较浪费,因为并不是所有的方法都是我们需要的,有时只需要某一些,此处为了解决这个问题,我们引入了接口的适配器模式,借助于一个抽象类,该抽象类实现了该接口,实现了所有的方法,而我们不和原始的接口打交道,只和该抽象类取得联系,所以我们写一个类,继承该抽象类,重写我们需要的方法就行。看一下类图:

    public abstract class Adapter implements Target{
        public void method1(){}
        public void method2(){}
    }

    总结:
      的适配器模式:当希望将一个类转换成满足另一个新接口的类时,可以使用类的适配器模式,创建一个新类,继承原有的类,实现新的接口即可。
      对象的适配器模式:当希望将一个对象转换成满足另一个新接口的对象时,可以创建一个Wrapper类,持有原类的一个实例,在Wrapper类的方法中,调用实例的方法就行。
      接口的适配器模式:当不希望实现一个接口中所有的方法时,可以创建一个抽象类Wrapper,实现所有方法,我们写别的类的时候,继承抽象类即可。

    优点:
      1).适配器模式可以让两个没有任何关系的类在一起运行
      2).增加了类的透明性
      3).提高了类的复用度,灵活性非常好

    注意事项:适配器模式最好在详细设计阶段不要考虑它,它不是为了解决还处在开发阶段中接口时,而是解决正在服役的项目问题,该模式使用的主要场景是扩展应用中。
      再次提醒,项目一定要遵守依赖倒置原则和里氏替换原则。


    2、桥接模式(Bridge)

      桥接模式将抽象化与实现化解耦,使得二者可以独立变化。桥梁模式的重点是在“解耦”上,如何让它们两者解耦是我们要了解的重点。
      桥接模式是一个非常简单的模式,它只是使用了类间的聚合关系、继承、覆写等常用功能 。
      像我们常用的JDBC桥DriverManager一样,JDBC进行连接数据库的时候,在各个数据库之间进行切换,基本不需要动太多的代码,甚至丝毫不用动,原因就是JDBC提供统一接口,每个数据库提供各自的实现,用一个叫做数据库驱动的程序来桥接就行了。我们来看看关系图:

    记住一句话:抽象角色引用实现角色,或者说抽象角色的部分实现是由实现角色完成的。
    1.Implementor: 实现化角色
      它是接口或抽象类,定义角色必需的行为和属性

    public interface Implementor {
        // 基本方法
        void doSomething();
        void doAnything();
    }

    2.具体实现化角色

    public class ConcreteImplementor implements Implementor {
        public void doSomething() {
            // 业务逻辑处理
        }
    
        public void doAnything() {
    
        }
    }

    3.抽象化角色
      定义出该角色的行为,同时保存一个对实现化角色的引用,该角色一般是抽象类。
      为什么要增加一个构造函数?是为了提醒子类,你必须做这项工作,指定实现者,特别是已经明确了实现者,则尽量清晰明确地定论出来。如果没有写,实现化角色有很多子接口,下面就会是一堆子实现。

    public abstract class Abstraction {
        private Implementor implementor;
    
        // 约束子类必须实现该构造函数
        public Abstraction(Implementor implementor) {
            this.implementor = implementor;
        }
    
        // 自身的行为和属性
        public void request(){
            this.implementor.doSomething();
        }
    
        public Implementor getImplementor() {
            return implementor;
        }
    }

    4.具体抽象化角色
      它引用实现化角色对抽象化角色进行修正

    public class RefinedAbstraction extends  Abstraction {
        public RefinedAbstraction(Implementor implementor) {
            super(implementor);
        }
    
        // 修正父类的行为
        @Override
        public void request() {
            super.request();
            super.getImplementor().doAnything();
        }
    }

    5.场景类

        @Test
        public void test(){
            // 定义一个实现化角色
            Implementor implementor = new ConcreteImplementor();
            // 定义一个抽象化角色
            Abstraction abstraction = new RefinedAbstraction(implementor);
    
            abstraction.request();
        }

    优点
      1).抽象和实现的分离
      这也是桥梁模式的主要特点,它完全是了为解决继承的缺点而提出的设计模式,在该模式下,实现可以不受抽象的约束,不用再绑定在一个固定的抽象层次上。
      2).优秀的扩充能力
      3).实现细节对客户透明,客户不用关心细节的实现,因为已经封装了。

    使用场景:
      1).不希望或不适用使用继承的场景
      2).接口或抽象类不稳定
      明知道接口不稳定还想通过实现或继承来实现业务需求,那是得不偿失的。
      3).重要性要求较高的场景

    注意:
      继承是有缺点,就是强侵入,父类有一个方法,子类也会有这个方法,这样会导致不能随便修改父类。对于比较明确不发生变化的,可以通过继承来实现;若不能确定是否会发生变化的,那就认为是发生变化,则通过桥梁模式来解决。


    3、组合模式(Composite)

      组合模式有时又叫部分-整体模式在处理类似树形结构的问题时比较方便,看看关系图:

    public class TreeNode {  
    
        private String name;  
        private TreeNode parent;  
        private Vector<TreeNode> children = new Vector<TreeNode>();  
    
        public TreeNode(String name){  
            this.name = name;  
        }  
    
        public String getName() {  
            return name;  
        }  
    
        public void setName(String name) {  
            this.name = name;  
        }  
    
        public TreeNode getParent() {  
            return parent;  
        }  
    
        public void setParent(TreeNode parent) {  
            this.parent = parent;  
        }  
    
        //添加孩子节点  
        public void add(TreeNode node){  
            children.add(node);  
        }  
    
        //删除孩子节点  
        public void remove(TreeNode node){  
            children.remove(node);  
        }  
    
        //取得孩子节点  
        public Enumeration<TreeNode> getChildren(){  
            return children.elements();  
        }  
    }  
    public class Tree {  
    
        TreeNode root = null;  
    
        public Tree(String name) {  
            root = new TreeNode(name);  
        }  
    
        public static void main(String[] args) {  
            Tree tree = new Tree("A");  
            TreeNode nodeB = new TreeNode("B");  
            TreeNode nodeC = new TreeNode("C");  
    
            nodeB.add(nodeC);  
            tree.root.add(nodeB);  
            System.out.println("build the tree finished!");  
        }  
    }  
    

    使用场景:将多个对象组合在一起进行操作,常用于表示树形结构中,例如二叉树,数等。

    4、装饰模式(Decorator)

      装饰模式:动态地给一个对象添加一些额外的职责。就增加功能来说,装饰模式相比生成子类更加灵活,是对继承的有力补充。要求装饰对象和被装饰对象实现同一个接口,装饰对象持有被装饰对象的实例,关系图如下:
      

    在装饰模式中,必然有一个最基本、最核心、最原始的接口或抽象类充当Component抽象构件

    抽象构件
      是一个接口或是抽象类,就是定义我们最核心的对象,也就是最原始的对象。

    public abstract class Component {
        public abstract void operate();
    }

    具体构件
      最原始、最基本、最核心的接口或抽象类的实现,你要装饰的就是它

    public class ConcreteComponent extends Component {
        // 具体实现
        @Override
        public void operate() {
        }
    }

    抽象装饰者
      一般是一个抽象类,主要是实现接口或抽象方法,它里面不一定有抽象的方法,在它的属性里必然有一个private变量指向Conponent抽象构件。

    public abstract class Decorator extends Component {
        private Component component = null;
    
        // 通过构造函数传递被修饰者
        public Decorator(Component component) {
            this.component = component;
        }
    
        // 委托给被修改者执行
        @Override
        public void operate() {
            this.component.operate();
        }
    }

    具体的装饰类
      把最基本的东西装饰成其他的东西。

    public class ConcreteDecorator extends Decorator {
        public ConcreteDecorator(Component component) {
            super(component);
        }
    
        // 定义自己的装饰方法
        public void method1() {
            System.out.println("method1装饰");
        }
    
        // 重写父类的方法,这里的顺序是固定的,可以通过重载实现多种顺序
        public void operate() {
            this.method1();
            super.operate();
        }
    }

    优点:
      1).装饰类和被装饰类可以独立发展,而不会相互耦合。也就是说Component类无须知道Decorator类,Decorator类是从外部来扩展Component类的功能,而它也不用知道具体的构件。
      2).装饰模式是继承关系的一个替代方案。看装饰类Decorator,不管装饰多少层,返回的对象还是Component,实现的还是is-a的关系。
      3).装饰模式可以动态地扩展一个实现类的功能。
    缺点:
      多层的装饰模式是比较复杂的,就像剥洋葱一样,剥到最后才发现是最里层的装饰出现了问题,工作量会很多,也会产生过多相似的对象,不易排错。因此尽量减少装饰类的数量,以降低系统的复杂度。

    应用场景:
      1).需要扩展一个类的功能,或给类增加附加功能。
      2).动态的为一个对象增加功能,而且还能动态撤销。(继承不能做到这一点,继承的功能是静态的,不能动态增删。)
      3).需要为一批的兄弟类进行改装或加装功能,首选装饰模式。


    5、外观/门面模式(Facade)

       门面模式也叫外观模式,是一种比较常用的封装模式:要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口,使得子系统更易于使用。
       门面模式注意“统一的对象”,也就是提供一个访问子系统的接口,除了这个接口不允许有任何访问子系统的行为发生。其通用类图如下:
           
       外观模式是为了解决类与类之间的依赖关系的,像spring一样,可以将类和类之间的关系配置到配置文件中,而外观模式就是将他们的关系放在一个Facade类中,降低了类类之间的耦合度,该模式中没有涉及到接口。

    subsystem子系统角色
       可以同时有一个或多个子系统。每一个子系统都不是一个单独的类,而是一个类的集合。子系统并不知道门面的存在,对于子系统而言,门面仅仅是另外一个客户端而已。
       下面用电脑的CPU,Memory来代表子系统

        public class CPU {  
            public void startup(){  
                System.out.println("cpu startup!");  
            }  
    
            public void shutdown(){  
                System.out.println("cpu shutdown!");  
            }  
        }  
        public class Memory {  
    
            public void startup(){  
                System.out.println("memory startup!");  
            }  
    
            public void shutdown(){  
                System.out.println("memory shutdown!");  
            }  
        }  

    Facade门面角色
       客户端可以调用这个角色的方法,此角色知晓子系统的所有功能和责任。一般情况下,本角色会将所有从客户端发来的请求委派到相应的子系统去,也就主该角色没有实际的业务逻辑,只是一个委托类。

        public class Facade {    // 可以当成Computer类去理解
            private CPU cpu;  
            private Memory memory;  
            private Disk disk;  
    
            public Facade(){  
                cpu = new CPU();  
                memory = new Memory();  
                disk = new Disk();  
            }  
    
            // 提供给自问访问的方法
            public void startup(){  
                cpu.startup();  
                memory.startup();  
            }  
    
            public void shutdown(){  
                cpu.shutdown();  
                memory.shutdown();  
            }  
        }  

       如果我们没有Facade类(实际可以理解为Computer类),那么,CPU、Memoryk他们之间将会相互持有实例,产生关系,这样会造成严重的依赖,修改一个类,可能会带来其他类的修改,这不是我们想要看到的,有了Facade类,他们之间的关系被放在了Facade类里,这样就起到了解耦的作用,这,就是外观模式!

    优点:
      1).减少系统的相互依赖,外界访问不用深入到子系统内部。
      2).提高了灵活性
      3).提高安全性
    缺点:
      最大的缺点就是不符合开闭原则,一旦系统出现错误,只能修改门面的代码,风险太大,所以设计的时候慎之又慎。
    使用场景:
      1).为了复杂的模式或子系统提供一个供外界访问的接口
      2).子系统相对独立,外界对子系统的访问只要黑箱操作即可


    6、享元模式(Flyweight)

      享元模式是池技术的重要实现方式,其定义如下:使用共享对象可有效地支持大量的细粒度的对象。主要目的是实现对象的共享,即共享池,当系统中对象多的时候可以减少内存的开销,通常与工厂模式一起使用。
      享元模式的定义为我们提出两个要求:细粒度的对象和共享对象。分配太多的的对象到应用程序中将有损程序的性能,同时还容易造成内存溢出,那怎么避免?就是享元模式提到的共享技术

    内存溢出对Java应用来说实在是太平常了,有以下两种可能
    1.内存泄漏
      无意识的代码缺陷,导致内存泄漏,JVM不能获得连续的内存空间
    2.对象太多
      代码写的太烂,产生的对象太多,内存被耗尽。

      要求细粒度对象,那么不可避免地使得对象数量多且性质相近,那我们就将这些对象的信息分为两个部分:内部状态(insrinsic)与外部状态(extrinsic)
    内部状态
      内部状态是对象可共享出来的信息,存储在享元对象内部并且不会随着环境改变而改变,它们可以作为一个对象的动态附加信息,不必直接储存在具体某个对象中,属于可以共享的部分。
    外部状态
      外部状态是对象得以依赖的一个标记,是随着环境改变而改变的、不可共享的状态,它是一批对象的统一标识,是唯一的一个索引值。
      
      FlyWeightFactory负责创建和管理享元单元,当一个客户端请求时,工厂需要检查当前对象池中是否有符合条件的对象,如果有,就返回已经存在的对象,如果没有,则创建一个新对象,FlyWeight是超类。一提到共享池,我们很容易联想到Java里面的JDBC连接池,想想每个连接的特点,我们不难总结出:适用于作共享的一些个对象,他们有一些共有的属性,就拿数据库连接池来说,url、driverClassName、username、password及dbname,这些属性对于每个连接来说都是一样的,所以就适合用享元模式来处理,建一个工厂类,将上述类似属性作为内部数据,其它的作为外部数据,在方法调用时,当做参数传进来,这样就节省了空间,减少了实例的数量。

      享元模式的目的在于运用共享技术,使得一些粒度的对象可以共享,我们的设计确实也应该这样,多使用细粒度的对象,便于重用或重构。下面看通用代码。
    抽象享元角色
      简单地说就是一个产品的抽象类,同时定义出对象的外部状态和内部状态的接口或实现。
      在该类里,一般需要把外部状态和内部状态(当然了可以没有内部状态,只有行为也是可以的)定义出来,避免子类的随意扩展。
      在对外部状态加上final关键字,防止意外产生,避免获得一个外部状态后无意修改了一下,池就混乱了。

    注意:在程序开发中,确认只需要一次赋值的属性则设置为final类型,避免无意修改导致逻辑混乱,特别是Session级的常量或变量

    public abstract class Flyweight {
        // 内部状态
        private String intrinsic;
    
        // 外部状态
        protected final String extrinsic;  // final方法必须初始化
    
        // 要求享元角色必须接受外部状态
        public Flyweight(String extrinsic) {
            this.extrinsic = extrinsic;
        }
    
        // 定义业务操作
        public abstract void operate();
    
        /*内部状态的getter/setter*/
        public String getIntrinsic() {
            return intrinsic;
        }
    
        public void setIntrinsic(String intrinsic) {
            this.intrinsic = intrinsic;
        }
    }

    具体享元角色
      具体的一个产品类,实现抽象角色定义的业务。该角色中需要注意的是内部状态处理应该与环境无关,不应该出现一个操作改变了内部状态,同时修改了外部状态,这是绝对不允许的。

    public class ConcreteFlyweight extends Flyweight {
        // 接受外部状态
        public ConcreteFlyweight(String extrinsic) {
            super(extrinsic);
        }
    
        // 根据外部状态进行逻辑处理
        @Override
        public void operate() {
        }
    }

    不可共享的享元角色
      不存在外部状态或者安全要求(如线程安全)不能使用共享技术的对象,该对象一般不会出现在享元工厂 中。

    享元工厂
      职责非常简单,就是构造一个池容器,同时提供从池中获得对象的方法

    public class FlyweightFactory {
        // 定义一个池容器
        private static HashMap<String ,Flyweight> pool = new HashMap<String, Flyweight>();
    
        // 享元工厂
        public static Flyweight getFlyweight(String extrinsic){
            Flyweight flyweight;  // 需要返回的对象
    
            if (pool.containsKey(extrinsic)) {
                flyweight = pool.get(extrinsic);
            } else {
                flyweight = new ConcreteFlyweight(extrinsic);
                pool.put(extrinsic, flyweight);
            }
    
            return flyweight;
        }
    }

    看个数据库连接池例子:

            /*公有属性*/  
            private String url = "jdbc:mysql://localhost:3306/test";  
            private String username = "root";  
            private String password = "root";  
            private String driverClassName = "com.mysql.jdbc.Driver"; 

      通过连接池的管理,实现了数据库连接的共享,不需要每一次都重新创建连接,节省了数据库重新创建的开销,提升了系统的性能!
      
    优点:
      享元模式是一个非常简单的模式,它可以大大减少应用程序创建的对象,降低程序内存的占用,增强程序的性能 。
    缺点:
      提高了系统的复杂性,需要分享出外部状态和内部状态,而且外部状态具有固化特性,不应该随内部状态改变而改变,否则系统的逻辑混乱。
    使用场景:
      1).系统中存在大量相似对象
      2).细粒度的对象都具备较近的外部状态,而且内部状态与环境无关,也就是说对象没有特定身份。
      3).需要缓冲池的场景。


    7、代理模式(Proxy)

      代理模式:为其他对象提供一种代理以控制对这个对象的访问。
      代理模式也叫做委托模式,它是一项基本设计技巧。许多其他的模式,如状态模式、策略模式、访问者模式本质上是在更特殊的场合采用了代理模式,而且在日常的应用中,代理模式可以提供非常好的访问控制。
      通用类图如下:
      
    抽象主题类
      抽象类或接口,是一个最普通的业务类型定义,无特殊要求。

    public interface Subject {
        void request();
    }

    真实主题类
      也叫被委托角色、被代理角色。业务逻辑的具体执行者。

    public class RealSubject implements Subject{
        @Override
        public void request() {
            // 业务逻辑处理
        }
    }

    代理类
      也叫委托类、代理类。它负责对真实角色的应用,把所有抽象主题类定义的方法限制委托给真实主题角色实现,并且在真实主题角色处理完毕前后做预处理和善后处理工作。

    public class Proxy implements Subject {
        // 要代理哪个实现类
        private Subject subject;
    
        // 默认被代理者
        public Proxy(){
            super();
            this.subject = new Proxy();    // new代理对象
        }
    
        // 你要代理谁就产生该代理的实例,然后把代理者传递进来
        public Proxy(Subject subject) {
            this.subject = subject;
        }
    
        // 实现接口中定义的方法
        @Override
        public void request() {
            this.before();
            subject.request();
            this.after();
        }
    
        private void after() {
            System.out.println("after proxy!");
        }
    
        private void before() {
            System.out.println("before proxy!");
        }
    }

    优点:
      1).职责清晰。真实的角色就是实现实际的业务逻辑,不用关心其他非本职的事务。
      2).高扩展性。具体主题角色只要实现了接口,无论它如何发生变化,我们代理类完全在不做任何修改的情况下使用。
      3).智能化。在动态代理中中体现。
    使用场景:
      为什么要代理?就跟打官司要找律师一样。最经典的使用就是Spring AOP,这是一个非常典型的动态代理。
      
    普通代理与强制代理
    在网络上代理服务设置分为透明代理和普通代理。
      透明代理:就是用户不用设置代理服务器地址,就可以直接访问,也就是说代理服务器对用户来说是透明的,不用知道它存在。
      普通代理:需要用户自己设置代理服务器的IP地址,用户必须知道代理的存在。
      强制代理:需要用户必须通过真实角色查找代理角色,否则你不能访问。如你认识一明星,有件事需要她确认,于是你直接打这个明星的电话,但她说太忙,要我找她的经纪人,最后返回的还是她的代理。

    7.1.动态代理

      动态代理是在实现阶段不用关心代理谁,而是在运行阶段才指定代理哪一个对象,AOP的核心就是采用了动态代理机制。(到时结合spring源码分析一波)

    展开全文
  • Android设计模式之——命令模式

    千次阅读 2017-10-29 20:56:30
    命令模式相对于其他的设计模式来说并没有那么多的条条框框,其实它不是一个很”规范“的模式,不过,就是基于这一点,命令模式相对于其他的设计模式更为灵活多变。我们接触比较多的命令模式个例无非就是程序菜单命令...
  • 观察者模式是经典设计模式中很常用的一种,平常我们看到的监听器,基本上都是采用这种设计模式实现的,这里探讨一下观察者模式的演化
  • 平常

    千次阅读 热门讨论 2007-07-30 19:51:00
    翻开各种报刊杂志,劝诫人要学会保持“平常心”的文章总是很多,健康报刊里更是谆谆嘱咐我们要有一颗平常心。但是年岁越长,越知道恰恰看似普通的,却最难得到。没有平常心的人,不好好吃饭;没有平常心的人,不好好...
  • 【设计模式】建造者模式

    千次阅读 2018-08-03 20:17:34
    博主声明: 转载请在开头附加本文链接及作者信息,并标记为转载。... 今天我们来讲一讲在 Android 开发中最常用的设计模式 —— 建造者模式(Builder Pattern),这是一个变种了的建造者模式。 说...
  • 问题:  在页面上,用户会有很多的操作 ,每进行一次操作我们需要去展示操作的结果,在这里我们有了一个问题,我们应如何去展示不同的结果呢?... 这个方法也就是我们平常说的中介者模式,如果想了
  • Android设计模式之——观察者模式

    千次阅读 2017-10-30 11:01:09
    一、介绍观察者模式是一个使用率非常高的模式,它最常用的地方是GUI系统、订阅——发布系统。因为这个模式的一个重要作用就是解耦,将被观察者和观察者解耦,使得它们之间的依赖性更小,甚至做到毫无依赖。以GUI系统...
  • 不管我们以前用的对还是不对,这一次我们还是对以前在项目中用到过的设计模式更加的熟悉,所以总结一句话,我们在平常的编码过程中应该多用一些设计模式,这样我们才能更好的理解设计模式的精髓。
  • Java 设计模式——组合模式

    万次阅读 多人点赞 2016-05-17 17:39:45
    看到组合的模式的定义,或许你就知道了这里的组合与我们平常讨论的*“继承-组合”*并不是同一个概念。因为在学习组合模式之前,我就是把这两个弄得有点混淆,所以一直没有认真地学习过它,以为组合也就是那么回事了...
  • Springboot 使用设计模式- 策略模式

    千次阅读 2020-05-12 10:03:14
    平常的springboot项目里面做CRUD,我们的习惯性基本是 一个mapper,一个service,一个serviceImpl。 但是有时候会出现一种情况,就是实现类impl里面虽然业务主线是归为一致的,但是需要进行类别判断去执行不同的...
  • 在现实生活中工厂是负责生产产品的,同样在设计模式中,简单工厂模式我们也可以理解为负责生产对象的一个类, 我们平常编程中,当使用”new”关键字创建一个对象时,此时该类就依赖与这个对象,也就是他们之间的耦合度...
  • Java设计模式——23种模式

    万次阅读 2017-05-24 22:18:11
    背景最近在整合Java设计模式平常偶尔也遇到过,同事之间也讨论过这模式的特点,本次结合当前个人经验及网上各位大神的分享,然后得出比较通俗易懂,当然在现实的项目中,里面包含的一些设计模式是比这复杂,望读者...
  • 桥接模式(Bridge): 把事物和其具体实现分开(抽象化与实现化解耦),使他们可以各自...按平常的写法,咱要写2*4个类,但是使用了桥接模式,你只需写2+4个类,可以看出桥接模式其实就是一种将 N*M转化成N+M组合的思想。
  • 平常茶非常道教育教学课件ppt模板,影院模式放映观看.
  • 在Expresso中,测试“多行模式” 测试一 注意:这里样例文本中3eeeee后面没有回车,光标就在e的后面。匹配的结果是3eeeee,如上图的Search ...在windows中,我们平常说的换行,实质上是先回车,后换行;下面有更详
  • 设计模式初探-单例模式

    千次阅读 2014-01-03 00:00:37
    单例模式平常开发中经常用到,比如系统的全局配置属性,常用的工具类或工厂方法都可以实现为一个单例。单例模式概念很简单,实现起来也不麻烦,但一不小心还是有可能出错的。 一、使用场景 只要是要求实例唯一的都...
  • 设计模式学习笔记——迭代器模式

    千次阅读 2014-02-12 22:32:00
    迭代器模式据说有人要将它从设计模式中剔除,原因是各种语言基本都内置了这种模式,比如c#的foreach语句,实在是太平常了,不值得特别一提。但我对这个迭代器,尤其是.NET的IEnumerable、IEnumerator甚感迷惑,有...
  • C语言和设计模式(责任链模式

    万次阅读 2011-12-19 20:47:23
     责任链模式是很实用的一种实际方法。举个例子来说,我们平常在公司里面难免不了报销流程。但是,我们知道公司里面每一级的领导的报批额度是不一样的。比如说,科长的额度是1000元,部长是10000元,总经理是10万元...
  • C#设计模式--桥接模式

    千次阅读 2017-03-01 17:22:15
    0.C#设计模式--简单工厂模式 1.C#设计模式--工厂方法模式 2.C#设计模式--抽象工厂模式 3.C#设计模式--单例模式 4.C#设计模式--建造者模式 5.C#设计模式--原型模式 6.C#设计模式--适配器模式 7....
  • 设计模式2-简单工厂模式

    千次阅读 2015-10-09 23:37:47
    在现实生活中工厂是负责生产产品的,同样在设计模式中,简单工厂模式我们也可以理解为负责生产对象的一个类, 我们平常编程中,当使用”new”关键字创建一个对象时,此时该类就依赖与这个对象,也就是他们之间的耦合...
  • 工厂方法模式、抽象工厂模式、生成器模式和原型模式,除此之外还有最后一个单例模式。 掌握了的知识才是自己的 在本次编写的重学 Java 设计模式的编写中尽可能多的用各种场景案例还介绍设计的使用,包括我们已经使用...
  • 看得懂的外观设计模式 python3 实现

    千次阅读 多人点赞 2020-07-03 21:31:00
    外观设计模式平常的代码编写中,会经常使用。在平常代码的编写时,即使程序员没有从标准上认识过外观设计模式,但在开发的过程中,也会从代码的多方面角度考虑,从而编写了符合外观设计模式的代码。 很多程序员都...
  • 简介:为什么要开展设计模式这个专栏?设计模式对于开发而言无疑是一把‘神兵利器’的存在【用不好也是伤敌一千自损八百】。在JAVA底层包的源码,各大流行框架的代码设计中充满了设计模式的踪迹。无疑,掌握了设计...
  • 数据源架构模式之表入口模式

    千次阅读 2015-08-03 21:34:50
    martin fowler在《企业应用架构模式》一书中将我们平常接触到的应用开发分为三层:表现层、领域层和数据源层。 其中领域层的领域逻辑模式有:事务脚本、领域模型以及表模块。 1、事务脚本最容易理解也最易于开发,...
  • 【java设计模式】之 模板方法(Template Method)模式

    万次阅读 多人点赞 2016-05-06 08:57:43
     这一节主要来学习一下设计模式中的模板方法模式。我们先来看一个例子:假如现在老板让你做一个汽车的模型,要求只要完成基本功能即可,不考虑扩展性,那你会怎么做呢?我们首先会根据经验设计一个类图:  由这...
  • 设计模式学习总结——工厂模式

    千次阅读 多人点赞 2020-12-02 16:20:00
    在我们平常创建对象的时候,都是通过关键字 new 来实现的,例:Class A = new A()。在一些情况下,要创建的对象需要一系列复杂的初始化操作,比如查配置文件、查数据库表、...
  • 桥接模式

    千次阅读 2017-09-11 20:18:16
    因为这个模式网上有很多不恰当的例子,这里先引用百度百科的定义:桥接模式是将抽象部分与它的实现部分分离,使它们都可以独立地变化。它是一种对象结构型模式,又称为柄体(Handle and Body)模式或接口(Interface)...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 60,518
精华内容 24,207
关键字:

平常模式