面向对象五大设计原则,你学会了吗?

上一篇 / 下一篇  2022-09-29 13:14:35

  最近在看七牛云许式伟的架构课, 重温了面向对象五大设计原则(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)矩形,但是我们的重写行为破坏了父类的表达,这是一种继承的误用。
  里氏替代原则就是约束你在继承(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点不是重复的,这一点意味着细节实现是受抽象驱动,这也是“倒置”的由来, 这一点是通过接口叫ICar而不是IAutoSystem来体现。
  面相对象五大设计原则SOLID,是指导思想,不贯彻这5大设计原则也能让程序跑起来,但是可能就会出现阅读性、维护性、正确性问题。
  测试行业发展前景大猜想,究竟是坚守阵地还是灵活变通,点击下方链接填写调查问卷预测一拨吧!看看你的选择有没有影响到这个行业。

TAG: SOLID

 

评分:0

我来说两句

Open Toolbar