C#七种设计原则

在C#中有七种设计原则 分别是

1.开闭原则(Open-Closed Principle, OCP)

2.单一职责原则（Single Responsibility Principle）

3.里氏替换原则（Liskov Substitution Principle）

4.迪米特法则（Law Of Demeter）

5.依赖倒置原则（Dependence Inversion Principle）

6.接口隔离原则（Interface Segregation Principle）

7.合成/聚合原则(Composite/Aggregate Reuse Principle,CARP)

就一一介绍着七种设计原则

1.开闭原则(Open-Closed Principle, OCP)

定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

我的解释：软件实体如同你租住的房子通常 你能够向里面添加东西 可是却很难修改这个房间

扩展开放就至关于你向租住的房子里放置家具 充实这个房子的功能

修改关闭就比如是房子的已经存在的物件 道理上你是没有这个改变他们的能力 实际是你在付出代价以后能够更改

但绝对的修改关闭是不可能的 就比如如水龙头 下水管道 灯泡等这些房子存在的基本物件损坏同样 不可避免的

因此须要提早作好准备避免而在软件中避免就是建立抽象来隔离之后发生同类的变化。

 

开放-封闭原则，能够保证之前代码的正确性，由于没有修改之前代码，因此能够保证开发人员专一于将设计放在新扩展的代码上。

简单的用一句经典的话来讲：过去的事已成历史，是不可修改的，由于时光不可倒流，但如今或明天计划作什么，是能够本身决定(即扩展)的。

 

2.单一职责原则（Single Responsibility Principle）

定义：即一个类只负责一项职责，应该仅有一个引发它变化的缘由

我的解释：你有一个带茶漏的茶杯(即类)用来喝茶和喝水(即两种职责) 有一天你想将奶茶倒入这个茶杯

但因为奶茶有珍珠 茶杯有茶漏 为了将珍珠也放入茶杯中 你将茶漏取出(改变了茶杯的功能)此时的茶杯就

不能用来喝茶 因此该茶杯的职责也就被改变 为了不这种改变你准备了茶杯和水杯 喝茶就用茶杯 喝水就用水杯

这就符合单一职责 一个类(杯子)只负责一种职责(喝茶或者喝水)

单一职责的优势：
1.能够下降类的复杂度，一个类只负责一项职责，其逻辑确定要比负责多项职责简单的多；
2.提升类的可读性，提升系统的可维护性；
3.变动引发的风险下降，变动是必然的，若是单一职责原则遵照的好，当修改一个功能时，能够显著下降对其余功能的影响。
须要说明的一点是单一职责原则不仅是面向对象编程思想所特有的，只要是模块化的程序设计，都须要遵循这一重要原则。

 

3.里氏替换原则（Liskov Substitution Principle）

定义：子类型必须可以替换掉它们的父类型

我的解释：若是父类型是鸟 子类型是企鹅 在生物学中企鹅归属于鸟 可是企鹅不会飞 在编程的世界中 企鹅就没法归属于鸟

即企鹅不能继承鸟类  

 

 只有当子类能够替换掉父类，软件单位的功能不受影响时，父类才能真正被复用，而子类也能够在父类的基础上增长新的行为，

正是有里氏代换原则，使得继承复用成为了可能。正是因为子类型的可替换性才使得使用父类类型的模块在无需修改的

状况下就能够扩展，否则还谈什么扩展开放，修改关闭呢

里氏替换原则通俗的来说就是：子类能够扩展父类的功能，但不能改变父类原有的功能。

它包含如下4层含义：
1.子类能够实现父类的抽象方法，但不能覆盖父类的非抽象方法。
2.子类中能够增长本身特有的方法。
3.当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
4.当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

 

4.迪米特法则（Law Of Demeter）

定义：迪米特法则又叫最少知道原则，即一个对象应该对其余对象保持最少的了解。

解释：迪米特法则其根本思想，是强调了类之间的松耦合，类之间的耦合越弱,越有利于复用，一个处在弱耦合的类被

修改，不会对有关系的类形成影响，也就是说信息的隐藏促进了软件的复用。

软件编程的总的原则：低耦合，高内聚。不管是面向过程编程仍是面向对象编程，只有使各个模块之间的耦合尽可能的低，

才能提升代码的复用率。而迪米特法则就是解决低耦合的方法

我的解释：迪米特法则有个简单的方法叫作：只与直接的朋友通讯。朋友关系在编程中就是耦合关系，耦合的方式就像现实

世界中交朋友同样有多种，例如：依赖，关联，组合，聚合等。其中，咱们称出现成员变量、方法参数、方法返回值中的类为直接的朋友

而出如今局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要做为局部变量的形式出如今类的内部。

 

5.依赖倒置原则（Dependence Inversion Principle）

定义：高层模块不该该依赖低层模块，两者都应该依赖其抽象；抽象不该该依赖细节；细节应该依赖抽象。中心思想是面向接口编程

在实际编程中，咱们通常须要作到以下3点：

1. 低层模块尽可能都要有抽象类或接口，或者二者都有。

2. 变量的声明类型尽可能是抽象类或接口。

3. 使用继承时遵循里氏替换原则。

依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来

的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好

规范和契约，而不去涉及任何具体的操做，把展示细节的任务交给他们的实现类去完成。

 

6.接口隔离原则（Interface Segregation Principle）

定义：咱们要为各个类创建专用的接口，而不要试图去创建一个很庞大的接口供全部依赖它的类去调用

解释：在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更灵活。就比如术业有专攻同样。

经过分散定义多个接口，能够预防外来变动的扩散，提升系统的灵活性和可维护性。

采用接口隔离原则对接口进行约束时，要注意如下几点：
1. 接口尽可能小，可是要有限度。对接口进行细化能够提升程序设计灵活性是不挣的事实，可是若是太小，则会形成接口数量过多，使设计复杂化。因此必定要适度。
2. 为依赖接口的类定制服务，只暴露给调用的类它须要的方法，它不须要的方法则隐藏起来。只有专一地为一个模块提供定制服务，才能创建最小的依赖关系。
3. 提升内聚，减小对外交互。使接口用最少的方法去完成最多的事情。

 运用接口隔离原则，必定要适度，接口设计的过大或太小都很差。设计接口的时候，只有多花些时间去思考和筹划，才能准确地实践这一原则。

 

7.合成/聚合原则(Composite/Aggregate Reuse Principle,CARP)

定义：尽可能的使用合成和聚合，而不是继承关系达到复用的目的换句话说，就是能用合成/聚合的地方，毫不用继承。

 

为何要尽可能使用合成/聚合而不使用类继承？

1. 对象的继承关系在编译时就定义好了，因此没法在运行时改变从父类继承的子类的实现

2. 子类的实现和它的父类有很是紧密的依赖关系，以致于父类实现中的任何变化必然会致使子类发生变化

3. 当你复用子类的时候，若是继承下来的实现不适合解决新的问题，则父类必须重写或者被其它更适合的类所替换，这种依赖关系限制了灵活性，并最终限制了复用性。

 

以上就是我对七大设计原则的总结，在之后的生活中若是碰见更好的解释会增添。