zoukankan      html  css  js  c++  java
  • C#设计模式(0)-设计模式系列文章导航

    设计模式系列文章导航

        C#设计模式(1)——单例模式(SingletonPattern)

        C#设计模式(2)——简单工厂模式(SimpleFactory)

        C#设计模式(3)——工厂方法模式(FactoryMethod)

      C#设计模式(4)——抽象工厂模式(AbstractFactory)

      C#设计模式(5)——建造者模式(Builder Pattern)

      C#设计模式(6)——原型模式(Prototype Pattern)

      C#设计模式(7)——适配器模式(Adapter Pattern)

      C#设计模式(8)——桥接模式(Bridge Pattern)

      C#设计模式(9)——装饰者模式(Decorator Pattern)

      C#设计模式(10)——组合模式(Composite Pattern)

      C#设计模式(11)——外观模式(Facade Pattern)

      C#设计模式(12)——享元模式(Flyweight Pattern)

      C#设计模式(13)——代理模式(Proxy Pattern)

      C#设计模式(14)——模板方法模式(Template Method)

      C#设计模式(15)——命令模式(Command Pattern)

      C#设计模式(16)——迭代器模式(Iterator Pattern)

      C#设计模式(17)——观察者模式(Observer Pattern)

      C#设计模式(18)——中介者模式(Mediator Pattern)

      C#设计模式(19)——状态者模式(State Pattern)

      C#设计模式(20)——策略者模式(Stragety Pattern)

      C#设计模式(21)——责任链模式

      C#设计模式(22)——访问者模式(Vistor Pattern)

      C#设计模式(23)——备忘录模式(Memento Pattern)

    简介

         世界上本没有路,走的人多了也就成了路;世界上本来没有设计模式。用的人多了,也就成了设计模式。所以,我们不是严格按照它的定义去执行,可以根据自己的实际场景、需求去变通。领悟了其中的思想,实现属于自己的设计模式。通过对设计模式理解,让它它慢慢地影响你写代码的思维方式;

     我们为什么要使用设计模式?使用设计模式是为了可重用代码,让代码容易被他人理解、保证代码可靠性以及可维护性。

     最近看了一些关于设计模式的文章,以前也实际用过一些,这里希望将设计模式系列做一下总结,帮助我更深入地理解设计模式;

    设计模式分类

    创建型模式

    创建型模式就是用来创建对象的模式,抽象了实例化的过程。所有的创建型模式都有两个共同点。第一,它们都将系统使用哪些具体类的信息封装起来;第二,它们隐藏了这些类的实例是如何被创建和组织的。创建型模式包括单例模式、工厂方法模式、抽象工厂模式、建造者模式和原型模式。

    • 单例模式:解决的是实例化对象的个数的问题,比如抽象工厂中的工厂、对象池等,除了Singleton之外,其他创建型模式解决的都是 new 所带来的耦合关系。
    • 抽象工厂:创建一系列相互依赖对象,并能在运行时改变系列。
    • 工厂方法:创建单个对象,在Abstract Factory有使用到。
    • 原型模式:通过拷贝原型来创建新的对象。

      工厂方法,抽象工厂, 建造者都需要一个额外的工厂类来负责实例化“一个对象”,而Prototype则是通过原型(一个特殊的工厂类)来克隆“易变对象”。

    结构型模式

     结构型模式,顾名思义讨论的是类和对象的结构 ,主要用来处理类或对象的组合。它包括两种类型,一是类结构型模式,指的是采用继承机制来组合接口或实现;二是对象结构型模式,指的是通过组合对象的方式来实现新的功能。它包括适配器模式、桥接模式、装饰者模式、组合模式、外观模式、享元模式和代理模式。

    • 适配器模式注重转换接口,将不吻合的接口适配对接 
    • 桥接模式注重分离接口与其实现,支持多维度变化 
    • 组合模式注重统一接口,将“一对多”的关系转化为“一对一”的关系 
    • 装饰者模式注重稳定接口,在此前提下为对象扩展功能 
    • 外观模式注重简化接口,简化组件系统与外部客户程序的依赖关系 
    • 享元模式注重保留接口,在内部使用共享技术对对象存储进行优化 
    • 代理模式注重假借接口,增加间接层来实现灵活控制

    行为型模式

    行为型模式是对在不同对象之间划分责任和算法的抽象化。行为模式不仅仅关于类和对象,还关于它们之间的相互作用。行为型模式又分为类的行为模式和对象的行为模式两种。

    • 类的行为模式——使用继承关系在几个类之间分配行为。
    • 对象的行为模式——使用对象聚合的方式来分配行为。

      行为型模式包括11种模式:模板方法模式、命令模式、迭代器模式、观察者模式、中介者模式、状态模式、策略模式、责任链模式、访问者模式、解释器模式和备忘录模式。

    • 模板方法模式:封装算法结构,定义算法骨架,支持算法子步骤变化。
    • 命令模式:注重将请求封装为对象,支持请求的变化,通过将一组行为抽象为对象,实现行为请求者和行为实现者之间的解耦。
    • 迭代器模式:注重封装特定领域变化,支持集合的变化,屏蔽集合对象内部复杂结构,提供客户程序对它的透明遍历。
    • 观察者模式:注重封装对象通知,支持通信对象的变化,实现对象状态改变,通知依赖它的对象并更新。
    • 中介者模式:注重封装对象间的交互,通过封装一系列对象之间的复杂交互,使他们不需要显式相互引用,实现解耦。
    • 状态模式:注重封装与状态相关的行为,支持状态的变化,通过封装对象状态,从而在其内部状态改变时改变它的行为。
    • 策略模式:注重封装算法,支持算法的变化,通过封装一系列算法,从而可以随时独立于客户替换算法。
    • 责任链模式:注重封装对象责任,支持责任的变化,通过动态构建职责链,实现事务处理。
    • 访问者模式:注重封装对象操作变化,支持在运行时为类结构添加新的操作,在类层次结构中,在不改变各类的前提下定义作用于这些类实例的新的操作。
    • 备忘录模式:注重封装对象状态变化,支持状态保存、恢复。
    • 解释器模式:注重封装特定领域变化,支持领域问题的频繁变化,将特定领域的问题表达为某种语法规则下的句子,然后构建一个解释器来解释这样的句子,从而达到解决问题的目的。

    设计原则

      使用设计模式的根本原因是适应变化,提高代码复用率,使软件更具有可维护性和可扩展性。并且,在进行设计的时候,也需要遵循以下几个原则:单一职责原则、开放封闭原则、里氏代替原则、依赖倒置原则、接口隔离原则、合成复用原则和迪米特法则。下面就分别介绍了每种设计原则。

    单一职责原则

      就一个类而言,应该只有一个引起它变化的原因。如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会影响到其他的职责,另外,把多个职责耦合在一起,也会影响复用性。

    开闭原则(Open-Closed Principle)

      开闭原则即OCP(Open-Closed Principle缩写)原则,该原则强调的是:一个软件实体(指的类、函数、模块等)应该对扩展开放,对修改关闭。即每次发生变化时,要通过添加新的代码来增强现有类型的行为,而不是修改原有的代码。

    里氏代替原则(Liskov Substitution Principle)

      Liskov Substitution Principle,LSP(里氏代替原则)指的是子类必须替换掉它们的父类型。也就是说,在软件开发过程中,子类替换父类后,程序的行为是一样的。只有当子类替换掉父类后,此时软件的功能不受影响时,父类才能真正地被复用,而子类也可以在父类的基础上添加新的行为。

    依赖倒置原则

      依赖倒置(Dependence Inversion Principle, DIP)原则指的是抽象不应该依赖于细节,细节应该依赖于抽象,也就是提出的 “面向接口编程,而不是面向实现编程”。这样可以降低客户与具体实现的耦合。

    接口隔离原则

      接口隔离原则(Interface Segregation Principle, ISP)指的是使用多个专门的接口比使用单一的总接口要好。也就是说不要让一个单一的接口承担过多的职责,而应把每个职责分离到多个专门的接口中,进行接口分离。过于臃肿的接口是对接口的一种污染。

    合成复用原则

      合成复用原则(Composite Reuse Principle, CRP)就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分。新对象通过向这些对象的委派达到复用已用功能的目的。简单地说,就是要尽量使用合成/聚合,尽量不要使用继承。

      要使用好合成复用原则,首先需要区分"Has—A"和“Is—A”的关系。

      “Is—A”是指一个类是另一个类的“一种”,是属于的关系,而“Has—A”则不同,它表示某一个角色具有某一项责任。导致错误的使用继承而不是聚合的常见的原因是错误地把“Has—A”当成“Is—A”.

    迪米特法则

      迪米特法则(Law of Demeter,LoD)又叫最少知识原则(Least Knowledge Principle,LKP),指的是一个对象应当对其他对象有尽可能少的了解。也就是说,一个模块或对象应尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立,这样当一个模块修改时,影响的模块就会越少,扩展起来更加容易。

      关于迪米特法则其他的一些表述有:只与你直接的朋友们通信;不要跟“陌生人”说话。

      外观模式(Facade Pattern)和中介者模式(Mediator Pattern)就使用了迪米特法则。

  • 相关阅读:
    组装query,query汇总,query字段
    POJ 1276, Cash Machine
    POJ 1129, Channel Allocation
    POJ 2531, Network Saboteur
    POJ 1837, Balance
    POJ 3278, Catch That Cow
    POJ 2676, Sudoku
    POJ 3126, Prime Path
    POJ 3414, Pots
    POJ 1426, Find The Multiple
  • 原文地址:https://www.cnblogs.com/yx007/p/DesignPattern.html
Copyright © 2011-2022 走看看