# 面向对象遵循的原则: SOLID # S(Single Responsibility Principle) # 单一职责原则 # 一个类只负责一项职责 # 好处 # 易于维护, 写出高内聚的代码 # 易于代码复用 # 案例 # 我们之前写的计算器类 # 假设只包含加减乘除运算和结果打印 # 如果往后需要增加, 结果写入文件, 结果参与其他运算, 结果上传服务器... # 是不是每一次都需要去修改此类? 就导致这个类变得特别臃肿; 不利于维护和部分代码复用 # 解决方案 # 计算器只包含, 加减乘除运算以及结果返回 # 根据不同情况, 将对结果的处理分散到其它合适的类别中 # O(Open Closed Principle) # 开放封闭原则 # 对扩展开放 # 对修改关闭 # 易于维护, 保证代码安全性以及扩展性 # 案例 # 我们之前写的, 在Person类中, 写的, 让小狗小猫工作的方法 # 假设小狗小猫的工作方法名分别是watch和catch; # 那Person类中让宠物工作的方法就需要通过if进行多分支判定 # 如果以后, 扩展了新的宠物类; 那么, Person类中的让宠物工作的方法, 必须要跟着修改 # 解决方案 # 通过基类, 以及抽象类等方案进行方法的统一 # O(Open Closed Principle) # 开放封闭原则 # 对扩展开放 # 对修改关闭 # 易于维护, 保证代码安全性以及扩展性 # 案例 # 我们之前写的, 在Person类中, 写的, 让小狗小猫工作的方法 # 假设小狗小猫的工作方法名分别是watch和catch; # 那Person类中让宠物工作的方法就需要通过if进行多分支判定 # 如果以后, 扩展了新的宠物类; 那么, Person类中的让宠物工作的方法, 必须要跟着修改 # 解决方案 # 通过基类, 以及抽象类等方案进行方法的统一 # L(Liskov Substitution Principle) L(Liskov Substitution Principle) # I(Interface Segregation Principle) # 接口分离原则 # 如果一个类包含了过多的接口方法，而这些方法在使用的过程中并非"不可分割", 那么应当把他们进行分离 # 所谓接口, 在Python中, 可以简单的理解为"抽象方法" # 好处 # 提高接口的重用价值 # 案例 # 小鸟 # 吃, 叫, 飞 # 上述接口设计在有鸵鸟类的前提下, 设计就不合理 # D(Dependency Inversion Principle) # 依赖倒置原则 # 高层模块不应该直接依赖低层模块 # 他们应该依赖抽象类或者接口 # 好处 # 利于代码维护 # 案例 # 电脑类, 依赖的不是某一个具体鼠标类 # 而应该是, 鼠标类的抽象 # 能单击, 能双击, 能右击, 能移动鼠标指针... # 到时, 可以是触摸板, 也可以是有线鼠标, 也可以是蓝牙鼠标...