SOLID面向对象设计原则

 

SRP	The Single Responsibility Principle	单一责任原则
OCP	The Open Closed Principle	开放封闭原则
LSP	The Liskov Substitution Principle	里氏替换原则
ISP	The Interface Segregation Principle	接口分离原则
DIP	The Dependency Inversion Principle	依赖倒置原则

 

SOLID--固体、稳定的

solid是5个原则的缩写，这样的设计具有稳定、可靠的特点。

单一职责SRP

一个类有且只有一个职责引起类改变的原因，只能有一个

//接口、方法 更容易实现此原则

任意小的改变都将导致这个单一类的变化。如果遵守 SRP，类将变得简洁和灵活。

核心是把整个问题分为小部分，并且每个小部分都将通过一个单独的类负责。

public class Tank

{//坦克类，业务逻辑和界面混合在一起

    public void Move()

    {

        //left

        //up

        //right

        //down

    }

    public void Show()

    {

        //windows show

    }

}

//新需求：linux

面对新的需求，如何复用逻辑代码？

因此，应该将职责分离，降低耦合。

 

开放封闭原则

一个类应该对扩展开放，对修改关闭。

一个类已经开始使用，就不应该再修改。因为如果改变它，很可能你的改变会引发系统的崩溃。如果需要一些额外功能，应该扩展这个类而不是修改它。

使用这种方式，现有系统不会看到任何新变化的影响。同时，只需要测试新创建的类。

public class Calculator

{     //加减计算器

    public double Calculate(double firstNumber,    double secondNumber, string operate)

    {

        double result = 0d;

        switch (operate)

        {

            case “+":

                result= firstNumber+ secondNumber;

                break;

            case “-":

                result= firstNumber- secondNumber;

                break;

        }

        return result;

    }

}

新需求：加入乘除功能

修改原来的类？影响到原有的功能怎么办？

更好的设计：

    public class Operation

    {    //抽象父类，拥有基本属性

        public double NumberA

        {

        }

       public double NumberB

        {

        }

        public virtual double GetResult()

        {

            double result = 0;

            return result;

        }

}

class OperationMul : Operation

    { //拓展的乘法子类，增加新功能时，直接增加一个类，而不是修改原来的代码

        public override double GetResult()

        {

            double result = 0;

            result = NumberA * NumberB;

            return result;

        }

    }

也就是封装变化，把频繁改动的地方抽象

 

LSP里式替换

父类出现的地方皆可以换成子类

上层模块不应关心底层模块的是如何工作的；同样的接口模块之间，可以在不知道底层模块代码的情况下，进行替换。即接口或父类出现的地方，实现接口的类或子类可以代入。

class Program

 {

        static void Main(string[] args)

        {

            Animal animal = new   Animal();//新来一只牛（猫，狗，羊），要修改整个方法吗？

            animal.Show();    //或者拓展了Animal类，上层客户端的代码都要改动吗

            animal.Eat();

            animal.Run();

        }

  }

public class Cat:Animal

{    //子类继承Animal，是对父类的拓展

}

//Animal animal = new Cat()；//使用继承&&多态，尽可能修改少的代码

正因为子类型的替换，才使得父类无须修改就可以扩展,

父类真正被服用，子类在此基础上增加新的行为

注意：父类和子类须严格遵循is-a关系

 

接口隔离原则（ISP）

类不应该被迫依赖他们不使用的方法，也就是说一个接口应该拥有尽可能少的行为，它是精简的，也是单一的。

使用多个专门的接口比使用单一的总接口要好

不应该依赖大的接口，应该裁减为小的接口给客户模块使用，以减少依赖性

public interface Animal

{

        public void eat();      // 吃

        public void sleep();    // 睡

        public void crawl();     // 爬

        public void run();      // 跑

 }

public class Bird ： Animal

{   

  public void eat()

  {

  }

  public void sleep()

  {

  }

  public void crawl ()

  {应单独抽取出接口！

  //鸟是动物，但不会爬

  }

  public void run()

  {应单独抽取出接口！

      //鸟也不会跑

  }

}

依赖注入或倒置原则（DIP）

1. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象 
2. 抽象不应该依赖于细节，细节应该依赖于抽象

public class Manager

{

        public Notify notify = new Notify（）;//老式的调用

}

public class Notify

{

        // Notify something

}

第一，当需要追加提供一种新的Notify时，对Manager层进行改动，增加了额外的工作。

第二，这种改动可能会影响到Manager ，带来风险。

第三，改动后， Manager层必须重新再做测试。

  public interface INotify

   {

        void Notify();

   }

public class Manager:INotify

{

  //do something

 public void Notify()

 {//只需要维护一个面向底层的接口，改动变小，尽可能遵守开闭原则

   //亦可以使用反射或上层传参的方式完全封闭这个类

public INotify notify = new EmailNotify（）;

 }

  //do somgthing

}

   public class EmailNotify:INotify

    {

        //EmailNotify

    }

    public class PhoneNotify:INotify

    {

        //PhoneNotify

    }

总结

一个对象只承担一种责任，所有服务接口只通过它来执行这种任务。

向扩展行为开放，向修改行为关闭。

子类应该可以用来替代它所继承的类。

一个类对另一个类的依赖应该限制在最小化的接口上。

依赖抽象层(接口、抽象类)，而不是具体类。

 

好处：

高内聚低耦合

简洁明了

可读性高

可维护性高

良好的设计、尽可能避免问题的出现

问题出现时，尽早的解决、低风险

 

通常，符合这样的设计规范的代码就是简短、灵活、易懂，也就是，好的代码！