软件设计原则

两截门--一个被水平分割为两部分的门，这样每一部分都可以独立保持开放或封闭 开放-封闭原则（The Open-Closed Principle) 软件实体（类、模块、函数）应该是可以扩展的，但是不可以修改的。 如果程序中的一处改动就会产生连锁反应，导致一系列的相关模块的改动，那么设计就具有僵化的臭味。如果正确的应用OCP， 那么以后再进行同样的改动时，就只需要添加新的代码，而不必改动已经正常运行的代码。 描述 主要两个特征： “对于扩展是开放的” 模块的行为是可以扩展的，当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。简言之，我们可以改变模块的功能。 “对于更改是封闭的” 对模块进行扩展时，不必改动模块的源代码。 关键是抽象 下图展示了一个简单的不遵循OCP的设计。Client类和Server类都是具体类，Client类使用Server类。如果我们希望Client对象使用另外一个不同的服务器对象，那么就必须要把Client类中使用Server类的地方更改为新的服务器类 下图是根据OCP设计重构的设计 ClientInterface类是一个拥有抽象成员函数的抽象类，Client类使用这个抽象类。如果我们希望Client对象使用一个不同的服务器类，那么只需要冲ClientInterface类派生一个新的类，无需对Client类做任何改动。 Shape应用程序

开闭原则 开闭原则（Open-Closed Principle, OCP）是指一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实现扩展细节。可以提高软件系统的可复用性及可维护性。开闭原则，是面向对象设计中最基础的设计原则。它指导我们如何建立稳定灵活的系统，例如：我们版本更新，我尽可能不修改源代码，但是可以增加新功能。 例如：计算商品价格接口实现类已经写好，这时需求有变做活动打折。 //接口 public interface TestCoreService { Integer getPrice(); String name(); } //实现类 public class TestCoreServiceImpl implements TestCoreService { private String name; private Integer price; public TestCoreServiceImpl(Integer price) { this.price = price; } @Override public Integer getPrice() { return this.price; } @Override public String name() { return this.name; }

开闭原则: 软件实体应对扩展开放 对修改关闭 里氏替换原则: 继承确保超类所有性质在子类中任然成立 是对开闭原则的补充 依赖倒置原则: 上层模块不依赖于下层模块 两者都依赖于抽象 细节不依赖于抽象 抽象依赖于细节 这是面向接口编程 单一职责原则: 一个类有且只有一个引起它变化的原因,否则应该被拆分 接口隔离原则: 要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口,让接口中只包含客户感兴趣的方法 迪米特法则: 只与你的直接朋友交谈,不跟"陌生人"说话 合成复用原则: 要求在软件复用时,要尽量先试用组合或者聚合等关联关系来实现,其次才考虑使用继承关系实现 这 7 种设计原则是软件设计模式必须尽量遵循的原则，各种原则要求的侧重点不同。其中，开闭原则是总纲，它告诉我们要对扩展开放，对修改 关闭； 里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；单一职责原则告诉我们实现类要职责单一；接口隔离原则告诉我们在设计接口的时候要精简单一； 迪米特法则告诉我们要降低耦合度；合成复用原则告诉我们要优先使用组合或者聚合关系复用，少用继承关系复用。 注意：“可见性”表示该属性对类外的元素是否可见，包括公有（Public）、私有（Private）、受保护（Protected）和朋友（Friendly）4 种，在类图中分别用符号+、-、#、~表示。 来源： CSDN 作者：

目录 4.接口隔离原则 5.迪米特法则 6.里氏替换原则 7.合成复用原则 总结： 4.接口隔离原则 接口隔离原则（Interface Segregation Principle，ISP）是指用多个专门的接口，而不是使用单一的总接口，客户端不要依赖自己不需要的接口。这个原则指导我们在设计时注意以下几点： 1、一个类对另一个类的依赖应该建立在最小的接口上 2、建立单一的接口，不要建立复杂臃肿的接口 3、尽量细化接口，接口内方法功能尽量不要重复 接口隔离原则符合我们常说的"高内聚、低耦合"的设计思想，从而提高了类的可扩展性、可维护性和可读性。所以我们在设计接口的时候，要多考虑业务模型和未来可能产生的情况，请看示例： 定义一个动物的接口 public interface IAnimal { void eat ( ) ; void swimming ( ) ; } 定义一个GuangTouQiang，实现动物接口： public class GuangTouQiang implements IAnimal { @Override public void eat ( ) { } @Override public void swimming ( ) { } } 定义一个XiongDa类，实现动物接口： public class XiongDa implements IAnimal {

开闭原则是面向对象的可复用设计的第一块基石，它是最重要的面向对象设计原则。开闭原则由 Bertrand Meyer 于1988年提出，其定义如下： 开闭原则(Open-Closed Principle, OCP)：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。 在开闭原则的定义中， 软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类 。 任何软件都需要面临一个很重要的问题，即它们的需求会随时间的推移而发生变化。当软件系统需要面对新的需求时，我们应该尽量保证系统的设计框架是稳定的。如果一个软件设计符合开闭原则，那么可以非常方便地对系统进行扩展，而且在扩展时无须修改现有代码，使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。随着软件规模越来越大，软件寿命越来越长，软件维护成本越来越高，设计满足开闭原则的软件系统也变得越来越重要。 为了满足开闭原则，需要对系统进行抽象化设计， 抽象化是开闭原则的关键 。在Java、C#等编程语言中，可以为系统定义一个相对稳定的抽象层，而将不同的实现行为移至具体的实现层中完成。在很多面向对象编程语言中都提供了接口、抽象类等机制，可以通过它们定义系统的抽象层，再通过具体类来进行扩展。如果需要修改系统的行为，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Craig Larman氏在《Applying UML and Patterns》一书中提出了GRASP设计模式的概念。作者称其为设计模式，其实，更好的理解应该为设计原则。因为，与GoF等设计模式不同的是，GoF等设计模式是针对特定问题而提出的解决方法，而GRASP则是站在面向对象设计的角度，告诉我们怎么样设计问题空间中的类与它们的行为责任，以及明确类之间的相互关系等等。GRASP可以说是GoF等设计模式的基础。 GRASP是General Responsibility Assignment Software patterns（通用职责分配软件模式）的简称，它的核心思想是“职责分配（Responsibility Assignment）”，用职责设计对象："Designing Objects with Responsibilities"。它包含了9个基本模式： 1 专家模式(Expert) 解决方案：将职责分配给具有履行职责所需要的信息的类 通俗点就是：该干嘛干嘛去，别管别人的闲事或者我的职责就是搞这个，别的事不管。 举个简单的例子，如果有一个类是专门处理字符串相关的类，那么这个类只能有字符串处理相关的方法，而不要将日期处理的方法加进来。也就是提高软件高内聚一种原则。 2 创建者(Creator) 解决方案

1.开闭原则（Open Close Principle） 定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。 开放-封闭原则的意思就是说，你设计的时候，时刻要考虑，尽量让这个类是足够好，写好了就不要去修改了，如果新需求来，我们增加一些类就完事了，原来的代码能不动则不动。这个原则有两个特性，一个是说“对于扩展是开放的”，另一个是说“对于更改是封闭的”。面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。这就是“开放-封闭原则”的精神所在 比如，刚开始需求只是写加法程序，很快在client类中完成后，此时变化没有发生，需求让再添加一个减法功能，此时会发现增加功能需要修改原来这个类，这就违背了开放-封闭原则，于是你就应该考虑重构程序，增加一个抽象的运算类，通过一些面向对象的手段，如继承、动态等来隔离具体加法、减法与client耦合，需求依然可以满足，还能应对变化。此时需求要添加乘除法功能，就不需要再去更改client及加减法类，而是增加乘法和除法子类即可。 绝对的修改关闭是不可能的，无论模块是多么的‘封闭‘，都会存在一些无法对之封闭的变化，既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。在我们最初编写代码时，假设变化不会发生，当变化发生时

1. 单一职责 （SOP Single Responsibility Principle ） 2. 里氏替换（LSP Liskov Substitution Principle ） 子类必须完全实现父类的方法 注：若子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”,则建议断开父子继承关系，采用依赖，聚集，组合等关系代替继承 子类可以有自己的个性 覆盖或实现父类的方法时输入参数可以被放大 方法中的输入参数为前置条件（即，契约原则，先定义出WSDL接口，制定好双方的开发协议，然后再各自实现）； 里氏替换原则也要求制定一个契约，就是父类或接口。契约制定好了，也就同时制定了前置条件和后置条件，前置条件是你要我执行，就必须满足我的条件；后置条件就是我执行完了需要反馈，标准是什么； 如：与父类的方法名相同，参数不同的话，即为重载（Overload）而非覆写（Override） 若，父类方法输入的是HashMap类型，子类输入的参数是Map类型，也就是说子类输入参数类型的范围扩大了，子类替代父类传递到调用者中，子类的方法永远都不会被执行。但是，如果Father类输入的参数类型宽于子类的输入参数类型，则父类存在的地方子类未必可以存在，因为一旦把子类作为参数传入，调用者就很可能进入子类方法的范畴。 覆写或实现父类的方法时输出结果可以被缩小 即，父类一个方法的返回值是T

什么是设计原则？ 设计原则是基本的工具，应用这些规则可以使你的代码更加灵活、更容易维护，更容易扩展。 基本原则 封装变化 Encapsulate what varies. 面向接口编程而非实现 Code to an interface rather than to an implementation. 优先使用组合而非继承 Favor Composition Over Inheritance SRP: The single responsibility principle 单一职责 系统中的每一个对象都应该只有一个单独的职责，而所有对象所关注的就是自身职责的完成。 Every object in your system should have a single responsibility ,and all the object s services should be focused on carrying out that single responsibility . 每一个职责都是一个设计的变因，需求变化的时候，需求变化反映为类职责的变化。当你系统里面的对象都只有一个变化的原因的时候，你就已经很好的遵循了 SRP 原则。 如果一个类承担的职责过多，就等于把这些职责耦合在了一起。一个职责的变化就可能削弱或者抑制这个类其它职责的能力。这种设计会导致脆弱的设计。当变化发生的时候

1、单一职责原则 定义：一个对象应该只包含单一的职责，并且该职责被完整的封装在一个类中。（就一个类而言，应该仅有一个引起它变化的原因） 解释：在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，相当于将这些职责耦合在一起，当其中一个职责变化时可能会影响其它职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可以将它们封装在同一个类中。单一职责原则是实现高内聚，低耦合的指导方针。 2、开闭原则 定义：软件实体应当对外扩展开放，对修改关闭 解释：在开闭原则的定义中，软件实体可以指一个软件模块，一个由多个类组成的局部结构或一个独立的类。开闭原则就是指软件实体应尽量在不修改原有代码的情况下进行扩展。为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。 3、里氏代换原则 定义：所有引用基类的地方必须能透明地使用其子类的对象 解释：里氏替换原则表明，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象，那么它不一定能使用基类对象。 举例：我喜欢动物，那我一定喜欢狗，因为狗是动物的子类；但是我喜欢狗，不能据此断定我喜欢所有动物（基类推子类成立，子类推基类不一定成立）