63 lines
6.6 KiB
C#
63 lines
6.6 KiB
C#
using System.Collections.Generic;
|
|
using System.Diagnostics.Metrics;
|
|
|
|
namespace 必备知识点_面向对象七大原则
|
|
{
|
|
internal class Program
|
|
{
|
|
static void Main(string[] args)
|
|
{
|
|
//1，开闭原则
|
|
//对扩展开放-------模块的行为可以被扩展从而满足新的需求。
|
|
//对修改关闭------ - 不允许修改模块的源代码（或者尽量使修改最小化）
|
|
//开闭原则是说我们应该努力设计不需要修改的模块。在实际应用将变化的代码和不需要变化的代码进行隔离，将变化的代码抽象成稳定接口，针对接口进行编程。
|
|
//在扩展系统的行为时，我们只需要添加新的代码，而不需要修改已有的代码。一般可以通过添加新的子类和重写父类的方法来实现。
|
|
//开闭原则是面向对象设计的核心，满足该原则可以达到最大限度的复用性和可维护性。
|
|
|
|
//2，单一原则
|
|
//单一原则表明，如果你有多个原因去改变一个类，那么应该把这些引起变化的原因分离开，把这个类分成多个类，每个类只负责处理一种改变。当你做出某种改变时，
|
|
//只需要修改负责处理该改变的类。当我们去改变一个具有多个职责的类时可能会影响该类的其他功能
|
|
//单一职责原则代表了设计应用程序时一种很好的识别类的方式，并且它提醒你思考一个类的所有演化方式。只有对应用程序的工作方式有了很好的理解，才能很好的分离职责。
|
|
|
|
//3，接口隔离原则
|
|
//接口隔离原则表明客户端不应该被强迫实现一些他们不会使用的接口，应该把肥胖接口中的方法分组，然后用多个接口代替它，每个接口服务于一个子模块。
|
|
//如果已经设计成了胖接口，可以使用适配器模式隔离它。像其他设计原则一样，接口隔离原则需要额外的时间和努力，并且会增加代码的复杂性，但是可以产生更灵活的设计。
|
|
//如果我们过度的使用它将会产生大量的包含单一方法的接口，所以需要根据经验并且识别出那些将来需要扩展的代码来使用它。
|
|
|
|
//4，里氏替换原则
|
|
//里氏替换原则是对开闭原则的扩展，它表明我们在创建基类的新的子类时，不应该改变基类的行为。
|
|
//当我们设计程序模块时，我们会创建一些类层次结构，然后我们通过扩展一些类来创建它们的子类。我们必须确保子类只是扩展而没有替换父类的功能，
|
|
//否则当我们在已有程序模块中使用它们时将会产生不可预料的结果。里氏代换原则表明当一个程序模块使用基类时，基类的引用可以被子类替换而不影响模块的功能。
|
|
|
|
//5，依赖倒转原则
|
|
//上层模块不应该依赖于底层模块，它们都应该依赖于抽象。
|
|
//抽象不应该依赖于细节，细节应该依赖于抽象。
|
|
//应用该原则意味着上层类不直接使用底层类，他们使用接口作为抽象层。这种情况下上层类中创建底层类的对象的代码不能直接使用new 操作符。可以使用一些创建型设计模式，
|
|
//例如工厂方法，抽象工厂和原型模式。模版设计模式是应用依赖倒转原则的一个例子。当然，使用该模式需要额外的努力和更复杂的代码，不过可以带来更灵活的设计。
|
|
//不应该随意使用该原则，如果我们有一个类的功能很有可能在将来不会改变，那么我们就不需要使用该原则。
|
|
|
|
//6，迪米特法则
|
|
//迪米特法则（Law of Demeter）又叫最少知识原（Least Knowledge Principle LKP），就是说一个对象应当对其他对象有尽可能少的了解。
|
|
//迪米特法则的目的在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块相互独立，相互之间不存在依赖关系。
|
|
//应用迪米特法则有可能造成的一个后果就是，系统中存在的大量的中介类，这些类只所以存在完全是为了传递类之间的相互调用关系—这在一定程度上增加系统的复杂度。
|
|
//设计模式中的门面模式（Facade）和中介模式（Mediator）都是迪米特法则的应用的例子。
|
|
//狭义的迪米特法则的缺点：
|
|
//在系统里面造出大量的小方法，这些方法仅仅是传递间接的调用，与系统的商业逻辑无关。
|
|
//遵循类之间的迪米特法则会使一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有之间的关联。但是，这也会造成系统的不同模块之间的通信效率降低
|
|
//，也会使系统的不同模块之间不容易协调。
|
|
//广义的迪米特法则在类的设计上的体现：
|
|
//优先考虑将一个类设置成不变类。
|
|
//尽量降低一个类的访问权限。
|
|
//尽量降低成员的访问权限。
|
|
|
|
//7，组合 / 聚合复用原则
|
|
//聚合表示整体与部分的关系，表示“含有”，整体由部分组合而成，部分可以脱离整体作为一个独立的个体存在。组合则是一种更强的聚合，部分组成整体，而且不可分割，
|
|
//部分不能脱离整体而单独存在。在合成关系中，部分和整体的生命周期一样，组合的新的对象完全支配其组成部分，包括他们的创建和销毁。
|
|
//组合 / 聚合和继承是实现复用的两个基本途径。合成复用原则是指尽量使用组合 / 聚合，而不是使用继承。只有当以下的条件全部被满足时，才应当使用继承关系：
|
|
//子类是超类的一个特殊种类，而不是超类的一个角色，也就是区分“Has - A”和“Is - A”.只有“Is - A”关系才符合继承关系，“Has - A”关系应当使用聚合来描述。
|
|
//永远不会出现需要将子类换成另外一个类的子类的情况。如果不能肯定将来是否会变成另外一个子类的话，就不要使用继承。
|
|
//子类具有扩展超类的责任，而不是具有置换掉或注销掉超类的责任。如果一个子类需要大量的置换掉超类的行为，那么这个类就不应该是这个超类的子类。
|
|
}
|
|
}
|
|
}
|