C#中的设计原则

C#中的设计原则

1. 为什么要有设计原则

• 项目在对编写C#程序的时候，一定要对其进行规范的编程，尤其是在进行一些较为庞大或者复杂的编程的时候，理解和运用设计原则的思想就变得尤为重要，因为程序的需求是会有变化的，当需求变化而需要进行更改的时候，它就应该是一个逻辑清晰、容易看懂和修改，不容易出错和更改的地方尽可能少的代码，否则在业务逻辑足够复杂的时候，维护起来就特别的不方便，也不会引起牵一发而动全身的麻烦事。

2. 有哪些设计原则

• 单一职责原则
  这个比较简单，就是一个类，不需要它去做过多的工作，实现一些比较单一的功能，使其目的更加明确，而实现程序的高内聚，因为如果什么东西都要放到这个类里面去的话，那么就会有更多的地方会对它产生依赖，一有什么变化就需要修改这个类，这是不好的。
• 开闭原则
  开闭原则的思想就是，对扩展开放，对修改封闭，意思就是尽量去扩展程序而不要修改程序。当然了，想要完全的不修改原来的程序而添加新的功能，这是不现实的，开闭原则就要利用到抽象类。
  一个程序，我们需要保证的就是的它的核心业务逻辑区域的稳定性，我们可以使核心业务逻辑区域只有对抽象类的依赖，当需要增加需求的时候，只需要增加相应的抽象类的具体实现类，实现对程序的扩展，这样，就能够保证程序的可扩展性，并且，我们只需要在调用具体实现类的客户端使用它，也只有这个客户端才对这个具体实现类产生依赖，并不会对核心业务逻辑区域产生任何的修改。
• 依赖倒置原则
  主程序要依赖于抽象接口，不要依赖于具体实现。高层模块不应该依赖底层模块，两个都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。总的意思就是说，程序的依赖关系，应该尽量多依赖于抽象，降低程序的耦合性。
• 里氏替换原则
  子类应该能完全的继承父类的功能的时候，才应该用继承关系。这个也比较好理解，继承关系下的子类可以有自己的特色，但是一定要把父类的功能完全实现的，不然就不应该使用继承关系，而应该考虑使用依赖、组合等关系。
• 迪米特法则
  迪米特法则就是最少知道原则，一个类应该对其他类保持最少的了解。当一个类需要去了解另外一个类的时候，无论它的逻辑有多复杂，应该尽量把这个过程中所接触到的东西私有化，使用一个公共的接口来获取这个需要了解的东西，因为我只需要了解这个，我也不想管在获取这个的途中做了什么操作或者使用了哪些字段等。
  还有一个就是尽量只与朋友打交道，我要获取和朋友有关系的其他人的信息的时候，我只需要让朋友把信息提供给我，省得我还要再去问别人。这就也减少了类与类之间的耦合性。
• 接口隔离原则
  客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上，意思是，一个类，它依赖的接口的目的性应该尽量明确，不要太臃肿，太臃肿的接口会导致实现该接口的类也要实现一些不需要的功能，我们应尽量适当的划分好接口的大小，在客户端调用的时候也不必依赖大量的它用不上的功能。