面向对象五大设计原则

news/2024/7/3 13:21:23 标签: 多态, 设计模式, java, 接口, 编程语言

最近在看七牛云许式伟的架构课, 重温了面向对象五大设计原则(SOLID),扣理论文字找出处。(当然许老板是不可能深聊这么低级的内容,🤡)

注意区分设计原则和设计模式
设计原则更为抽象和泛化;
设计模式也是抽象或泛化的良好实践,但是它们提供了更具体和实用的底层建议。

面向对象5大设计原则
Single Responsiblity Principle单一职责原则
Open/Closed Principle开闭原则
Likov Substitution Principle里斯替代原则
Interface Segregation Principle接口隔离原则
Dependency inversion依赖倒置原则

单一职责原则

只能有一个让组件或类发生改变的原因;或者说每个组件或类专注于单一功能,解决特定问题。

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: 但有了一点开发经验后开始有点心得了。

痛点:面向过程的开发,上层调用下层,上层依赖于下层。当下层变动时上层也要跟着变动,导致模块复用度降低,维护成本增高。

8bce678e835e5fef9c4715575b11c837.png

提炼痛点:含有高层策略的模块,如AutoSystem模块,依赖于它所控制的低层的负责具体细节的模块。

思路:找到一种方法使AutoSystem模块独立于它所控制的具体细节,那么我们就可以自由地复用AutoSystem了;同时让底层汽车厂也依赖抽象,受抽象驱动,这就形成一种“倒置”。

f14e64b16e0b206cc4a0f0436a1a63c7.png

所以依赖倒置原则有两个关键体现:

①  高层次模块不应该依赖于低层实现,而都应该依赖于抽象;

这在上图:AutoSystem和Car都依赖于抽象接口ICar

②  抽象不应该依赖于具体实现,具体实现应该依赖于抽象。

第2点与第1点不是重复的,这一点意味着细节实现是受抽象驱动,这也是“倒置”的由来, 这一点是通过接口叫ICar而不是IAutoSystem来体现。

面相对象五大设计原则SOLID,是指导思想,不贯彻这5大设计原则也能让程序跑起来,但是可能就会出现阅读性、维护性、正确性问题。

本人会不时修正理解、更正错误,请适时移步左下角永久更新地址;也请看客大胆斧正。


http://www.niftyadmin.cn/n/1864413.html

相关文章

两将军问题和TCP三次握手

两将军问题,又被称为两将军悖论、两军问题, 是一个经典的计算机思想实验。 首先, 为避免混淆,我们需要认识到两将军问题虽然与拜占庭将军问题相关,但两者不是一个东西。拜占庭将军问题是一个更通用的两将军问题版本&am…

Go语言正/反向代理的姿势

先重温一下什么叫反向代理,正向代理。鹅厂二面,nginx回忆录[1]所谓正向,反向代理取决于代理的是出站请求,还是入站请求。正向代理:代理的出站请求, 客户端能感知到代理程序,架构上距离客户端更近…

你认识的C# foreach语法糖,真的是全部吗?

本文的知识点其实由golang知名的for循环陷阱发散而来, 对应到我的主力语言C#, 其实牵涉到闭包、foreach。为了便于理解,我重新组织了语言,以倒叙结构行文。 先给大家提炼出一个C#题:观察for、foreach闭包的差异 左边输…

项目管理概述

项目管理 项目是为创造独特的产品、服务或成果而进行的临时性工作。 临时性:指的是有开始、结束时间,而不是指时间很短 独特性:项目中某些可交付成果或者活动中的某些元素是重复的,但项目仍然具有独特性 项目管理让项目目标落地&…

项目运行环境

项目运行环境 影响项目的两大因素 事业环境因素 客观存在,对项目可能有帮助,也可能有阻碍,项目经理只能去应对,而不能回避 所有公司外部的环境,包括法律法规、市场环境、政府行业标准等公司内组织文化、员工能力、基础…

组织体系

组织体系 ​ 单个组织内多种因素交织影响创造出的一个独特系统,会对在该系统内运行的项目造成影响,其因素包括: 管理要素治理框架组织结构类型 运行项目的过程中需要应对治理框架和组织结构带来的制约 项目管理办公室(PMO&#…

项目经理角色

项目经理角色 项目经理的作用 对团队成果负责,需要从整体角度看待团队产品,以便进行规划、协调、完成 项目经理和职能经理 项目经理:由执行组织委派,领导团队实现项目目标的个人。通常项目经理会花大量时间进行沟通协调&#xf…

空跑任务,满足CPU使用率合规要求

语言:golang 适用系统:linux 用途:空跑任务,满足CPU使用率合规要求 使用方法:go run cpulimit.go 0.35 // 百分之35%使用率 package mainimport ("fmt""io/ioutil"// "math""os&q…