Talking about the seven design patterns of source code



Article link: https://my.oschina.net/u/3779583/blog/1645055

Author: Java Architecture Resource Sharing


A professional programmer always puts code clarity, compatibility, and portability in a very important position. They always enhance the clarity and readability of the code by defining a large number of macros without increasing the length of the compiled code and the running efficiency of the code.


They always code with future code maintenance and upgrades in mind. Even after analyzing 1% of the code, you will deeply understand what kind of code is written by a professional programmer and what kind of code is written by an amateur.


And this is something that anyone who hasn't really analyzed standard code can't appreciate.


This article will introduce some classic design pattern ideas:


Common Design Patterns


Proxy mode


Proxy mode: Provides a proxy for other objects to control access to this object.


You can control the method of accessing a certain class (object) in detail, and pre-processing before calling this method (the unified process code is placed in the proxy for processing). Do post-processing after calling this method.


Proxy mode classification:


1. Static proxy (statically defined proxy class, our own statically defined proxy class. For example, we define a star broker class by ourselves)


2. Dynamic proxy (the proxy class is dynamically generated by the program, the proxy class is not defined by ourselves. It is automatically generated by the program) is more important! !


  • JDK's own dynamic proxy

  • javaassist bytecode manipulation library implementation

  • CGLIB

  • ASM (underlying instructions, poor maintainability)


Structure and composition


The proxy mode mainly involves three roles: abstract roles, proxy roles, and real roles (proxied roles).


Abstract Role : Declares the common interface of the real object and the proxy object. That is, the actions that the real object and the proxy object need to achieve together (for example, the landlord and the intermediary must be able to realize the behavior of renting a house, and they can rent the house to you).


Proxy role : The proxy role contains a reference to the real role, so that the real object can be manipulated, and the proxy object provides an interface with the real object, so that it can replace the real object at any time. At the same time, when the proxy object performs the operation of the real object, it can also attach its own operation, which is equivalent to the encapsulation of the real object


真实角色:代理角色所代理的对象,亦即我们最终要引用的对象。


Factory工厂模式


工厂模式主要是为创建对象提供过渡接口,以便将创建对象的具体过程屏蔽隔离起来,达到提高灵活性的目的。


工厂模式可以分为三类:


  • 简单工厂模式(Simple Factory)

  • 工厂方法模式(Factory Method)

  • 抽象工厂模式(Abstract Factory)


这三种模式从上到下逐步抽象,并且更具一般性。GOF在《设计模式》一书中将工厂模式分为两类:工厂方法模式(Factory Method)与抽象工厂模式(Abstract Factory)。将简单工厂模式(Simple Factory)看为工厂方法模式的一种特例,两者归为一类。


区别:


工厂方法模式:


  • 一个抽象产品类,可以派生出多个具体产品类。

  • 一个抽象工厂类,可以派生出多个具体工厂类。


每个具体工厂类只能创建一个具体产品类的实例。


抽象工厂模式:


  • 多个抽象产品类,每个抽象产品类可以派生出多个具体产品类。

  • 一个抽象工厂类,可以派生出多个具体工厂类。

  • 每个具体工厂类可以创建多个具体产品类的实例。


区别:


工厂方法模式只有一个抽象产品类,而抽象工厂模式有多个。

工厂方法模式的具体工厂类只能创建一个具体产品类的实例,而抽象工厂模式可以创建多个。


Singleton 单例模式


  • 单例模式只能有一个实例。

  • 单例类必须创建自己的唯一实例。

  • 单例类必须向其他对象提供这一实例。


保证一个类仅有一个实例,并提供一个访问它的全局访问点。



单例模式结构图


单例模式(Singleton)是几个创建模式中最对立的一个,它的主要特点不是根据用户程序调用生成一个新的实例,而是控制某个类型的实例唯一性,通过上图我们知道它包含的角色只有一个,就是Singleton,它拥有一个私有构造函数,这确保用户无法通过new直接实例它。


除此之外,该模式中包含一个静态私有成员变量instance与静态公有方法Instance()。Instance()方法负责检验并实例化自己,然后存储在静态成员变量中,以确保只有一个实例被创建。


使用Singleton模式有一个必要条件:在一个系统要求一个类只有一个实例时才应当使用单例模式。反之,如果一个类可以有几个实例共存,就不要使用单例模式。


不要使用单例模式存取全局变量。这违背了单例模式的用意,最好放到对应类的静态成员中。


不要将数据库连接做成单例,因为一个系统可能会与数据库有多个连接,并且在有连接池的情况下,应当尽可能及时释放连接。Singleton模式由于使用静态成员存储类实例,所以可能会造成资源无法及时释放,带来问题。


Delegate 委派模式


委派模式(Delegate)是面向对象设计模式中常用的一种模式。这种模式的原理为类B和类A是两个互相没有任何关系的类,B具有和A一模一样的方法和属性;并且调用B中的方法,属性就是调用A中同名的方法和属性。


B好像就是一个受A授权委托的中介。第三方的代码不需要知道A的存在,也不需要和A发生直接的联系,通过B就可以直接使用A的功能,这样既能够使用到A的各种公能,又能够很好的将A保护起来了。

委派模式的优点:


  • 单一一个类无法表现复杂的设计

  • 设计拆分

  • 方便重用

  • 相对独立

  • 功能定义清晰,行为界面分离

  • 松散耦合,容易扩展


strategy 策略模式


定义一系列的算法,把每一个算法封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。也称为政策模式(Policy)。(Definea family of algorithms,encapsulate each one, andmake them interchangeable. Strategy lets the algorithmvary independently from clients that use it. )


策略模式把对象本身和运算规则区分开来,其功能非常强大,因为这个设计模式本身的核心思想就是面向对象编程的多形性的思想。



策略模式结构


当存在以下情况时使用Strategy模式


  • 许多相关的类仅仅是行为有异。 “策略”提供了一种用多个行为中的一个行为来配置一个类的方法。即一个系统需要动态地在几种算法中选择一种。

  • 需要使用一个算法的不同变体。例如,你可能会定义一些反映不同的空间 /时间权衡的算法。当这些变体实现为一个算法的类层次时 ,可以使用策略模式。

  • 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。

  • 一个类定义了多种行为 , 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。


Prototype 原型模式


原型模式的主要思想是基于现有的对象克隆一个新的对象出来,一般是有对象的内部提供克隆的方法,通过该方法返回一个对象的副本,这种创建对象的方式,相比我们之前说的几类创建型模式还是有区别的,之前的讲述的工厂模式与抽象工厂都是通过工厂封装具体的new操作的过程,返回一个新的对象,有的时候我们通过这样的创建工厂创建对象不值得,特别是以下的几个场景的时候,可能使用原型模式更简单也效率更高。


  • 当一个系统应该独立于它的产品创建、构成和表示时,要使用 Prototype模式

  • 当要实例化的类是在运行时刻指定时,例如,通过动态装载;

  • 为了避免创建一个与产品类层次平行的工厂类层次时

  • 当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。(也就是当我们在处理一些对象比较简单,并且对象之间的区别很小,可能只是很固定的几个属性不同的时候,可能我们使用原型模式更合适)。


原型模式结构


Template 模板模式


  • 模板方法模式是一种类的行为型模式,在它的结构图中只有类之间的继承关系,没有对象关联关系。

  • 板方法模式是基于继承的代码复用基本技术,模板方法模式的结构和用法也是面向对象设计的核心之一。在模板方法模式中,可以将相同的代码放在父类中,而将不同的方法实现放在不同的子类中。

  • 在模板方法模式中,我们需要准备一个抽象类,将部分逻辑以具体方法以及具体构造函数的形式实现,然后声明一些抽象方法来让子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法,从而对剩余的逻辑有不同的实现,这就是模板方法模式的用意。模板方法模式体现了面向对象的诸多重要思想,是一种使用频率较高的模式。


模板方法应用于下列情况:


  • 一次性实现一个算法的不变的部分,并将可变的行为留给子类来实现。

  • 各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。首先识别现有代码中的不同之处,并且将不同之处分离为新的操作。最后,用一个调用这些新的操作的模板方法来替换这些不同的代码。全文中源码分析可以在群619881427免费学习。感兴趣的可以加入进来。

  • 控制子类扩展。模板方法只在特定点调用“ hook”操作 ,这样就只允许在这些点进行扩展。



模板模式结构


文章链接:https://my.oschina.net/u/3779583/blog/1645055

作者:Java架构资源分享

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326838037&siteId=291194637