|
回复“000”获取大量电子书 写在前面我们继续学习架构师技能，今天是本系列的第二篇，希望大家持续关注。 可能你不是科班出生，甚至大学都没念，没背景没关系。我们只要每天进步一点点，一个月、两个月、半年、一年......。 规划性的学习一年半载后，你会觉得开始的你是多么的无知，如若不信，你可试试看！ 只要你肯努力，迟早弯道超车！ 坐稳了，开始发车 网上都流行那么个段子：搞死一个程序员，不用动刀或枪，只需要修改几次需求。 开玩笑，确定吗？ 我也是程序员，也和相关人员互怼过，不过都只是动口不动手。确实，很多时候，相关人员提的需求确实有点过分，因为要考虑到工期以及现有资源，有句话叫做“你给我做够资源和时间，我可以给你造飞机火箭！”。 话又说回来，看这篇文章的相信都是程序员，咱们都是一路人。但，我想说其实很多时候，我们也存在问题。 比如：系统设计的可扩展性、可维护性等，大家是否真的有认真想过，甚至部分人连软件设计的七大原则都还搞不清楚。 不过，很多人也是想好好设计的，但是无赖，给你工期不够，否则，你需要加班，甚至加班估计够呛，从而也就导致系统逐渐变的非常难以维护，臃肿，同样的功能有n套代码，到最后就是推翻了出个新版本（长痛不如短痛）。 但，牛逼的人，只要工期不是很离谱，他们写代码永远是看起来非常舒服、还给你预留了很多扩展口子、封装了很多公用的工具类、抽象出了很多模型等等。 综上，个人建议同行朋友，尤其是三年左右的，这时候，知识的广度，深度都要有所涉及，同时，系统设计或者某个模块的设计也是体现你的能力的点（领导交给你的某个模块，其实也可以理解为一个系统，所以还是要认真对待，大项目也是有多个模块组成的）。希望大家一定多体会&&领会软件设计的七大原则。 牛人们的总结Robert C.Martin一个可维护性（Maintainability）较低的软件设计，通常由于以下4个原因造成 1、过于僵化(Rigidity)：设计难以修改 2、过于脆弱(Fragility)：设计易遭到破坏（需要修改的时候，容易牵一发而动全身，不该受到影响的代码也被迫的破坏掉） 3、牢固性(Immobility)：复用率低（当想使用一些功能时会发现里面的某些代码不是他想要的，想把这些代码去掉时，发现没办法去掉，原因是代码耦合度太高了） 4、粘度过高(Viscosity)：难以做正确事情（维护的过程中想进行修改某些代码，但是发现没有办法进行修改，原因就是粘度太高） PeterCoad一个好的系统设计应该具备如下三个特性：
面向对象设计原则和设计模式也是对系统进行合理重构，重构是在不改变软件现有功能的基础上，通过调整代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理性，提高软件的扩展性和维护性。 软件设计七大原则
关于这个七大设计原则，相信大部分人也听说过，甚至很多朋友都学习过，但是始终没有掌握，希望通过本文的分享，不敢说你一定能掌握，但是至少掌握部分。 本文主要内容就是软件设计的七大原则，重点在于用代码来演示。
开闭原则开闭原则（Open Closed Principle，OCP）由勃兰特·梅耶提出，他在 1988 年的著作《面向对象软件构造》中提出：
这就是开闭原则的经典定义。 在现实生活中，开闭原则也有体现。比如，很多互联网公司都实行弹性制作息时间，规定每天工作8小时。意思就是，对于每天工作8小时这个规定是关闭的，但是什么时候来、什么时候走是开放的。早来早走，晚来晚走。 作用开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。具体来说，其作用如下。
实际案例报名一个网上课程，课程有价格、id、名称。 //课程接口类运行OpenCloseDemo的main方法，结果： 课程ID=1现在要给Java架构课程做活动，价格优惠，比如双11、618等节日搞促销活动。如果修改JavaCourse中的getPrice()方法，则会存在一定风险，可能影响其他地方的调用结果。 如何在不修改原有代码的前提下，实现价格优惠这个功能呢？我们再写一个处理优惠逻辑的类——JavaDiscountCourse类（可以思考一下为什么要叫JavaDiscountCourse，而不叫DiscountCourse）。 于是我们就这么干，增加一个java课程的打折类。 public class JavaDiscountCourse extends JavaCourse {运行结果： 课程ID=1这样的话，我们就没必要动JavaCourse这个类了，其他地方可能还在使用这个JavaCourse中的价格。 整个类图： 依赖倒置原则定义依赖倒置原则（Dependence Inversion Principle，DIP）指设计代码结构时，高层模块不应该依赖底层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。通过依赖倒置，可以降低类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并降低修改程序带来的风险。 案例我们来看一个案例，还是以课程为例，首先创建一个类Tian。 public class Tian {然后编写客户端测试代码并调用。 public static void main(String[] args) {随着学习兴趣的暴涨，老田还想学习AI课程。 这个时候，需要业务扩展，代码要从底层到高层（调用层）一次修改代码。在Tian类中增加studyAICourse()的方法，在高层也要追加调用。如此一来，在系统发布以后，实际上是非常不稳定的，在修改代码的同时会带来意想不到的风险。因此我们优化代码，首先创建一个课程的抽象接口ICourse。 public interface ICourse {然后写JavaCourse类。 public class JavaCourse implements ICourse {再实现PythonCourse类。 public class PythonCourse implements ICourse {最后修改Tian类。 public class Tian {来看客户端测试代码。 public static void main(String[] args) {这时候再看代码，老田的兴趣无论怎么暴涨，对于新的课程，只需要新建一个类，通过传参的方式告诉Tian，而不需要修改底层代码。实际上，这是一种大家非常熟悉的方式，叫作依赖注入。
下面来看构造器注入方式。 public class Tian {来看客户端代码，将JavaCourse对象作为Tian对象的构造参数注入。 public static void main(String[] args) {根据构造器注入方式，当调用时，每次都要创建实例。 但，如果Tian是全局单例，则只能选择Setter注入方式，继续修改Tian类的代码。 public class Tian {来看客户端代码，调用Tian对象的setCourse（）方法，将JavaCourse对象作为参数。 public static void main(String[] args) {最终得到的类图如下： 注： 以抽象为基准比以细节为基准搭建起来的架构要稳定得多，因此大家在拿到需求后，要面向接口编程，按照先顶层再细节的顺序设计代码结构。 单一职责原则定义单一职责原则的定义单一职责原则（Simple Responsibility Principle，SRP）指不要存在一个以上导致类变更的原因。 假设有一个Class负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能会导致另一个职责的功能发生故障。这样一来，这个Class就存在两个导致类变更的原因。 如何解决这个问题呢？我们就要分别用两个Class来实现两个职责，进行解耦。后期需求变更维护互不影响。这样的设计，可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险。 总体来说就是一个Class、Interface、Method只负责一项职责。 案例我们来看代码实例，还是用课程举例，我们的课程有直播课和录播课。直播课不能快进和快退，录播课可以任意地反复观看，功能职责不一样。首先创建一个Course类。 public class ICourse {然后看客户端代码，无论是直播课还是录播课，都调用study()方法的逻辑。 public class Test1 {从上面代码来看，Course类承担了两种处理逻辑。 假如，现在对课程进行加密，那么直播课和录播课的加密逻辑是不一样的，必须修改代码。 而修改代码逻辑势必会相互影响，容易带来不可控的风险。 我们对职责进行分离解耦，分别创建两个类LiveCourse和ReplayCourse。 LiveCourse直播课程： public class LiveCourse {ReplayCourse重播或录像课程： public class ReplayCourse {客户端代码如下，将直播课的处理逻辑调用LiveCourse类，录播课的处理逻辑调用ReplayCourse类。 public class Test2 {当业务继续发展时，要对课程做权限。没有付费的学员可以获得课程的基本信息，已经付费的学员可以获得视频流，即学习权限。 那么对于控制课程层面，至少有两个职责。我们可以把展示职责和管理职责分离开，都实现同一个抽象依赖。 设计一个顶层接口，创建ICourse接口。 public interface ICourse {可以把这个接口拆成两个接口，创建一个接口ICourseInfo和ICourseManager。ICourseInfo接口的代码如下。 ICourseInfo接口的代码如下： public interface ICourseInfo {ICourseManager接口的代码如下： public interface ICourseManager {下面来看方法层面的单一职责设计。有时候，为了偷懒，通常会把一个方法写成下面这样。 public void modifyUserInfo(String userName, String address){还可能写成这样： private void modifyUserInfo(String userName, String... fields){显然，上面两种写法的modifyUserInfo（）方法都承担了多个职责，既可以修改userName，也可以修改address，甚至更多，明显不符合单一职责原则。那么我们做如下修改，把这个方法拆成两个。 private void modifyUserName(String userName){代码在修改之后，开发起来简单，维护起来也容易。在实际项目中，代码会存在依赖、组合、聚合关系，在项目开发过程中还受到项目的规模、周期、技术人员水平、对进度把控的影响，导致很多类都不能满足单一职责原则。但是，我们在编写代码的过程中，尽可能地让接口和方法保持单一职责，对项目后期的维护是有很大帮助的。 接口隔离原则定义接口隔离原则的定义接口隔离原则（Interface Segregation Principle，ISP）指用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。 这个原则指导我们在设计接口时，应当注意以下几点。 （1）一个类对另一个类的依赖应该建立在最小接口上。 （2）建立单一接口，不要建立庞大臃肿的接口。 （3）尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）。 接口隔离原则符合“高聚合、低耦合”的设计思想，使得类具有很好的可读性、可扩展性和可维护性。在设计接口的时候，要多花时间思考，要考虑业务模型，包括还要对以后可能发生变更的地方做一些预判。所以，在实际开发中，我们对抽象、业务模型的理解是非常重要的。 案例我们来写一个动物行为的抽象。 IAnimal接口的代码如下： public interface IAnimal{Bird实现类代码如如下： public class Bird implements IAnimal{Dog类实现的代码如下。 public class Dog implements IAnimal{由上面代码可以看出，Bird类的swim（）方法可能只能空着，Dog类的fly（）方法显然是不可能的。这时候，我们针对不同动物的行为来设计不同的接口，分别设计IEatAnimal、IFlyAnimal和ISwimAnimal接口。 IEatAnimal接口的代码如下： public interface IEatAnimal{IFlyAnimal接口的代码如下： public interface IFlyAnimal{ISwimAnimal接口的代码如下： public interface ISwimAnimal{Dog只实现IEatAnimal和ISwimAnimal接口。 public class Dog implements IEatAnimal、ISwimAnimal{我们来看两种类图的对比，如下图所示，还是非常清晰明了的。 迪米特法则迪米特法则的定义迪米特法则（Law of Demeter，LoD）又叫作最少知道原则（Least KnowledgePrinciple，LKP），指一个对象应该对其他对象保持最少的了解，尽量降低类与类之间的耦合。迪米特法则主要强调只和朋友交流，不和陌生人说话。出现在成员变量、方法的输入和输出参数中的类都可以被称为成员朋友类，而出现在方法体内部的类不属于朋友类。 案例我们来设计一个权限系统，TeamLeader需要查看目前发布到线上的课程数量。这时候，TeamLeader要让Employee去进行统计，Employee再把统计结果告诉TeamLeader，来看代码。 Course类的代码如下： public class Course{Employee类的代码如下： public class Employee{TeamLeader类的代码如下： public class TeamLeader{客户端测试代码如下，将Employee对象作为参数传送给TeamLeader对象 public static void main(String [] args){写到这里，其实功能都已经实现，代码看上去也没什么问题。根据迪米特法则，TeamLeader只想要结果，不需要跟Course产生直接交流。而Employee统计需要引用Course对象，TeamLeader和Course并不是朋友，从如下图所示的类图就可以看出来。 改造Employee类的代码如下。 public class Employee{TeamLeader类的代码如下。 ublic class TeamLeader{再来看如下图所示的类图，Course和TeamLeader已经没有关联了。 学习软件设计原则，千万不能形成强迫症。当碰到业务复杂的场景时，需要随机应变。 里氏替换原则定义里氏替换原则（Liskov Substitution Principle，LSP）指如果对每一个类型为T1的对象O1，都有类型为T2的对象O2，使得以T1定义的所有程序P在所有对象O1都替换成O2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。 定义看上去比较抽象，我们重新解释一下，可以理解为一个软件实体如果适用于一个父类，则一定适用于其子类，所有引用父类的地方必须能透明地使用其子类的对象，子类对象能够替换父类对象，而程序逻辑不变。也可以理解为，子类可以扩展父类的功能，但不能改变父类原有的功能。根据这个理解，我们对里氏替换原则的定义总结如下。 （1）子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。 （2）子类中可以增加自己特有的方法。 （3）当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松。 （4）当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的输出/返回值）要比父类的方法更严格或相等。 案例在讲开闭原则的时候，我们埋下了一个伏笔。我们在获取折扣价格后重写覆盖了父类的getPrice()方法，增加了一个获取源码的方法getOriginPrice()，这显然违背了里氏替换原则。我们修改一下代码，不应该覆盖getPrice()方法，增加getDiscountPrice()方法。 public class JavaDiscountCourse extends JavaCourse{使用里氏替换原则有以下优点：
现在来描述一个经典的业务场景，用正方形、矩形和四边形的关系说明里氏替换原则，我们都知道正方形是一个特殊的长方形，那么可以创建一个长方形的父类Rectangle类，代码如下。 public class Rectangle{创建正方形Square类继承长方形，代码如下： public class Square extends Rectangle{在测试类中，创建resize（）方法。根据逻辑，长方形的宽应该大于等于高，我们让高一直自增，直到高等于宽变成正方形，代码如下。 public class Test {运行结果： width=20 height=11由运行结果可知，高比宽还大，这在长方形中是一种非常正常的情况。再来看下面的代码，把长方形替换成它的子类正方形，修改客户端测试代码如下。 public class Test {运行结果： 此时，运行出现了死循环，违背了里氏替换原则，在将父类替换为子类后，程序运行结果没有达到预期。因此，代码设计是存在一定风险的。里氏替换原则只存在于父类与子类之间，约束继承泛滥。 再来创建一个基于长方形与正方形共同的抽象——四边形QuardRangle接口，代码如下。 public interface QuardRangle {修改长方形Rectangle类的代码如下。 public class Rectangle implements QuardRangle{修改正方形Square类的代码如下。 public class Square implements QuardRangle{此时，如果把resize（）方法的参数换成四边形QuardRangle类，方法内部就会报错。因为正方形已经没有了setWidth（）和setHeight（）方法，所以，为了约束继承泛滥，resize（）方法的参数只能用长方形Rectangle类。 合成复用原则定义合成复用原则（Composite/Aggregate Reuse Principle，CARP）指尽量使用对象组合（has-a）或对象聚合（contanis-a）的方式实现代码复用，而不是用继承关系达到代码复用的目的。 合成复用原则可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较小。继承，又被称为白箱复用，相当于把所有实现细节暴露给子类。 组合/聚合又被称为黑箱复用，对类以外的对象是无法获取实现细节的。我们要根据具体的业务场景来做代码设计，其实也都需要遵循面向对象编程（Object OrientedProgramming，OOP）模型。 案例 还是以数据库操作为例，首先创建DBConnection类。 public class DBConnection{创建ProductDao类。 public class ProdcutDao{这是一种非常典型的合成复用原则应用场景。但是，对于目前的设计来说，DBConnection还不是一种抽象，不便于系统扩展。目前的系统支持MySQL数据库连接，假设业务发生变化，数据库操作层要支持Oracle数据库。 当然，我们可以在DBConnection中增加对Oracle数据库支持的方法，但是这违背了开闭原则。其实，可以不必修改Dao的代码，将DBConnection修改为abstract，代码如下。 public abstract class DBConnection{然后将MySQL的逻辑抽离。 public class MySQLConnection extends DBConnection{再创建Oracle支持的逻辑。 public class OracleConnection extends DBConnection{具体选择交给应用层，来看如下图所示的类图。 总结学习设计原则是学习设计模式的基础。在实际开发过程中，并不是一定要求所有代码都遵循设计原则，而是要综合考虑人力、时间、成本、质量，不刻意追求完美，要在适当的场景遵循设计原则。这体现的是一种平衡取舍，可以帮助我们设计出更加优雅的代码结构。 分别用一句话归纳总结软件设计七大原则，如下表所示。 参考：Tom的架构师笔记 大家好，我是一个写了10来年bug的老田，继续分享架构师技能，对设计模式感兴趣的可以加我wx：tj20120622，一起搞定设计模式。 学得越多，不知道的越多，但咱们还是不能停下学习的jio步。 推荐 码字不易，帮忙转发、点赞、在看，谢啦！ |
|
|
