在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. 当你复用子类的时候，如果继承下来的实现不适合解决新的问题，则父类必须重写或者被其它更适合的类所替换，这种依赖关系限制了灵活性，并最终限制了复用性。
以上就是我对七大设计原则的总结，在以后的生活中如果遇见更好的解释会增添。