所谓设计原则，就是在设计时必须遵守的原则。就个人学习过程来看，主要有SOLID和DRY两大类。那么首先说下SOLID原则。
SOLID主要包括五种原则。单词中每个字母都代表一种原则。这五种原则分别是：
|
SRP |
单一责任原则 |
|
|
OCP |
开放封闭原则 |
|
|
LSP |
里氏替换原则 |
|
|
DIP |
依赖倒置原则 |
|
|
ISP |
接口分离原则 |
单一职责原则（SRP）
解析：SRP被表述为”一个类应该有且只有一个变化的原因“,单一职责意味着每个类或者方法只做一件事情，该原则也是多数开发人员最容易理解但是也是最容易违反的一个原则。在ASP.NET MVC中，一个很好的例子，就是不同的显示接口对应不同的控制器。例如，HomeController就只应包含主页有关的操作，而ProductController应该只处理产品页面的操作。
多功能与单变化
对于单功能类来说，比较容易遵循SRP。例如：将繁体中文转换为简体中文的工具类。我们来看一个手机(Phone)类的例子，Phone具有2个功能：发短信，打电话。
1 public class Phone{ 2 3 public void Message() {} 4 5 public void MakePhone() {…} 6 7 }
我们先来考察一下Phone类的变化点，并将其分为两类：
1.Phone类的内部细节变化，比如Message和MakePhone方法发生了变化；
2.Phone类整体性的变化，比如Phone类需要增加PlayMovie方法。这个Phone类具有多个变化点，不符合SRP。
进一步抽象
难道每个类都应该只有一个方法吗？当然不是。我们可以将每个方法提取到抽象中。下面代码是将方法提取到抽象中。
1 public interface IMessage 2 3 { 4 5 void MessageMethod(); 6 7 } 8 9 public class Message:IMessage 10 11 { 12 13 public void MessageMethod(){ } 14 15 } 16 17 18 19 public interface IMakePhone 20 21 { 22 23 void MakePhoneMethod(); 24 25 } 26 27 public class MakePhone:IMakePhone 28 29 { 30 31 public void MakePhoneMethod() { } 32 33 } 34 35 36 37 public class Phone 38 39 { 40 41 private IMessage message; 42 43 public void MessageMethod() 44 45 { 46 47 message.MessageMethod(); 48 49 } 50 51 private IMakePhone makePhone; 52 53 public void MakePhoneMethod() 54 55 { 56 57 makePhone.MakePhoneMethod(); 58 59 } 60 61 }
上述方法将功能点抽取到单一的接口中，将变化封装到了稳定的接口背后，这样就避免了底层的变化传导到高层。如果想更好的运用单一职责原则，就必须理解好C#编程中的抽象。
当下，正是单一职责盛行的时代，每个人都专精于某一个模块，需要多人协同合作，才能组成绚丽多彩的世界。代码写到一定程序，慢慢的我们就需要考虑一些设计原则，当然原则是以实际应用为基础的。