设计原则

利用继承来提供对象的行为，会导致： 1、代码在多个子类中重复 2、很难知道所有鸭子的全部行为 3、运行时的行为不易改变 4、改变会牵一发而动全身，造成其他鸭子不想要的改变 设计原则 1 ： 找出应用之中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。 注释：把会变化的部分取出并“封装”起来，以便以后可以轻易的改动或者扩充此部分，好让其他部分不受影响。代码变化引起的不经意后果变少，系统变得更有弹性。 例：在设计鸭子类Duck时，鸭子的行为包括飞和叫，不同鸭子的行为是不同的，所以对于鸭子类Duck来说，行为飞和叫是会变化的部分，所以应当取出并“封装”起来，建立一组新类来代表每个行为。 设计原则 2 ：针对接口编程，而不是针对实现编程。 实现行为与主体分离 注释：利用接口代表每个行为，而行为的每个实现都将实现其中的一个接口。 “针对接口编程”真正的意思是 “针对超类型编程”。 这里“接口”有多个含义，接口是一个“概念”，也是一种java的interface构造。 “针对超类型编程”可以 理解为：变量的声明类型应该是超类型，通常是一个抽象类或者是一个接口，如此，只要是实现此超类型的类所产生的对象，都可以指定给这个变量。这也意味着，声明类时不用理会以后执行时的真正对象类型。 设计原则 3 ： 多用组合，少用继承 使用组合建立系统具有很大的弹性，不仅可将算法族封装成类

【一】为什么要学习设计模式？ 设计模式要解决的软件设计问题：“过于僵硬”（Rigidity）、“过于脆弱”（Fragility）、“复用率低”（Immobility）、“粘度过高”（Viscosity）。 软件设计的目标：可扩展性（Extensibility）、灵活性（Flexibility）、可插入性（Pluggability）。 【二】有哪些设计原则？ 设计模式的原则有： “开-闭”原则（Open-Closed Principle，或者OCP） 里氏代换原则（Liskov Substitution Principle，或者LSP） 依赖倒转原则（Dependency Inversion Principle，或者DIP） 接口隔离原则（Interface Segregation Principle，或者ISP） 组合/聚合复用原则（Composition / Aggregation Principle，或者CARP） 迪米特法则（Law of Demeter，或者LoD） 【三】这些原则如何理解？ 1、 “开-闭”原则（OCP） “开-闭”的意思是：对扩展开放，对修改关闭。（Software entities should be open for extension, but closed for modification. ） 这个原则讲的是，在设计一个模块的时候

开闭原则 软件实体（模块、类、函数等）应该对扩展是开发的，对修改是关闭的。 通俗的讲就是：软件功能是可以扩展的，但是软件实体是不可以被修改的。 当我们在代码中看到else 或者 switch/case 关键字的时候，基本可以判断违反开闭原则了。 策略模式、适配器模式、观察者模式、模板方法模式都可以实现开闭原则，可以在不同场景中解决 if/else 或 switch/case 问题。 来源： oschina 链接： https://my.oschina.net/u/939952/blog/3164958

http://www.cnblogs.com/seacryfly/archive/2011/12/29/2305965.html 只有类对应的（唯一）职责（需求）的变更才会引起代码的重构。 The single responsibility principle states that every module or class should have responsibility over a single part of the functionality provided by the software , and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. Robert C. Martin expresses the principle as follows: [1] “ A class should have only one reason to change. ” 2.2 单一职责原则 2.2.1 引言 一个优良的系统设计，强调模块间保持低耦合、高内聚的关系，在面向对象设计中这条规则同样适用，所以面向对象的第一个设计原则就是：单一职责原则（SRP

如果说开闭原则是面向对象设计的目标的话，那么依赖倒转原则就是面向对象设计的主要实现机制之一，它是系统抽象化的具体实现。依赖倒转原则是 Robert C. Martin 在 1996 年为“ C++Reporter ”所写的专栏 Engineering Notebook 的第三篇，后来加入到他在 2002 年出版的经典著作“ Agile Software Development, Principles, Patterns, and Practices ”一书中。依赖倒转原则定义如下： 依赖倒转原则 (Dependency Inversion Principle, DIP) ：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。 依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。 为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。 在引入抽象层后，系统将具有很好的灵活性，在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中，这样一来，如果系统行为发生变化，只需要对抽象层进行扩展，并修改配置文件，而无须修改原有系统的源代码

对于面向对象软件系统的设计而言，在支持可维护性的同时，提高系统的可复用性是一个至关重要的问题， 如何同时提高一个软件系统的可维护性和可复用性是面向对象设计需要解决的核心问题之一 。在面向对象设计中，可维护性的复用是以设计原则为基础的。每一个原则都蕴含一些面向对象设计的思想，可以从不同的角度提升一个软件结构的设计水平。 面向对象设计原则为支持可维护性复用而诞生，这些原则蕴含在很多设计模式中，它们是从许多设计方案中总结出的指导性原则 。 面向对象设计原则也是我们用于评价一个设计模式的使用效果的重要指标之一，在设计模式的学习中，大家经常会看到诸如“ XXX 模式符合 XXX 原则”、“ XXX 模式违反了 XXX 原则”这样的语句。 最常见的7种面向对象设计原则如下表所示： 表 1 7 种常用的面向对象设计原则 设计原则名称 定 义 使用频率 单一职责原则 (Single Responsibility Principle, SRP) 一个类只负责一个功能领域中的相应职责 ★★★★☆ 开闭原则 (Open-Closed Principle, OCP) 软件实体应对扩展开放，而对修改关闭 ★★★★★ 里氏代换原则 (Liskov Substitution Principle, LSP) 所有引用基类对象的地方能够透明地使用其子类的对象 ★★★★★ 依赖倒转原则 (Dependence

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　第一章 软件架构设计原则 1.1开闭原则-对扩开放，对修改关闭。开闭原则的核心思想就是面向抽象编程。 1.2依赖倒置原则。大家一定要切记：以抽象为基准比以细节为基准搭建起来的架构要稳定的多，因此在拿到需求之后，要面向接口编程，先顶层再细节的设计代码结构。 1.3单一职责原则。总体来说，就是一个类，接口或者方法只负责一项职责。 1.4接口隔离原则。建立单一接口，不要建立臃肿庞大的接口。尽量细化接口，接口中的方法尽量少(适度)。 1.5迪米特原则-最少知道原则。 1.6里氏替换原则。 1.7合成复用原则。 来源： https://www.cnblogs.com/la5qianer/p/12291435.html

两种设计思路： 分解：面向过程 抽象：面向对象 面向对象设计： 隔离变化：宏观层面，减小变化带来的影响 各负其责：微观层面，强调各个类的“责任”，由于需求变化导致的新增类型不应影响原类型（多态） 对象是什么： 语言层面：封装了代码和数据 规格层面：一系列可被使用的公共接口 概念层面：拥有某种责任的抽象 八大设计原则： 依赖倒置：高层模块（稳定）不应依赖于低层模块（变化），二者都依赖于抽象（稳定）；抽象（稳定）不应依赖于细节（变化）（如MainForm和line都依赖于shape） 开放封闭：对扩展开放，对更改封闭；类模块可扩展但不可修改（桌子厂刷涂料） 单一职责：一个类应仅有一个引起它变化的原因，变化的方向隐含着类的责任 李氏替换：子类必须能替换它们的基类（is-a），父类的方法子类都要能用，继承关系要与组合关系区分 接口隔离：接口小而完备，不要都public，子类protected，本类private 优先使用对象组合，而不是类继承：继承本质是类属（组合）关系，简单理解成父-子关系会导致错误使用（高耦合） 封装变化点：一侧变化，一侧稳定，不只是表面上的封装代码和数据 针对接口编程，而不是针对实现：不要将变量类型声明为具体类（业务类，string不算），而是声明为某个接口（如抽象类shape），实现高内聚，松耦合（举例：秦兵器、活字印刷） 23种设计模式分类： 从目的看： 创建型

设计原则 城堡游戏 扩展 字符串被分割 String line = in.nextLine(); String[] words = line.split(" "); 消除代码复制 消除代码复制的两个基本手段，就是函数和父类 封装 用封装来降低耦合 封装的意思是，类自己对自己的成员变量进行一些操作 类和类之间的关系称作耦合 耦合越低越好，保持距离是形成良好代码的关键 扩展 StringBuffer可以用于进行复杂的字符串的操作去产生一个结果字符串的时候 可扩展性 代码的某些部分不需要经过修改就能适应将来可能的变化。 来源： https://www.cnblogs.com/quxiangjia/p/12271802.html

原则一 依赖倒置原则（DIP）： 高层模块（稳定）不应该依赖于底层模块（变化），二者都应该依赖于抽象（稳定）。 抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定）。 原则二： 开放封闭原则（OCP）： 对外扩展开放，对更改封闭。 类模块应该是可扩展的，但是不可修改。 原则三： 单一职责原则（SRP）： 一个类应该仅有一个引起它变化的原因。 变化的方向隐含着类的责任。 原则四 Liskov替换原则（LSP）： 子类必须能够替换它们的基类（IS-A）。 继承表达类型抽象。 原则五 接口隔离原则（ISP）： 不应该强迫客户程序依赖它们不用的方法。 接口应该小而完善。 原则六 优先使用对象组合，而不是类继承： 类继承通常“白箱复用”，对象组合通常为“黑箱复用”。 继承在某种程度上破坏了封装性，子类父类耦合高。 而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。 原则七 封装变化点： 使用封装创建对象之间的分界层，让设计者可以在分界的一侧进行修改，而不会对另一侧产生不良影响，从而实现层次间的松耦合。 原则八 针对接口编程，而不是针对实现编程： 不将变量类型声明为某个特定的具体类，而是声明为某个接口。 客户端程序无需获知对象的具体类型，只需要知道对象所具有的接口。 减少系统中各部分的依赖关系，从而实现“高内聚，松耦合”的类型设计方案。 来源： CSDN 作者：