最近在看许式伟的架构课, 面向对象五大设计原则(SOLID)，扣理论找出处。
早期我跟着大家人云亦云， 回过头来，抠字眼找出处， 五大设计原则真的很有功力。
注意区分设计原则和设计模式。
设计原则更为抽象和泛化；
设计模式也是抽象或泛化的良好实践，但是它们提供了更具体和实用的底层建议。
单一职责原则
只能有一个让组件或类发生改变的原因；或者说每个组件或类专注于单一功能，解决特定问题。
there should never be more than one reason for a class to change. A class should be focused on a single functionality, address a specific concern.
开闭原则
对扩展开放， 对修改封闭。
扩展类的几种方式：
一般我们通过继承或者实现接口来实践开闭原则。
class Person { public int age; public string name;
public Person(string name, int age) { this.name = name; this.age = age; } public virtual void SayHallo() { Console.WriteLine("我是{0}，今年{1}", name, age); } } class Student : Person { public string major; public Student(string name, int age, string major) : base(name, age) { this.major = major; } public override void SayHallo() //子类中override重写，实现虚方法 { Console.WriteLine("我是{0}，今年{1},正在学习{2}", name, age, major); } }
class Program { static void Main(string[] args) { Person trevor1 = new Person("Trevor", 18); trevor1.SayHallo(); Student trevor2 = new Student("Trevor", 18,"C#"); trevor2.SayHallo(); } }
output：我是Trevor，今年18我是Trevor，今年18,正在学习C#
复制代码
里氏替代原则
在父子类生态中，在父类出现的地方，可以用子类对象替换父类对象，同时不改变程序的功能和正确性。
~。。~ 乍一看，这不是理所当然吗？ 为啥单独拎出来鞭尸，鞭策。
比如上例我们使用
Person trevor1 = new Student("trevor",18,"C#") // 子类对象替换父类对象 trevor1.SayHello();
复制代码
利用多态正确表达了含义。
但是某些情况下滥用继承，却不一定保证程序的正确性，会对使用者造成误解。
比如下面经典的[矩形-正方形求面积]反例：
public class Rectangle{ // 分别设置宽高 public virtual double Width {get;set;} public virtual double Height {get;set;}
public virtual void Area() { Console.WriteLine("面积是：" + Width * Height); }}
public class Square : Rectangle{ public override double Width { // get; set // 因为是正方形，想当然重设了宽=高 { base.Width= value; base.Height= value; } }
public override double Height { // get; set // 因为是正方形，想当然重设了宽=高 { base.Width = value; base.Height = value; } }
public override void Area() { Console.WriteLine("面积是：" + Width * Width); } }
public class Program{ public static void Main() { Rectangle s = new Rectangle(); s.Width = 2; s.Height = 3;
s.Area(); }}
output：面积是：6
复制代码
但是如果你[使用子类对象去替换父类对象]：
Rectangle s2 = new Square(); s2.Width = 2; s2.Height = 3; s2.Area();
output:面积是： 9
复制代码
Get 到了吗？
并不是我们想当然认为子类对象就能无损替换父类对象的， 根本原因是我们正方形虽然是(is a)矩形，但是我们的重写行为破坏了父类的表达，这是一种继承的误用。
里氏替代原则就是约束你在继承的时候注意到这个现象，并提醒你规避这个问题。
这个时候，不应该重写父类的 SetWight 方法, 而应该扩展新的方法 SetLength。
接口隔离
接口隔离，将胖接口修改为多个小接口，调用接口的代码应该比实现接口的代码更依赖于接口
why：如果一个类实现了胖接口的所有方法(部分方法在某次调用时并不需要),那么在该次调用时我们就会发现此时出现了(部分并不需要的方法)，而并没有机制告诉我们我们现在不应该使用这部分方法。
how:
避免胖接口，不要实现违反单一职责原则的接口。可以根据实际多职责划分为多接口，类实现多接口后， 在调用时以特定接口指代对象，这样这个对象只能体现特定接口的方法，以此体现接口隔离。
public interface IA { void getA(); }
interface IB { void getB(); }
public class Test : IA, IB { public string Field { get; set; } public void getA() { throw new NotImplementedException(); }
public void getB() { throw new NotImplementedException(); } } class Program { static void Main(string[] args) { Console.WriteLine("Hello World!");
IA a = new Test(); a.getA(); // 在这个调用处只能看到接口IA的方法， 接口隔离 } }
复制代码
依赖倒置原则
实现依赖于抽象， 抽象不依赖于细节。
Q：这个原则我其实一开始没能理解什么叫“倒置”？
A: 但有了一点开发经验后开始有点心得了。
痛点：面向过程的开发，上层调用下层，上层依赖于下层。当下层变动时上层也要跟着变动，导致模块复用度降低，维护成本增高。
提炼痛点： 含有高层策略的模块，如 AutoSystem 模块，依赖于它所控制的低层的负责具体细节的模块。
思路：找到一种方法使 AutoSystem 模块独立于它所控制的具体细节，那么我们就可以自由地复用 AutoSystem 了； 同时让底层汽车厂也依赖抽象，受抽象驱动，这就形成一种“倒置”。
所以依赖倒置原则有两个关键体现:① 高层次模块不应该依赖于底层实现，而都应该依赖于抽象；
这在上图： AutoSystem 和 Car 都依赖于抽象接口 ICar
② 抽象不应该依赖于具体实现，具体实现应该依赖于抽象。
第 2 点与第 1 点不是重复的，这一点意味着细节实现是受抽象驱动，这也是“倒置”的由来。
五大设计原则 SOLID，是指导思想，不贯彻这 5 大设计原则也能让程序跑起来，但是可能就会出现可阅读性、维护性、正确性问题。
![深入解读[面向对象五大设计原则]_黄俊_InfoQ写作社区](https://static001.infoq.cn/static/infoq/img/logo-121-75.yuij86g.png){kind=logo}
评论