精华内容
下载资源
问答
  • 网络应用程序设计模式
    千次阅读
    2019-05-20 13:29:18

    C/S模式

    传统的网络应用设计模式,客户机(client)/服务器(server)模式。需要在通讯两端各自部署客户机和服务器来完成数据通信。

    B/S模式

    浏览器(broswer)/服务器(server)模式。只需在一端部署服务器,而另外一端使用每台PC都默认配置的浏览器即可完成数据的传输。

    优缺点

    对于C/S模式来说,其优点明显。客户端位于目标主机上可以保证性能,将数据缓存至客户端本地,从而提高数据传输效率。一般来说客户端和服务器程序由一个开发团队创作,所以他们之间所采用的协议相对灵活。可以在标准协议的基础上根据需求裁剪及定制。例如,腾讯公司所采用的通信协议,即为ftp协议的修改剪裁版。

    因此,传统的网络应用程序及较大型的网络应用程序都首选C/S模式进行开发。如,知名的网络游戏魔兽世界。3D画面,数据量庞大,使用C/S模式可以提前在本地进行大量数据的缓存处理,从而提高观感。

    C/S模式的缺点也较突出。由于客户端和服务器都需要有一个开发团队来完成开发。工作量将成倍提升,开发周期较长。另外,从用户角度出发,需要将客户端安插至用户主机上,对用户主机的安全性构成威胁。这也是很多用户不愿使用C/S模式应用程序的重要原因。

    B/S模式相比C/S模式而言,由于它没有独立的客户端,使用标准浏览器作为客户端,其工作开发量较小。只需开发服务器端即可。另外由于其采用浏览器显示数据,因此移植性非常好,不受平台限制。如早期的偷菜游戏,在各个平台上都可以完美运行。

    B/S模式的缺点也较明显。由于使用第三方浏览器,因此网络应用支持受限。另外,没有客户端放到对方主机上,缓存数据不尽如人意,从而传输数据量受到限制。应用的观感大打折扣。第三,必须与浏览器一样,采用标准http协议进行通信,协议选择不灵活。
    因此在开发过程中,模式的选择由上述各自的特点决定。根据实际需求选择应用程序设计模式。

    更多相关内容
  • Java常见设计模式总结

    万次阅读 多人点赞 2021-09-18 17:18:54
    项目中合理的运用设计模式可以完美的解决很多问题,每种模式在现实中都相应的原理来与之对应,每种模式描述了一个在我们周围不断重复发生的问题,以及该问题的核心解决方案,这也是它能被广泛应用的原因。...

     一、设计模式总述:

    1、什么是设计模式:

            设计模式是一套经过反复使用的代码设计经验,目的是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 设计模式于己于人于系统都是多赢的,它使得代码编写真正工程化,它是软件工程的基石,如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决很多问题,每种模式在现实中都有相应的原理来与之对应,每种模式描述了一个在我们周围不断重复发生的问题,以及该问题的核心解决方案,这也是它能被广泛应用的原因。总体来说,设计模式分为三大类:

    • 创建型模式:共5种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式
    • 结构型模式:共7种:适配器模式、装饰器模式、代理模式、桥接模式、外观模式、组合模式、享元模式
    • 行为型模式:共11种:策略模式、模板方法模式、观察者模式、责任链模式、访问者模式、中介者模式、迭代器模式、命令模式、状态模式、备忘录模式、解释器模式

    其实还有两类:并发型模式和线程池模式,用一个图片来整体描述一下:

    2、设计模式的六大原则:

    (1)开闭原则 (Open Close Principle) :

            开闭原则指的是对扩展开放,对修改关闭。在对程序进行扩展的时候,不能去修改原有的代码,想要达到这样的效果,我们就需要使用接口或者抽象类

    (2)依赖倒转原则 (Dependence Inversion Principle):

            依赖倒置原则是开闭原则的基础,指的是针对接口编程,依赖于抽象而不依赖于具体

    (3)里氏替换原则 (Liskov Substitution Principle) :

            里氏替换原则是继承与复用的基石,只有当子类可以替换掉基类,且系统的功能不受影响时,基类才能被复用,而子类也能够在基础类上增加新的行为。所以里氏替换原则指的是任何基类可以出现的地方,子类一定可以出现。

            里氏替换原则是对 “开闭原则” 的补充,实现 “开闭原则” 的关键步骤就是抽象化,而基类与子类的继承关系就是抽象化的具体实现,所以里氏替换原则是对实现抽象化的具体步骤的规范。

    (4)接口隔离原则 (Interface Segregation Principle):

            使用多个隔离的接口,比使用单个接口要好,降低接口之间的耦合度与依赖,方便升级和维护方便

    (5)迪米特原则 (Demeter Principle):

            迪米特原则,也叫最少知道原则,指的是一个类应当尽量减少与其他实体进行相互作用,使得系统功能模块相对独立,降低耦合关系。该原则的初衷是降低类的耦合,虽然可以避免与非直接的类通信,但是要通信,就必然会通过一个“中介”来发生关系,过分的使用迪米特原则,会产生大量的中介和传递类,导致系统复杂度变大,所以采用迪米特法则时要反复权衡,既要做到结构清晰,又要高内聚低耦合。

    (6)合成复用原则 (Composite Reuse Principle):

            尽量使用组合/聚合的方式,而不是使用继承。

    二、Java的23种设计模式:

            接下来我们详细介绍Java中23种设计模式的概念,应用场景等情况,并结合他们的特点及设计模式的原则进行分析

    1、创建型-工厂方法模式:

    工厂方法模式分为三种:

    (1)简单工厂模式:

    建立一个工厂类,并定义一个接口对实现了同一接口的产品类进行创建。首先看下关系图:

    (2)工厂方法模式:

    工厂方法模式是对简单工厂模式的改进,简单工厂的缺陷在于不符合“开闭原则”,每次添加新产品类就需要修改工厂类,不利于系统的扩展维护。而工厂方法将工厂抽象化,并定义一个创建对象的接口。每增加新产品,只需增加该产品以及对应的具体实现工厂类,由具体工厂类决定要实例化的产品是哪个,将对象的创建与实例化延迟到子类,这样工厂的设计就符合“开闭原则”了,扩展时不必去修改原来的代码。UML关系图如下:

     (3)静态工厂方法模式:

    静态工厂模式是将工厂方法模式里的方法置为静态的,不需要创建实例,直接调用即可。

    工厂方法模式详情文章:Java设计模式之创建型:工厂模式详解(简单工厂+工厂方法+抽象工厂)

    2、创建型-抽象工厂模式:

            抽象工厂模式主要用于创建相关对象的家族。当一个产品族中需要被设计在一起工作时,通过抽象工厂模式,能够保证客户端始终只使用同一个产品族中的对象;并且通过隔离具体类的生成,使得客户端不需要明确指定具体生成类;所有的具体工厂都实现了抽象工厂中定义的公共接口,因此只需要改变具体工厂的实例,就可以在某种程度上改变整个软件系统的行为。

            但该模式的缺点在于添加新的行为时比较麻烦,如果需要添加一个新产品族对象时,需要更改接口及其下所有子类,这必然会带来很大的麻烦。

            UML结构图如下:

    抽象工厂模式详情:Java设计模式之创建型:工厂模式详解(简单工厂+工厂方法+抽象工厂)

    3、创建型-建造者模式:

             建造者模式将复杂产品的创建步骤分解在在不同的方法中,使得创建过程更加清晰,从而更精确控制复杂对象的产生过程;通过隔离复杂对象的构建与使用,也就是将产品的创建与产品本身分离开来,使得同样的构建过程可以创建不同的对象;并且每个具体建造者都相互独立,因此可以很方便地替换具体建造者或增加新的具体建造者,用户使用不同的具体建造者即可得到不同的产品对象。UML结构图如下:

     建造者模式详情:Java设计模式之创建型:建造者模式

    4、创建型-单例模式:

            单例模式可以确保系统中某个类只有一个实例,该类自行实例化并向整个系统提供这个实例的公共访问点,除了该公共访问点,不能通过其他途径访问该实例。单例模式的优点在于:

    • 系统中只存在一个共用的实例对象,无需频繁创建和销毁对象,节约了系统资源,提高系统的性能
    • 可以严格控制客户怎么样以及何时访问单例对象。

    单例模式的写法有好几种,主要有三种:懒汉式单例、饿汉式单例、登记式单例。

    单例模式详情:Java设计模式之创建型:单例模式

    5、创建型-原型模式:

            原型模式也是用于对象的创建,通过将一个对象作为原型,对其进行复制克隆,产生一个与源对象类似的新对象。UML类图如下:

     在 Java 中,原型模式的核心是就是原型类 Prototype,Prototype 类需要具备以下两个条件:

    • 实现 Cloneable 接口:
    • 重写 Object 类中的 clone() 方法,用于返回对象的拷贝;

    Object 类中的 clone() 方法默认是浅拷贝,如果想要深拷贝对象,则需要在 clone() 方法中自定义自己的复制逻辑。

    • 浅复制:将一个对象复制后,基本数据类型的变量会重新创建,而引用类型指向的还是原对象所指向的内存地址。
    • 深复制:将一个对象复制后,不论是基本数据类型还有引用类型,都是重新创建的。

            使用原型模式进行创建对象不仅简化对象的创建步骤,还比 new 方式创建对象的性能要好的多,因为 Object 类的 clone() 方法是一个本地方法,直接操作内存中的二进制流,特别是复制大对象时,性能的差别非常明显;

    原型模式详情:Java设计模式之创建型:原型模式

            

            上面我们介绍了5种创建型模式,下面我们就开始介绍下7种结构型模式:适配器模式、装饰模式、代理模式、外观模式、桥接模式、组合模式、享元模式。其中对象的适配器模式是各种模式的起源,如下图:

    6、结构型-适配器模式:

            适配器模式主要用于将一个类或者接口转化成客户端希望的格式,使得原本不兼容的类可以在一起工作,将目标类和适配者类解耦;同时也符合“开闭原则”,可以在不修改原代码的基础上增加新的适配器类;将具体的实现封装在适配者类中,对于客户端类来说是透明的,而且提高了适配者的复用性,但是缺点在于更换适配器的实现过程比较复杂。

            所以,适配器模式比较适合以下场景:

    • (1)系统需要使用现有的类,而这些类的接口不符合系统的接口。
    • (2)使用第三方组件,组件接口定义和自己定义的不同,不希望修改自己的接口,但是要使用第三方组件接口的功能。

    下面有个非常形象的例子很好地说明了什么是适配器模式:

    适配器模式的主要实现有三种:类的适配器模式、对象的适配器模式、接口的适配器模式。三者的使用场景如下:

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

    适配器模式详情:Java设计模式之结构型:适配器模式

    7、结构型-装饰器模式:

            装饰器模式可以动态给对象添加一些额外的职责从而实现功能的拓展,在运行时选择不同的装饰器,从而实现不同的行为;比使用继承更加灵活,通过对不同的装饰类进行排列组合,创造出很多不同行为,得到功能更为强大的对象;符合“开闭原则”,被装饰类与装饰类独立变化,用户可以根据需要增加新的装饰类和被装饰类,在使用时再对其进行组合,原有代码无须改变。装饰器模式的UML结构图如下:

            但是装饰器模式也存在缺点,首先会产生很多的小对象,增加了系统的复杂性,第二是排错比较困难,对于多次装饰的对象,调试时寻找错误可能需要逐级排查,较为烦琐。

    装饰器模式详情:Java设计模式之结构型:装饰器模式

    8、结构型-代理模式:

            代理模式的设计动机是通过代理对象来访问真实对象,通过建立一个对象代理类,由代理对象控制原对象的引用,从而实现对真实对象的操作。在代理模式中,代理对象主要起到一个中介的作用,用于协调与连接调用者(即客户端)和被调用者(即目标对象),在一定程度上降低了系统的耦合度,同时也保护了目标对象。但缺点是在调用者与被调用者之间增加了代理对象,可能会造成请求的处理速度变慢。UML结构图如下:

    代理模式详情:Java设计模式之结构型:代理模式

    9、结构型-桥接模式:

            桥接模式将系统的抽象部分与实现部分分离解耦,使他们可以独立的变化。为了达到让抽象部分和实现部分独立变化的目的,桥接模式使用组合关系来代替继承关系,抽象部分拥有实现部分的接口对象,从而能够通过这个接口对象来调用具体实现部分的功能。也就是说,桥接模式中的桥接是一个单方向的关系,只能够抽象部分去使用实现部分的对象,而不能反过来。 

            桥接模式符合“开闭原则”,提高了系统的可拓展性,在两个变化维度中任意扩展一个维度,都不需要修改原来的系统;并且实现细节对客户不透明,可以隐藏实现细节。但是由于聚合关系建立在抽象层,要求开发者针对抽象进行编程,这增加系统的理解和设计难度。桥接模式的UML结构图如下:

            就像在Java中我们使用 JDBC 连接数据库时,在各个数据库之间进行切换,基本不需要动太多的代码,原因就是使用了桥接模式,JDBC 提供统一接口,每个数据库提供各自的实现,然后由桥接类创建一个连接数据库的驱动,使用某一个数据库的时候只需要切换一下就行。JDBC 的结构图如下:

             在 JDBC 中,桥接模式的实现化角色 (Implementor) 为的 Driver 接口,具体实现化 (Concrete Implementor) 角色对应 MysqlDriver、OracleDriver 和 MariadbDriver,扩展抽象化 (Refined Abstraction) 角色对应 DriverManager,不具有抽象化 (Abstraction) 角色作为扩展抽象化角色的父类。

    桥接模式详情:Java设计模式之结构型:桥接模式

    10、结构型-外观模式:

            外观模式通过对客户端提供一个统一的接口,用于访问子系统中的一群接口。使用外观模式有以下几点好处:

    (1)更加易用:使得子系统更加易用,客户端不再需要了解子系统内部的实现,也不需要跟众多子系统内部的模块进行交互,只需要跟外观类交互就可以了;

    (2)松散耦合:将客户端与子系统解耦,让子系统内部的模块能更容易扩展和维护。

    (3)更好的划分访问层次:通过合理使用 Facade,可以更好地划分访问的层次,有些方法是对系统外的,有些方法是系统内部使用的。把需要暴露给外部的功能集中到门面中,这样既方便客户端使用,也很好地隐藏了内部的细节。

            但是如果外观模式对子系统类做太多的限制则减少了可变性和灵活性,所以外观模式适用于为复杂子系统提供一个简单接口,提高系统的易用性场景 以及 引入外观模式将子系统与客户端进行解耦,提高子系统的独立性和可移植性。

            外观模式的UML结构图如下:

    外观模式详情: Java设计模式之结构型:外观模式

    11、结构型-组合模式:

            组合模式将叶子对象和容器对象进行递归组合,形成树形结构以表示“部分-整体”的层次结构,使得用户对单个对象和组合对象的使用具有一致性,能够像处理叶子对象一样来处理组合对象,无需进行区分,从而使用户程序能够与复杂元素的内部结构进行解耦。

            组合模式最关键的地方是叶子对象和组合对象实现了相同的抽象构建类,它既可表示叶子对象,也可表示容器对象,客户仅仅需要针对这个抽象构建类进行编程,这就是组合模式能够将叶子节点和对象节点进行一致处理的原因。组合模式的UML结构图如下:

    组合模式详情: Java设计模式之结构型:组合模式

    12、结构型-享元模式:

            享元模式通过共享技术有效地支持细粒度、状态变化小的对象复用,当系统中存在有多个相同的对象,那么只共享一份,不必每个都去实例化一个对象,极大地减少系统中对象的数量,从而节省资源。

            享元模式的核心是享元工厂类,享元工厂类维护了一个对象存储池,当客户端需要对象时,首先从享元池中获取,如果享元池中存在对象实例则直接返回,如果享元池中不存在,则创建一个新的享元对象实例返回给用户,并在享元池中保存该新增对象,这点有些单例的意思。

            工厂类通常会使用集合类型来保存对象,如 HashMap、Hashtable、Vector 等等,在 Java 中,数据库连接池、线程池等都是用享元模式的应用。

            享元模式的UML结构图如下:

             Java 中,String 类型就是使用享元模式,String 对象是 final 类型,对象一旦创建就不可改变。而 Java 的字符串常量都是存在字符串常量池中的,JVM 会确保一个字符串常量在常量池中只有一个拷贝。

            而且提到共享池,我们也很容易联想到 Java 里面的JDBC连接池,通过连接池的管理,实现了数据库连接的共享,不需要每一次都重新创建连接,节省了数据库重新创建的开销,提升了系统的性能!

    享元模式详情:Java设计模式之结构型:享元模式

            前面我们介绍了7种结构型设计模式,接下来我们介绍一下11种行为型设计模式:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。先来张图,看看这11中模式的关系:

     13、行为型-策略模式:

            将类中经常改变或者可能改变的部分提取为作为一个抽象策略接口类,然后在类中包含这个对象的实例,这样类实例在运行时就可以随意调用实现了这个接口的类的行为。

            比如定义一系列的算法,把每一个算法封装起来,并且使它们可相互替换,使得算法可独立于使用它的客户而变化,这就是策略模式。UML结构图如下:

            策略模式的优点在于可以动态改变对象的行为;但缺点是会产生很多策略类,并且策略模式的决定权在用户,系统只是提供不同算法的实现,所以客户端必须知道所有的策略类,并自行决定使用哪一个策略类; 

            策略模式适用用于以下几种场景:

    • (1)应用程序需要实现特定的功能服务,而该程序有多种实现方式使用,所以需要动态地在几种算法中选择一种
    • (2)一个类定义了多种行为算法,并且这些行为在类的操作中以多个条件语句的形式出现,就可以将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。

    策略模式详情:Java设计模式之行为型:策略模式

    14、行为型-模板方法:

            模板方法是基于继承实现的,在抽象父类中声明一个模板方法,并在模板方法中定义算法的执行步骤(即算法骨架)。在模板方法模式中,可以将子类共性的部分放在父类中实现,而特性的部分延迟到子类中实现,只需将特性部分在父类中声明成抽象方法即可,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤,不同的子类可以以不同的方式来实现这些逻辑。

            模板方法模式的优点在于符合“开闭原则”,也能够实现代码复用,将不变的行为转移到父类,去除子类中的重复代码。但是缺点是不同的实现都需要定义一个子类,导致类的个数的增加使得系统更加庞大,设计更加抽象。模板方法模式的UML图如下:

    模板方法详情:Java设计模式之行为型:模板方法模式

    15、行为型-责任链模式:

            职责链可以将请求的处理者组织成一条链,并将请求沿着链传递,如果某个处理者能够处理请求则处理,否则将该请求交由上级处理。客户端只需将请求发送到职责链上,无须关注请求的处理细节,通过职责链将请求的发送者和处理者解耦了,这也是职责链的设计动机。        

           职责链模式可以简化对象间的相互连接,因为客户端和处理者都没有对方明确的信息,同时处理者也不知道职责链中的结构,处理者只需保存一个指向后续者的引用,而不需要保存所有候选者的引用。

            另外职责链模式增加了系统的灵活性,我们可以任意增加或更改处理者,甚至更改处理者的顺序,不过有可能会导致一个请求无论如何也得不到处理,因为它可能被放置在链末端。

    所以责任链模式有以下几个优点:

    • (1)降低耦合度,将请求的发送者和接收者解耦。反映在代码上就是不需要在类中写很多丑陋的 if….else 语句,如果用了职责链,相当于我们面对一个黑箱,只需将请求递交给其中一个处理者,然后让黑箱内部去负责传递就可以了。
    • (2)简化了对象,使得对象不需要链的结构。
    • (3)增加系统的灵活性,通过改变链内的成员或者调动他们的次序,允许动态地新增或者删除处理者
    • (4)增加新的请求处理类很方便。

    但是责任链模式也存在一些缺点:

    • (1)不能保证请求一定被成功处理
    • (2)系统性能将受到一定影响,并且可能会造成循环调用。
    • (3)可能不容易观察运行时的特征,而且在进行代码调试时不太方便,有碍于除错。

            责任链模式的UML结构图如下:

    责任链模式详情:Java设计模式之行为型:责任链模式

    16、行为型-观察者模式:

            观察者模式又称为 发布-订阅模式,定义了对象之间一对多依赖关系,当目标对象(被观察者)的状态发生改变时,它的所有依赖者(观察者)都会收到通知。一个观察目标可以对应多个观察者,而这些观察者之间没有相互联系,所以能够根据需要增加和删除观察者,使得系统更易于扩展,符合开闭原则;并且观察者模式让目标对象和观察者松耦合,虽然彼此不清楚对方的细节,但依然可以交互,目标对象只知道一个具体的观察者列表,但并不认识任何一个具体的观察者,它只知道他们都有一个共同的接口。

            但观察者模式的缺点在于如果存在很多个被观察者的话,那么将需要花费一定时间通知所有的观察者,如果观察者与被观察者之间存在循环依赖的话,那么可能导致系统崩溃,并且观察者模式没有相应的机制让观察者知道被观察对象是怎么发生变化的,而仅仅只是知道观察目标发生了变化。观察者模式的UML结构图如下:

     观察者模式详情:Java设计模式之行为型:观察者模式

    17、行为型-访问者模式:

            访问者模式就是一种分离对象数据结构与行为 (基于数据结构的操作) 的方法,通过这种分离,达到为一个被访问者动态添加新的操作而无需做其它修改的效果,使得添加作用于这些数据结构的新操作变得简单,并且不需要改变各数据结构,为不同类型的数据结构提供多种访问操作方式,这样是访问者模式的设计动机。

            除了使新增访问操作变得更加简单,也能够在不修改现有类的层次结构下,定义该类层次结构的操作,并将有关元素对象的访问行为集中到一个访问者对象中,而不是分散搞一个个的元素类中。

           但访问者模式的缺点在于让增加新的元素类变得困难,每增加一个新的元素类都意味着要在抽象访问者角色中增加一个新的抽象操作,并在每一个具体访问者类中增加相应的具体操作,违背了“开闭原则”的要求;

            所以访问者模式适用于对象结构中很少改变,但经常需要在此对象结构上定义新的操作的系统,使得算法操作的增加变得简单;或者需要对一个对象结构中进行很多不同并且不相关的操作,并且需要避免让这些操作污染这些对象,也不希望在增加新操作时修改这些类的场景。

            访问者模式的UML结构图如下:

            从上面的 UML 结构图中我们可以看出,访问者模式主要分为两个层次结构,一个是访问者层次结构,提供了抽象访问者和具体访问者,主要用于声明一些操作;一个是元素层次结构,提供了抽象元素和具体元素,主要用于声明 accept 操作;而对象结构 ObjectStructure 作为两者的桥梁,存储了不同类型的对象,以便不同的访问者来访问,相同访问者可以以不同的方式访问不同的元素,所以在访问者模式中增加新的访问者无需修改现有代码,可扩展行强。

            在访问者模式使用了双分派技术,所谓双分派技术就是在选择方法的时候,不仅仅要根据消息接收者的运行时区别,还要根据参数的运行时区别。在访问者模式中,客户端将具体状态当做参数传递给具体访问者,这里完成第一次分派,然后具体访问者作为参数的“具体状态”中的方法,同时也将自己this作为参数传递进去,这里就完成了第二次分派。双分派意味着得到的执行操作决定于请求的种类和接受者的类型。

     访问者模式详情:Java设计模式之行为型:访问者模式

    18、行为型-中介者模式:

             中介者模式通过中介者对象来封装一系列的对象交互,将对象间复杂的关系网状结构变成结构简单的以中介者为核心的星形结构,对象间一对多的关联转变为一对一的关联,简化对象间的关系,便于理解;各个对象之间的关系被解耦,每个对象不再和它关联的对象直接发生相互作用,而是通过中介者对象来与关联的对象进行通讯,使得对象可以相对独立地使用,提高了对象的可复用和系统的可扩展性。

            在中介者模式中,中介者类处于核心地位,它封装了系统中所有对象类之间的关系,除了简化对象间的关系,还可以对对象间的交互进行进一步的控制。中介者模式的UML结构图如下:

            但是,中介者对象封装了对象之间的关联关系,导致中介者对象变得比较庞大复杂,所承担的责任也比较多,维护起来也比较困难,它需要知道每个对象和他们之间的交互细节,如果它出问题,将会导致整个系统都会出问题。

    中介者模式详情:Java设计模式之行为型:中介者模式

    19、行为型-命令模式:

            命令模式的本质是将请求封装成对象,将发出命令与执行命令的责任分开,命令的发送者和接收者完全解耦,发送者只需知道如何发送命令,不需要关心命令是如何实现的,甚至是否执行成功都不需要理会。命令模式的关键在于引入了抽象命令接口,发送者针对抽象命令接口编程,只有实现了抽象命令接口的具体命令才能与接收者相关联。

            使用命令模式的优势在于降低了系统的耦合度,而且新命令可以很方便添加到系统中,也容易设计一个组合命令。但缺点在于会导致某些系统有过多的具体命令类,因为针对每一个命令都需要设计一个具体命令类。

            命令模式的UML结构图如下:

    命令模式详情: Java设计模式之行为型:命令模式

    20、行为型-状态模式:

            状态模式,就是允许对象在内部状态发生改变时改变它的行为,对象看起来就好像修改了它的类,也就是说以状态为原子来改变它的行为,而不是通过行为来改变状态。

            当对象的行为取决于它的属性时,我们称这些属性为状态,那该对象就称为状态对象。对于状态对象而言,它的行为依赖于它的状态,比如要预订房间,只有当该房间空闲时才能预订,想入住该房间也只有当你预订了该房间或者该房间为空闲时。对于这样的一个对象,当它的外部事件产生互动的时候,其内部状态就会发生变化,从而使得他的行为也随之发生变化。

            状态模式的UML结构图如下:

     从上面的UML结构图我们可以看出状态模式的优点在于:

    (1)封装了转换规则,允许状态转换逻辑与状态对象合成一体,而不是某一个巨大的条件语句块

    (2)将所有与状态有关的行为放到一个类中,可以方便地增加新的状态,只需要改变对象状态即可改变对象的行为。 

    但是状态模式的缺点在于:

    (1)需要在枚举状态之前需要确定状态种类

    (2)会导致增加系统类和对象的个数。

    (3)对 “开闭原则” 的支持并不友好,新增状态类需要修改那些负责状态转换的源代码,否则无法切换到新增状态;而且修改某个状态类的行为也需修改对应类的源代码。

    所以状态模式适用于:代码中包含大量与对象状态有关的条件语句,以及对象的行为依赖于它的状态,并且可以根据它的状态改变而改变它的相关行为。

    状态模式详情:Java设计模式之行为型:状态模式

    21、行为型-备忘录模式:

            备忘录模式提供了一种恢复状态的机制,在不破坏封装的前提下,捕获对象的某个时刻内部状态,并保存在该对象之外,保证该对象能够恢复到某个历史状态;备忘录模式将保存的细节封装在备忘录中,除了创建它的创建者之外其他对象都不能访问它,并且实现了即使要改变保存的细节也不影响客户端。但是备忘录模式都是多状态和多备份的,会早用较多的内存,消耗资源。备忘录模式的额UML结构图如下:

             备忘录模式的核心就是备忘录 Memento,在备忘录中存储的就是原发器 Originator 的部分或者所有的状态信息,而这些状态信息是不能够被其他对象所访问的,也就是说我们是不能使用备忘录之外的对象来存储这些状态信息,如果暴漏了内部状态信息就违反了封装的原则,故备忘录除了原发器外其他对象都不可以访问。所以为了实现备忘录模式的封装,我们需要对备忘录的访问做些控制:

    (1)对原发器:可以访问备忘录里的所有信息。

    (2)对负责人 caretaker:不可以访问备忘录里面的数据,但是他可以保存备忘录并且可以将备忘录传递给其他对象。

    (3)其他对象:不可访问也不可以保存,它只负责接收从负责人那里传递过来的备忘录同时恢复原发器的状态。

    备忘录模式详情:Java设计模式之行为型:备忘录模式

    22、行为型-迭代器模式:

            迭代器模式提供一种访问集合中的各个元素,而不暴露其内部表示的方法。将在元素之间游走的职责交给迭代器,而不是集合对象,从而简化集合容器的实现,让集合容器专注于在它所应该专注的事情上,更加符合单一职责原则,避免在集合容器的抽象接口层中充斥着各种不同的遍历操作。迭代器模式的UML结构图如下:

    迭代器模式详情:Java设计模式之行为型:迭代器模式

    23、行为型-解释器模式:

            解释器模式,就是定义语言的文法,并建立一个解释器来解释该语言中的句子,通过构建解释器,解决某一频繁发生的特定类型问题实例。

            解释器模式描述了如何构成一个简单的语言解释器,主要应用在使用面向对象语言开发的编译器中,它描述了如何为简单的语言定义一个文法,如何在该语言中表示一个句子,以及如何解释这些句子。    

            解释器模式中除了能够使用文法规则来定义一个语言,还能通过使用抽象语法树来更加直观表示、更好地地表示一个语言的构成,每一颗抽象语法树对应一个语言实例。抽象语法树描述了如何构成一个复杂的句子,通过对抽象语法树的分析,可以识别出语言中的终结符和非终结符类。 在解释器模式中由于每一种终结符表达式、非终结符表达式都会有一个具体的实例与之相对应,所以系统的扩展性比较好。

            解释器模式的UML如下:

     解释器模式详情:Java设计模式之行为型:解释器模式


    相关推荐阅读:

    Spring常见面试题总结

    SpringMVC常见面试题总结

    Mybatis常见面试题总结

    MySQL常见面试题总结

    Redis常见面试题总结

    RabbitMQ消息队列常见面试题总结

    ElasticSearch搜索引擎常见面试题总结

    计算机网络常见面试题总结

    操作系统常见面试题总结

    Java基础、集合、多线程常见面试题总结

    Java虚拟机常见面试题总结

    Java常见设计模式总结

    海量数据处理的方法总结


    参考文章:

    Java之美[从菜鸟到高手演变]之设计模式

    Java之美[从菜鸟到高手演变]之设计模式二

    Java之美[从菜鸟到高手演变]之设计模式三

    Java之美[从菜鸟到高手演变]之设计模式四

    展开全文
  • 网络应用模式

    千次阅读 2019-12-16 14:06:29
    网络应用模式 C/S(Client/Server):C/S结构通常采用两层结构,服务器负责数据的管理,客户机负责完成与用户的交互任务。客户机通过局域网与服务器相连,接收用户的请求,并通过网络向服务器放松请求,对数据库...

    网络应用模式

    C/S(Client/Server):C/S结构通常采用两层结构,服务器负责数据的管理,客户机负责完成与用户的交互任务。客户机通过局域网与服务器相连,接收用户的请求,并通过网络向服务器放松请求,对数据库进行操作。服务器接收到请求,将数据提交给客户机,然后客户机对数据进行计算后讲结果呈现给用户。C/S结构缺少通用性,系统维护、升级需要重新设计和开发,增加了维护和管理的难度,进一步的数据拓展困难较多,所以C/S结构只限于小型的局域网。

    B/S(Browser/Server):B/S架构采取浏览器请求,服务器响应的工作模式。用户可以通过浏览器去访问Internet上由Web服务器产生的文本、数据、图片、动画、视频点播和声音等信息;而每一个Web服务器又可以通过各种方式与数据库服务器连接,大量的数据实际存放在数据库服务器中;当用户发送请求时浏览器将请求提交给服务器,服务器对请求处理后生成HTML页面返回给浏览器,最后浏览器将页面显示给用户。给结构已经成了当今软件应用的主流结构模式.
    在这里插入图片描述

    P2P:P2P在IT最初的含义是Peer-to-Peer(点对点),之后的含义数Point to Point,现在P2P已经被广泛的理解为Pointer to Pointer,PC-to-PC等;简单的讲P2P就是数据不在通过服务器传输,而是网络用户之间直接传输数据,例如腾讯的QQ

    展开全文
  • 经典设计模式实战演练

    千次阅读 2018-07-03 02:45:11
    为了实现以上目的,前辈们从实践中总结出了一套可套用的武功招式,这就是设计模式。使用设计模式可以让你写出一手令人赏心悦目的代码。 我认为每一个后端开发者都应该学习设计模式,它是代码的精华,是程序发展的...

    课程简介

    面向对象的程序应该具有可维护性,代码可复用性,扩展性以及灵活性。为了实现以上目的,前辈们从实践中总结出了一套可套用的武功招式,这就是设计模式。使用设计模式可以让你写出一手令人赏心悦目的代码。

    我认为每一个后端开发者都应该学习设计模式,它是代码的精华,是程序发展的强力支撑,是能够让你发出惊叹的神来之笔。

    本课程共有 10 篇,结合作者的开发经验,从理论到实战,剖析设计模式经典案例,帮助读者掌握将设计模式应用于实际项目开发的能力。

    课程主要分为两大部分:

    第一部分(第01-09课),介绍常用的几种设计模式,通过具体案例的分析与代码实现带领大家深入学习与理解设计模式;

    第二部分(第10课),将结合多种设计模式手把手带领大家开发一个综合案例,提升设计模式实战的能力。

    作者介绍

    周君,资深后端工程师,CSDN 博客专家,精通 PHP、Java、Web 开发。多年实战经验,热衷分享。

    课程内容

    导读:如何学好设计模式

    0.1 什么是设计模式

    设计模式( Design Pattern )代表了最佳的实践,通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长一段时间的试验和错误总结出来的。

    上面的解释来自于网络,是比较标准的定义,可以从中筛选出几个关键字来帮助我们理解什么是设计模式:

    • 最佳实践
    • 解决方案
    • 试验和错误总结

    从上面的三个关键词中可以总结出,设计模式就是在针对编码过程中遇到的问题总结出来的最佳解决方案。

    那么这些问题指的是什么问题呢?面向对象的程序应该具有可维护性、代码可复用性、扩展性及灵活性,要解决的问题就是代码可维护性问题、复用性问题、扩展性问题及灵活性问题。

    简单来说,设计模式就是指导你如何写出可维护、可复用、可扩展及灵活的代码。

    0.2 设计模式分类

    设计模式总共有 23 种,总体来说可以分为三大类:创建型模式( Creational Patterns )、结构型模式( Structural Patterns )和行为型模式( Behavioral Patterns )。

    分类关注点包含
    创建型模式关注于对象的创建,同时隐藏创建逻辑工厂模式、抽象工厂模式、单例模式、建造者模式、原型模式
    结构型模式关注类和对象之间的组合适配器模式、过滤器模式、装饰模式、享元模式、代理模式、外观模式、组合模式、桥接模式
    行为型模式关注对象之间的通信责任链模式、命令模式、中介者模式、观察者模式、状态模式、策略模式、模板模式、空对象模式、备忘录模式、迭代器模式、解释器模式、访问者模式

    上面的三种分类说明,有助于在开发时思考当前场景应该使用哪种分类。大家不一定要全部记住,有个大概的了解即可。

    0.3 学习设计模式

    1. 为什么要学设计模式

    写出可维护、可复用、可扩展及灵活的代码是我们的目的,也是学习设计模式的理由,但是这个理由对我们来说太抽象,下面从 “ 读 ” 和 “ 写 ” 两方面来说明到底为什么要学习设计模式。

    作为开发人员,不可避免地要接触其他人写的代码,有的是一些知名的库或框架,例如 Spring 、Shiro 等。但是当我们去阅读这些框架源码的时候会发现无从下手,因为类太多了,关系太复杂,而且很多类的命名看不懂,比如 xxxBuilder 、xxxStrategy 、xxxFilter 等,一个词看不懂就可能导致你直接放弃继续阅读。

    如果没有学过设计模式,自然看不懂,学习设计模式可以有效地帮助你阅读代码,即便不能百分百帮到你,至少也能帮到百分之三四十。

    每一个开发人员必然喷过其他人写的代码,觉得其他人的代码有的写得很垃圾,尤其是要扩展功能或者修改功能的时候,恨不得全部删掉重新写,其实在其他人看来你的代码也是如此。所以写出一手让人无话可说的代码是很有必要的,不仅可以满足你的小小成就感,也可以让你的程序更快速稳定地发展。

    在一个项目组中,如果大家都学习过设计模式,那么当你阅读或修改同事写的代码时也将得心应手,少了很多麻烦。

    2. 如何学好设计模式

    如今网上和书上都有大量的设计模式教程,但是他们大部分都有一个共同点:仅仅使用生活中的例子。

    比如前几年我第一次学习设计模式,在学到适配器模式时,教程中抛出了一个电器的插头问题:

    你家插座只有三头的,但电器插头是两头的,怎么办?弄个插头适配器将两头转换成三头。

    Nice,这个例子简单明了,作为新手的我瞬间明白了适配器的含义,就是在不兼容的双方中间做一层转化。但是后来发现在实际编码中根本用不上这个设计模式,因为我不会用。

    生活中的例子的确可以帮助我们理解设计模式,这是毋庸置疑的,但是想要真正用好设计模式,实际项目中的案例是必不可少的,这也是我写这门课的原因,希望通过分析实际案例,能够帮到更多想要学习设计模式的同行。

    下面给出几点更加具体的建议:

    • 从生活例子中去理解设计模式;
    • 从实际案例去了解设计模式的使用场景;
    • 动手实践,在学完实际案例之后,不妨动手写一写,不要写生活中的例子,自己构造一个小功能,用上你的设计模式;
    • 改变自己的意识,在开发或修改一个功能时,首先要下意识地去思考这个功能将来在修改和扩展上会遇到什么问题,能否用上设计模式。记住一定要思考、一定要思考、一定要思考,即便最终用不上,也能让你回顾一遍设计模式的内容,使其知识更牢固。很多开发者不是不会用,而是根本没有想过要用设计模式,久而久之这方面的能力自然就弱化了。

    0.4 课程说明

    1. 课程内容

    本课程每一篇文章都包含三大部分:

    • 解释和理解设计模式;
    • 至少介绍一个实际案例( 实际案例有些是我自己写的,有些来自于已有的框架或库 );
    • 设计模式优缺点。

    2. 必要准备

    本课程将使用 Java 语言讲解设计模式,虽然设计模式与语言本身无关,但是本课程中有许多实际案例都是来自于知名的 Java 框架源码,如果没有 Java 基础,学习效果可能不佳。

    除了要求 Java 基础之外,还需要了解 UML 图,如果不了解 UML,只需要知道以下几种 UML 关系即可:

    • 泛化,可以简单地理解为继承关系;
    • 实现,一般是接口和实现类之间的关系;
    • 关联,一种拥有关系,比如老师类中有学生列表,那么老师类和学生类就是拥有关系;
    • 聚合,整体与部分的关系,但是整体和部分是可以分离而独立存在的,如汽车类和轮胎类;
    • 组合,整体与部分的关系,但是二者不可分离,分离了就没有意义了,例如,公司类和部门类,没有公司就没有部门;
    • 依赖,一种使用关系,例如创建 A 类必须要有 B 类。

    参考下图:

    enter image description here

    记不住也没关系,后续课程主要使用泛化和实现这两种,先记住这两种即可,如果有遇到看不懂的再回头来看一眼。

    第01课:策略模式

    1.1 课程概述

    策略模式定义了算法族,分别封装起来,让他们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。

    一般情况下我们是将一种行为写成一个类方法,比如计算器类中有加、减、乘、除四种方法,而策略模式则是将每一种算法都写成一个类,然后动态地选择使用哪一个算法。

    这里所说的算法并不是指 “ 冒泡排序算法 ” 、“ 搜索算法 ” 之类的算法,它可以是一段代码、一个请求、一个业务操作。

    策略模式如图:

    enter image description here

    从上图可以看到,我们将操作封装到类中,他们实现了同一个接口,然后在 Context 中调用。

    这里我们举一个计算器的例子:

    enter image description here

    此例中,为加法和减法分别创建了一个类。

    其实策略不一定要命名为 Strategy ,Context 不一定要叫 Context ,可以根据实际情况自己命名,在计算器的例子中,你如果非要命名为 Strategy 和 Context ,反而让人产生疑惑。

    实际代码也很简单,具体如下。

    Operation 接口:

    public interface Operation {    public int doOperation(int num1, int num2);}

    两个实现类 —— 加法和减法:

    public class OperationAdd implements Operation{    @Override    public int doOperation(int num1, int num2) {        return num1 + num2;    }}public class OperationSub implements Operation {    @Override    public int doOperation(int num1, int num2) {        return num1 - num2;    }}

    计算器类:

    public class Calculator {    private Operation operation;    public void setOperation(Operation operation){        this.operation = operation;    }    public int doOperation(int num1, int num2){        return this.operation.doOperation(num1,num2);    }}

    使用:

    Calculator calculator = new Calculator();calculator.setOperation(new OperationAdd());int result = calculator.doOperation(1,2);System.out.println(result);

    使用计算器类时,如果要进行加法运算,就 New 一个加法类传入,减法也是同理。

    看到这里,相信大家一定会有疑惑,为什么要把加、减、乘、除四则运算分别封装到类中?直接在 Calculator 中写 add() 、sub() 等方法不是更方便吗?甚至如果要添加其他的运算方法,每次都要创建一个类,反而更麻烦。

    的确,用了策略模式之后代码比普通写法多了一些,但是这里假设一种场景:把写好的计算器代码打包好作为一个库发布出去给其他人用,其他人发现你的计算器中只有加、减、乘、除四个方法,而他想增加平方、开方等功能,怎么办?

    如果是用普通写法写的计算器,想要增加功能唯一的办法就是修改你写好的 Calculator ,增加平方和开方两个 method 。

    可是你提供的是一个 jar 包啊,jar 包,jar…jar…jar…jar…包……

    就算你提供的是源码,你希望其他人可以随意修改你写好的代码吗?一般我们发布出去的开源框架或库都是经过千锤百炼、经过测试的代码,其他人随意修改我们的源码很容易产生不可预知的错误。

    如果你用的是策略模式,那么其他人想要增加平方或开平方功能,只需要自己定义一个类实现你的 Operation 接口,然后调用 calculator.setOperation(new 平方类()); 即可。

    看到这里相信你已经对策略模式有了一定的好感,甚至惊叹一声:哇,还有这种操作?

    顺便提一嘴,这里很好的体现了一个设计模式的基本原则:开闭原则。开闭原则说的是 ” 对修改关闭、对扩展开放 “ 。对修改关闭就是不希望别人修改我们的代码,此路不通,对扩展开放就是希望别人以扩展的方式增加功能,策略模式把开闭原则体现得淋漓尽致。

    1.2 实际案例

    1. 主题

    隔壁老王准备开发一个客户端框架,允许其他的开发者进行二次开发,其中有一个更换主题的功能,开发者们可以自己定义主题。老王很快就想到了策略模式,并且提供了一个默认主题 DefaultTheme :

    enter image description here

    代码:

    public interface Theme {    public void showTheme();}public class DefaultTheme implements Theme {    @Override    public void showTheme() {        //此处设置主题颜色,背景,字体等        System.out.println("显示默认主题");    }}public class ThemeManager {    private Theme theme;    public void setTheme(Theme theme){        this.theme = theme;    }    public void showTheme(){        this.theme.showTheme();    }}

    使用:

    ThemeManager themeManager = new ThemeManager();themeManager.setTheme(new DefaultTheme());themeManager.showTheme();

    看完更换主题的案例代码,你会发现跟计算器惊人地相似,没错,所谓设计模式就是前人总结出来的武功套路,经常可以直接套用。当然也要灵活地根据实际情况进行修改,设计模式想要传达给我们的更多的是一种编程思想。

    这里还有一个小窍门:

    themeManager.setTheme(new DefaultTheme());

    在这里老王 New 一个默认主题对象,如果其他开发者加了主题,还要修改这行代码,New 开发者自定义的主题对象。根据开闭原则,我们不希望其他人修改我们的任何一行代码,否则拔刀相见。老王机智地将主题的包名和类名写到了配置文件中,利用 Java 的反射机制动态生成主题对象,因此更换主题也只要修改配置文件即可。

    2. Shiro

    Shiro 是 Java 界最著名的权限控制框架之一,相信大家都不陌生。在 Shiro 中,我们可以创建多个权限验证器进行权限验证,如验证器 A、验证器 B、验证器 C,三个验证器可以同时生效。

    那么就产生了一个问题,如果验证器 A 验证通过,B 验证不通过,C 验证通过,这种情况怎么办?到底算当前用户验证通过还是不通过呢?

    Shiro 给我们提供了三种验证策略,就像老王默认提供了一种主题一样:

    • AtLeastOneSuccessfulStrategy :只要有一个验证通过,那么最终验证结果就是通过。
    • FirstSuccessfulStrategy :只有第一个成功地验证的 Realm 返回的信息将被使用,所有进一步的 Realm 将被忽略,如果没有一个验证成功,则整体尝试失败。
    • AllSucessfulStrategy :所有验证器都必须验证成功。

    如果你不熟悉 Shiro ,看不懂上面三种策略的含义,没关系,本课程讲的是设计模式,而不是 Shiro 的使用,你只要知道 Shiro 默认为我们提供了三种策略即可。

    作为开发者,在使用 Shiro 的时候,Shiro 默认的策略未必符合我们的需求,比如我们要求三个验证器中通过两个才算通过,怎么办?很简单,Shiro 这里用的也是策略模式,我们只要自定义一个 MyAuthenticationStrategy 继承 Shiro 的 AbstractAuthenticationStrategy 。咦?前面不是说实现接口吗,这里怎么是继承?变通,要懂得变通。设计模式不是一成不变的,重要的是这种编程思想。

    然后在 MyAuthenticationStrategy 实现父类要求的方法,再修改配置文件将当前验证策略改为你定义的验证策略:

    authcStrategy = 你的包名.MyAuthenticationStrategy

    1.3 课程总结

    1. 优点

    讲完上面的例子,优点已经十分明显了,那就是遵循了开闭原则,扩展性良好。

    2. 缺点

    • 随着你的策略增加,你的类也会越来越多。
    • 所有的策略类都要暴露出去,所以如果你在实际开发中使用了策略模式,一定要记得写好文档让你的伙伴们知道已有哪些策略。就像 Shiro 默认提供了三种验证策略,就必须在文档中写清楚,否则我们根本不知道如何使用。

    当然,权衡利弊,跟优点比起来,这些缺点都不算事儿。

    第02课:装饰器模式
    第03课:观察者模式
    第04课:适配器模式
    第05课:单例模式与工厂模式
    第06课:模板方法模式
    第07课:外观模式
    第08课:代理模式
    第09课:责任链模式
    第10课:设计模式综合应用

    阅读全文: http://gitbook.cn/gitchat/column/5b1e3647294fb04d7c22b783

    展开全文
  • 常用设计模式

    万次阅读 多人点赞 2020-06-29 21:41:01
    设计模式 从程序的结构上实现松耦合,从而可以扩大整体的类结构,用来解决更大的问题。 设计模式的本质是面向对象设计原则的实际运用,是对类的封装性、继承性和多态性以及类的关联和组合关系的充分理解。 正确使用...
  • Spring中所使用的设计模式

    万次阅读 多人点赞 2021-01-14 02:51:09
    Spring是一个非常优秀的开源框架,项目源码中所使用的设计模式随处可见,这篇文章主要记录一下Spring中常见设计模式: (1)工厂模式:Spring使用工厂模式,通过BeanFactory和ApplicationContext来创建对象 (2...
  • 设计模式 | 装饰者模式及典型应用

    千次阅读 2018-09-18 21:16:34
    源码分析装饰者模式的典型应用 Java I/O 中的装饰者模式 spring session 中的装饰者模式 Mybatis 缓存中的装饰者模式 总结 装饰者模式 装饰者模式(Decorator Pattern):动态地给一个对象增加一些额外...
  • 经典软件架构设计模式

    千次阅读 2022-03-17 10:18:32
    分层架构模式是最常见模式之一。分层模式背后的理念是,具有相同功能的组件将被组织成水平层。因此,每一层在应用程序中都扮演着特定的角色。 在这种模式中,我们对应用程序可以拥有的层数没有限制。在这方面,...
  • MVC设计模式

    万次阅读 多人点赞 2019-05-27 21:03:58
    MVC设计模式的引入 在我们实际开发的最后到产品上线,供给客户使用,客户通过浏览器或者app等进行数据的操作,实现这个的,处理发送请求,业务逻辑处理以及访问数据库,这三个功能我们是可以放到一块使用的,但是...
  • 几种常见设计模式(含C++代码)

    万次阅读 多人点赞 2018-07-09 13:46:30
    本文部分转载于https://blog.csdn.net/hechao3225/article/details/71366058本文介绍几种常用的设计模式并给出C++实现。1.单例模式作用:保证一个类只有一个实例,并提供一个访问它的全局访问点,使得系统中只有唯一...
  • Spring框架中常用的设计模式详解

    万次阅读 多人点赞 2019-06-16 17:12:26
    一、浅谈控制反转(IOC)与依赖注入(DI) IOC(Inversion of Control)是Spring中一个非常重要的概念,它不是什么技术,而是一种解耦的设计...它不是一个模式,而是一种设计原则,但以下模式(但不限于)实现了IOC...
  • ③通过编程实践,理解每一种创建型设计模式的概念和内涵、结构、优缺点以及应用场景。 (2)实验内容与步骤 ①使用简单工厂模式设计一个可以创建不同几何形状( Shape)(例如圆形( Circle).、矩形 Rectangle)和三角形...
  • 设计模式(Design pattern)代表了最佳的实践,通常被经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段...
  • 设计模式 考试题+答案

    万次阅读 多人点赞 2020-03-13 13:43:49
    一、选择题 1.( A )模式的关键是将一个对象定义为...2.下面的类图表示的是哪个设计模式?(B ) A装饰模式(Decorator) B策略模式(Strategy) C桥接模式(Bridge) D观察者模式(Observer) 转存失败重...
  • 如何通俗理解设计模式及其思想

    万次阅读 多人点赞 2018-07-08 20:36:52
    本文由 玉刚说写作平台 提供写作赞助 原作者:却把清梅嗅 ... 版权声明:本文版权归微信公众号 玉刚...数据结构,算法,设计模式被认为是程序员必备技能的三叉戟,如果说编程语言的语法特性和业务编码能力是【术】,...
  • 6种常用的架构设计模式(上)

    千次阅读 2020-10-19 11:10:32
    许多现代应用都需要在企业级规模上进行构建,有时甚至需要在互联网规模上进行构建。这些应用都需要满足可扩展性、可用性、安全性、可靠性和弹性需求。在本文中,我将谈论一些设计模式,这些模式可以帮...
  • 微服务架构设计模式与CAP定理

    万次阅读 热门讨论 2020-09-22 23:01:09
    微服务架构设计模式与CAP定理 前言        hello 大家好,我是一名Java后端开发的程序猿。由于国庆假期已经来了,所以我打算把这一星期的时间用来好好提升下自己的技术水平。...
  • Spring中涉及的设计模式总结

    万次阅读 多人点赞 2018-04-22 16:00:21
    Spring中涉及的设计模式总结 1.简单工厂(非23种设计模式中的一种) 实现方式:BeanFactory。 Spring中的BeanFactory就是简单工厂模式的体现,根据传入一个唯一的标识来获得Bean对象,但是否是在传入参数后创建...
  • 这个问题我问过的面试者不下于数十次,回答五花八门,在我看来,模式就是经验,设计模式就是设计经验,了这些经验,我们就能在特定情况下使用特定的设计、组合设计,这样可以大大节省我们的设计时间,提..
  • ——《设计模式》单例模式的概念很简单,下面以C#语言为例子,列出常见单例写法的优缺点。1、简单实现 public sealed class Singleton { static Singleton instance = null; public void Show()
  • Reactor设计模式

    千次阅读 2017-01-13 14:00:44
    Reactor模式是处理并发I/O比较常见的一种模式,用于同步I/O,中心思想是将所有要处理的I/O事件注册到一个中心I/O多路复用器上,同时主线程阻塞在多路复用器上;一旦I/O事件到来或是准备就绪(区别在于多路复用器是...
  • JAVA设计模式——单例模式八种方式

    千次阅读 多人点赞 2021-10-14 18:01:56
    单例设计模式的八种方式: 1、饿汉式(静态常量) 2、饿汉式(静态代码块) 3、懒汉式(线程不安全) 4、懒汉式(线程安全,同步方法) 5、懒汉式(线程安全,同步代码块) 6、双重检查(推荐使用) 7、静态...
  • 软件架构的10个常见模式

    万次阅读 多人点赞 2019-04-03 12:18:00
    企业规模的软件系统该如何设计呢?在开始写代码之前,我们需要选择一个合适的架构,这个架构将决定软件实施...架构模式类似于软件设计模式,但范围更广。本文将简要解释10种常见架构模式及其用法、优缺点。 分...
  • python中的设计模式详解

    万次阅读 2020-05-17 23:33:17
    设计模式一般是描述如何组织代码和使用最佳实践来解决常见的设计问题。需谨记一点:设计模式是高层次的方案,并不关注具体的实现细节,比如算法和数据结构。对于正在尝试解决的问题,何种算法和数据结构最优,则是由...
  • 软件工程的23种设计模式

    千次阅读 多人点赞 2019-11-22 22:07:00
    设计模式 模式 在一定环境中解决某一问题的方案,包括三个基本元素–问题,解决方案和环境。 大白话:在一定环境下,用固定套路解决问题。 设计模式(Design pattern) 是一套被反复使用、多数人知晓的、经过分类编目的...
  • 设计模式的艺术》双色版正式出版,再次感谢清华大学出版社! 一本修炼编程内功的设计模式著作,内容涵盖本博客所有精品文章! 图书目录可参考: 史上最全设计模式导学目录(完整版):...
  • Java常用设计模式的使用场景

    千次阅读 2016-12-19 21:54:20
    单例设计模式单例设计模式就是保证一个类中,且只有一个实例存在并提供一个访问点供全局访问,该实例可以被所有的程序来访问。一般在这种情况下用: 当要用一个类时,又要用该类中的一个实例; new 来创建实例时会...
  • 1.网络应用的体系结构首先要思考这样一个问题 网络应用应该采取什么样的体系结构? 凭什么非得按照它设计的来学习呢? 它好在哪里?以下三种结构(1)客户机/服务器结构(C/S)(2)点对点(p2p)(3)混合结构...
  • 设计模式与架构

    万次阅读 2019-03-29 13:13:53
    MVC、MVP、MVVM、VIPER、CDD(这些设计模式一般都是在架构里的界面层使用的) 三层架构:界面层(展示UI页面等) -> 业务层(执行一些业务操作比如:加载数据) -> 数据层(获取数据,本地数据或者是网络数据...
  • 设计模式——1、单例模式

    千次阅读 2021-02-01 15:53:55
    在有些系统中,为了节省内存资源、保证数据内容的一致性,对某些类要求只能...在计算机系统中,还有 Windows 的回收站、操作系统中的文件系统、多线程中的线程池、显卡的驱动程序对象、打印机的后台处理服务、应用

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 596,972
精华内容 238,788
关键字:

常见的网络应用设计模式有