CSharpDesignPatterns

KO | EN

gitlite — search

#python #react #android #machine-learning #rust #deep-learning #linux #docker #macos #nodejs #windows #awesome #awesome-list #open-source

CSharpDesignPatterns

(★ 9)

23种设计模式案例实现

CSharpDesignPatterns 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# CSharpDesignPatterns
23种设计模式案例实现

**案例开发环境：**
Win10  64位系统
.NetCore 2.2

------------

**一、参考资料**

参考地址：
https://www.cnblogs.com/abcdwxc/archive/2007/09/20/900264.html
https://www.cnblogs.com/abcdwxc/archive/2007/10/30/942834.html

------------

**二、 设计原则**

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

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

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

符合开闭原则的最好方式是提供一个固有的接口，然后让所有可能发生变化的类实现该接口，让固定的接口与相关对象进行交互。

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

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

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

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

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

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

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

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

------------

**三、 设计模式**
1. **创建型(Creational Patterns)，这里的使用频率仅供参考**

1.1 抽象工厂(Abstract Factory): 提供一个创建一些列相关或相互依赖的对象的接口，而无需指定他们具体的类。
	使用频率：☆☆☆☆☆

1.2 工厂方法(FactoryMethod)：定义一个用于创建对象的接口，让子类决定实例哪一个类。Factory Method是一个类的实例化延迟到其子类。
	使用频率：☆☆☆☆☆

1.3 单例(Singleton)：保证一个类仅有一个实例，并提供一个访问他的全局访问点。
	使用频率：☆☆☆☆☆

1.4 原型(Prototype):用原型实例指定创建对象的种类，冰洁通过拷贝这些原型创建新的对象
	使用频率：☆☆☆

1.5 建造者(Builder): 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
	使用频率：☆☆☆

2. **结构型(Structural Patterns)**

2.1 外观(Facade): 为子系统中一组接口提供一个一直的接口，定义了一个高层接口，使得子系统更加容易使用。
	使用频率：☆☆☆☆☆

2.2 适配器(Adapter): 将一个类的接口转换成客户希望的另一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
	使用频率：☆☆☆☆

2.3 组合(Composite): 将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。
	使用频率：☆☆☆☆

2.4 代理(Proxy): 为其他对象提供一种代理以控制对这个对象的访问。
	使用频率：☆☆☆☆

2.5 桥接(Bridge): 将抽象部分与它的实现部分分离，是他们都可以独立变化。
	使用频率：☆☆☆

2.6 装饰着模式(Decorator): 动态地给一个对象添加一些额外的职责。
	使用频率：☆☆☆

2.7 享元(Flyweight): 使用共享来有效地支持大量细粒度对象。
	使用频率：☆
	
3. **行为型(Behavioral patterns)**

3.1 观察者(Observer): 定义对象间的一种一对多的依赖关系，当一个对象的状态发生变化时，所有依赖于它的对象都得到通知并自动更新。
	使用频率：☆☆☆☆☆

3.2 迭代器(Iterator): 提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。
	使用频率：☆☆☆☆☆

3.3 策略(Strategy): 定义一系列的算法，把他们一个个封装起来，并且将他们可互相转换。使得算法可独立于使用它的客户而变化。
	使用频率：☆☆☆☆

3.4 命令(Command): 将一个请求封装为一个对象，从使你可用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销的操作。
	使用频率：☆☆☆☆

3.5 模板方法(Template Method)：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。使得子类可以不改一个算法的结构即可重定义该算法的某些特定步骤。
	使用频率：☆☆☆☆

3.6 状态(State): 允许一个对象在器内部状态改变时改变他的行为。对象开起来似乎修改了它的类。
	使用频率：☆☆☆

3.7 中介者(Mediator): 用一个中介对象来封装一系列的对象交互。使得各个对象不需要显示地相互引用，从而使其耦合松散，而且可以独立改变他们之间的交互。
	使用频率：☆☆

3.8 责任链(Chain of Responsibility): 使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理为止。
	使用频率：☆☆

3.9 访问者(Visitor): 表示要在对象结构的元素上执行操作。允许你定义一个新的操作，而不需要更改他所操作的元素的类。
	使用频率：☆

3.10 解释器(Interpreter): 给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
	使用频率：☆

3.11 备忘录(Memento): 在不破坏封装性的前提下，捕获一个对象内部状态，并在改对象之外保存这个状态。这样以后就可将改对象恢复到原先保存的状态。
	使用频率：☆

CSharpDesignPatterns

CSharpDesignPatterns 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

CSharpDesignPatterns

CSharpDesignPatterns 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README