设计原则

文章目录 一、分解与抽象 1、分解-分而治之 2、抽象-面向对象 二、设计模式基本原则 1、依赖倒置原则（DIP） 2、开放封闭原则（OCP） 3、单一职责原则（SRP） 4、里氏替换原则（LSP） 5、接口隔离原则（ISP） 6、优先使用对象组合，而不是类继承 7、封装变化点 8、针对接口编程，而不是针对实现编程    使用设计模式是为了可重用代码 ，让代码更容易被他人理解，保证代码可靠性，设计模式使代码编制真正工程化。 一、分解与抽象 1、分解-分而治之    人们面对复杂性有一个常见的做法：即分而治之， 将大问题分解为多个小问题，将复杂问题分解为多个简单问题 。其思想我们在数据结构中有提及。分解主要用于结构化设计思维：像C语言之类，当然我们在C++面向对象中也可以使用，但是我们尽可能使用抽象思想。 class Point { public : int x ; int y ; } ; class Line { public : Point start ; Point end ; Line ( const Point & start , const Point & end ) { this - > start = start ; this - > end = end ; } } ; class Rect { public : Point leftUp ; int width ;

设计模式之六大原则（转载） 　　关于设计模式的六大设计原则的资料网上很多，但是很多地方解释地都太过于笼统化，我也找了很多资料来看，发现CSDN上有几篇关于设计模式的六大原则讲述的比较通俗易懂，因此转载过来。 　　原作者博客链接： http://blog.csdn.net/LoveLion/article/category/738450/7 一.单一职责原则 　　原文链接： http://blog.csdn.net/lovelion/article/details/7536542 　　单一职责原则是最简单的面向对象设计原则，它用于控制类的粒度大小。单一职责原则定义如下： 单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。 单一职责原则告诉我们：一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。 单一职责原则是实现高内聚、低耦合的指导方针

1.前言 面向对象三大特性：继承，封装，多态 面向对象是一种 程序思想 而设计模式是一些代码设计经验形成的 设计范式 面向对象的设计原则是介于面向对象和设计模式中间，是 面向对象优秀代码的设计思想 　 2. 面向对象设计七大原则 说到设计原则，不免说到七大原则 （1） 单一原则： 作用：降低类的复杂性和提高可读性 做法：每个类只负责一项职责，如果类中方法少，则在方法级别上保持单一原则也行 　　 总之当类不单纯时，利用接口，类和方法等来分解类 例子：dao层的一个类操作一个表 　　出行工具类->改成空中飞行类+水中类+陆地类 　　　　　　 ->改成类中飞行出行方法+水中方法+陆地方法 （2） 接口隔离原则： （比较简单） 接口是动作集合（动词），就是一类技能，设计接口要适合项目 类是实体（名词），类实现接口说明类要有这些功能，实现接口要切合功能 （3） 依赖倒置原则则： 作用：扩展性 做法：当具体类相似且很多时，用抽象类或者接口做抽象层，抽象层被依赖有利于扩展 例子：如人类要聚合衣服抽象类，衣服有夹克，T恤 　　人要聚合饮食接口，饮食的方式有吃水果，喝水 （4） 里式替换原则： （比较简单） 接口隔离原则不要实现不切合的接口 里式替换原则不要继承不切合的类，一部分切合的类可以让他们继承更基础的类 如：b要调用a的方法去，继承他，但又要重写它，此时就要将ab关系重构为组合。 （5）

快速理解 SOLID (面向对象设计)——开闭原则 在程序设计领域， SOLID（单一功能、开闭原则、里氏替换、接口隔离以及依赖反转），指代了面向对象编程和面向对象设计的五个基本原则。当这些原则被一起应用时，它们使得一个程序员开发一个容易进行软件维护和扩展的系统变得更加可能。 1. 开闭原则 1.1 开闭原则 的定义 开闭原则 不是一种编程方法，而是一种编程思想。 程序应该是对于扩展开放的，但是对于修改封闭的。 1.2 开闭原则 解决了什么问题 在项目运营期间，难免会以为需求变化，升级，维护等原因需要对代码修改。而在修改过程中有可能会对原有功能的破坏。 1.3 开闭原则 举个例子 开闭原则没有什么特定的方法实现，其实开闭原则就是对其他的设计原则的总结。做好其他的设计原则自然而然的实现了开闭原则。 1.4 开闭原则 的总结 开闭原则不是一种编程方法，而是一种编程思想。 关注我的微信公众号，查看更多文章，第一时间收到我的文章。 来源： https://blog.csdn.net/qq_18208265/article/details/100827453

row key长度原则 不应设计过长，row key是冗余存储，数据的持久化文件HFile 中是按照KeyValue 存储的，row key越长会影响Hfile的存储效率 MemStore 将缓存部分数据到内存，Rowkey 字段过长内存的有效利用率会降低，系统将无法缓存更多的数据，这会降低检索效率 Row key散列原则 row key尽量散列，将Rowkey的高位作为散列字段，将提高数据均衡分布在每个Regionserver 实现负载均衡的几率。避免热点访问(在做数据检索的时候负载将会集中在个别RegionServer，降低查询效率) Row key唯一原则 设计上保证其唯一性。 来源： https://blog.csdn.net/weixin_39950222/article/details/100826571

开闭原则相关的面向对象设计原则（） 里氏代换原则(Liskov Substitution Principle LSP) 依赖倒转原则（Dependence Inversion Principle）单一职责原则：应该有且仅有一个原因引起类的变更(一个接口或一个类只有一个原则，它就只负责一件事) 里式替换原则：子类型必须能替换掉它们的基类型 依赖倒置原则 ： 高层模块不应该依赖低层模块，两者都应该依赖其抽象 抽象不应该依赖细节 细节应该依赖抽象 接口隔离原则： 客户端不应该依赖它不需要的接口 类间的依赖关系应该建立在最小的接口上 迪米特法则：只与直接朋友进行通信 来源： https://www.cnblogs.com/CKhomepage/p/10624802.html

内聚性： 一个模块的组成元素之间的功能相关性。 就一个类而言，应该仅有一个引起它变化的原因。 当需求变化时，该变化会反映为类的职责的变化，如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个。 如果一个类承担的职责过多，就等于把这些职责耦合在一起。一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。 这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。 什么是职责？ 在SRP中，吧职责定义为“变化的原因”。如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个职责。有时，很难注意到这一点，我们习惯于以组的形式去考虑职责。 Modem接口，大多数人认为这个接口非常合理： public interface Modem { public void dial(String pno); public void hangup(); public void send(char c); public void recv(); } 然而，该接口却显示两个职责（1）连接管理（2）数据通信。 dial和hangup连接处理，send和recv数据通信 这两个职责应该被分开吗？这依赖于应用程序变化的方式。如果应用程序的变化会影响连接函数的签名，那么这个设计就具有僵化性的臭味，因为send和recv的类必须要重新编译。 在这种情况下，这两个职责应该被分离

GOF23种设计模式(Design Pattern)总结 设计模式 常用程度 适用层次 引入时机 结构复杂度 Abstract Factory 比较常用 应用级 设计时 比较复杂 Builder 一般 代码级 编码时 一般 Factory Method 很常用 代码级 编码时 简单 Prototype 不太常用 应用级 编码时、重构时 比较简单 Singleton 很常用 代码级、应用级 设计时、编码时 简单 Adapter 一般 代码级 重构时 一般 Bridge 一般 代码级 设计时、编码时 一般 Composite 比较常用 代码级 编码时、重构时 比较复杂 Decorator 一般 代码级 重构时 比较复杂 Facade 很常用 应用级、构架级 设计时、编码时 简单 Flyweight 不太常用 代码级、应用级 设计时 一般 Proxy 比较常用 应用级、构架级 设计时、编码时 简单 Chain of Resp. 不太常用 应用级、构架级 设计时、编码时 比较复杂 Command 比较常用 应用级 设计时、编码时 比较简单 Interpreter 不太常用 应用级 设计时 比较复杂 Iterator 一般 代码级、应用级 编码时、重构时 比较简单 Mediator 一般 应用级、构架级 编码时、重构时 一般 Memento 一般 代码级 编码时 比较简单 Observer

第一章 策略模式 00设计原则： 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码放在一起。 把会变化的部分取出并封装起来，好让其它部分不会受到影响。结果如何？代码变化引起的不经意后果变少，系统变得更有弹性。 00设计原则： 针对接口编程，而不是针对实现编程。 “针对接口编程”真正的意思是“针对超类型编程”： 这里的接口有多个含义，接口是一个概念，也是一种java的interface构造。”针对接口编程“关键就在多态。利用多态，程序可以针对超类型编程，执行时会根据实际情况执行到真正的行为，不会被绑死在超类型的行为上。这句话可以更明确的说成”变量的声明类型应该是超类型，通常是一个抽象类或者是一个接口。如此，只要是具体实现此超类型的类所产生的对象，都可以指定给这个变量。这也意味着声明类时不用理会以后执行的真正对象类型。 OO设计原则： 多用组合，少用继承 使用组合建立系统具有很大的弹性，不仅可以将算法族封装成类，更可以“在运行时动态地改变行为”，只要组合的行为对象符合正确的接口标准即可。 策略模式 定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。 类图 JDK java.util.Comparator#compare() javax.servlet.http.HttpServlet javax.servlet

开闭原则 OCP / Open Closed Principle 尚硅谷设计模式-学习笔记 ---------------- 开闭基本介绍 开闭原则是编程 最基础，最重要的设计原则 一个软件实体如类，模块，方法，应该 对扩展开放 （对提供方）， 对修改关闭 （对使用方）; 用抽象构建框架，用实现扩展细节 。 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化 编程中遵循其他原则，以及使用设计模式的目的就是遵循开闭原则。 ---------------- 开闭原则实例 实例简介：完成一个画图形的功能 Example：传统方式 public class OCP1 { public static void main ( String [ ] args ) { //使用看看存在的问题是什么 GraphicEditor graphicEditor = new GraphicEditor ( ) ; graphicEditor . drawShape ( new Rectangle ( ) ) ; graphicEditor . drawShape ( new Circle ( ) ) ; } } //这是一个用于绘图的类[使用方] //接受Shape对象，根据其type绘制不同的图形 class GraphicEditor { public void