设计原则

本文源码： GitHub·点这里 || GitEE·点这里 一、单一职责原则 1、概念描述 对类来说的，即一个类应该只负责一项职责。如果一个类负责两个职责，可能存在职责1变化，引起职责2变化的情况。可以基于抽象逻辑，或者业务逻辑对类进行细化。 2、案例演示 这里基于方法和类的细化都可以，可以根据实际业务选择。 class Animal { public void dogVoice (){ System.out.println("狗叫声：旺旺"); } public void cowVoice (){ System.out.println("牛叫声：哞哞"); } } class DogVoice { public String getDogVoice (){ return "旺旺" ; } } class CowVoice { public String getCowVoice (){ return "哞哞" ; } } 3、注意事项 减少代码一处变更引起的程序大规模改动情况，降低类的复杂度，提高类的可读性，可维护性。通常情况下，需要遵守单一职责原则，可以适当违反单一职责原则。 二、接口隔离原则 1、概念描述 客户端不应该依赖它不需要的接口，一个类对另一个类的依赖，应该建立在最小的接口上。 2、案例演示 interface ReadBlog { String getBlog ()

单一职责原则 定义 单一职责原则(Single Responsibility Principle, SRP)是Bob大叔提倡的S.O.L.I.D五大设计原则中的第一个。其中，职责(Responsibility)被表述为“变化的原因”(reason to change)；SRP被表述为“一个类应该有且只有一个变化的原因”。但如果光从字面去理解，SRP很容易让人望文生义产生误解。本文希望能阐明SRP的本质，达到避免误解和指导设计的目的。 动机 对于设计原则的理解应该首先从它的动机入手，即遵循这个原则带来的好处是什么？对于SRP来讲，如果遵循“一个类应该有且只有一个变化的原因”是因，那么“任何一个变化只会影响一个类”就是果。可见SRP的动机主要是系统的可维护性，即降低适应变化的成本。 多功能与单变化 对于单功能的类来讲，比较容易遵循SRP，比如：把string转换为DateTime类型的工具类。理解SRP的难点在于在多功能类的情形，即不容易理解多功能与单变化的矛盾。让我们先来看一个Modem类的例子，Modem具有4个功能：拨号，挂断，发送数据，接收数据： class Modem { public void Dial(string aPno) {…} public void Hangup() {…} public void Send(char aData) {…} public char

本文源码： GitHub·点这里 || GitEE·点这里 一、单一职责原则 1、概念描述 对类来说的，即一个类应该只负责一项职责。如果一个类负责两个职责，可能存在职责1变化，引起职责2变化的情况。可以基于抽象逻辑，或者业务逻辑对类进行细化。 2、案例演示 这里基于方法和类的细化都可以，可以根据实际业务选择。 class Animal { public void dogVoice (){ System.out.println("狗叫声：旺旺"); } public void cowVoice (){ System.out.println("牛叫声：哞哞"); } } class DogVoice { public String getDogVoice (){ return "旺旺" ; } } class CowVoice { public String getCowVoice (){ return "哞哞" ; } } 3、注意事项 减少代码一处变更引起的程序大规模改动情况，降低类的复杂度，提高类的可读性，可维护性。通常情况下，需要遵守单一职责原则，可以适当违反单一职责原则。 二、接口隔离原则 1、概念描述 客户端不应该依赖它不需要的接口，一个类对另一个类的依赖，应该建立在最小的接口上。 2、案例演示 interface ReadBlog { String getBlog ()

以下设计原则是在物联网云平台架构实践（ 参考这里 ）中的一些经验总结，不一定适合所有微服务架构的体系。 单一责任原则：对于一个微服务而言，具有有限的业务范围，可以帮助我们满足服务开发和交付的敏捷性； 适当的边界：关注微服务的范围，而不是一味的把服务做小。一个服务的大小应该等于满足某个特定业务能力所需要的大小； 业务分层： 先把业务分层，形成单向依赖，避免微服务之间的网状依赖关系； 颗粒度递增：初期先把业务划分到尽可能细，然后依据其它原则合并到适当颗粒度； 非唯一依赖：至少被2个以上其它微服务依赖，才有必要独立成一个微服务。 部署独立性：能独立于其它微服务部署，一个微服务故障不影响其它微服务； 动态扩展：每个微服务都可以动态的进行x轴和z轴的扩展，并适应云环境下的自动化部署；（ 参考这里 ） 领域和应用分层： 提供数据基本操作能力的领域服务层和执行业务逻辑的应用服务层解耦； 避免产生频繁的跨库查询； 避免产生频繁的分布式事务。 根据业务和技术分层的情况，对微服务分组治理； 各个分组之间通过API网关集成； 通过API网关实现级轻量级消息路由，鉴权； 运行时管理，如性能，限流，监控等可在API网关实现，让微服务功能纯粹； 避免通过数据库集成； 避免部署多个版本来兼容。 原文： https://www.cnblogs.com/yorkwu/p/9304227.html

7个常用的面向对象的设计原则 单一职责原则、开闭原则、里氏代换原则、依赖倒转原则、接口隔离原则、合成复用原则以及迪米特法则。 单一职责原则 Single Responsibility Principle (SRP)，一个对象应该只包含单一的职责，并且该职责被完整的封装在一个类中。 另一种定义：就一个类而言，应该仅有一个引起它变化的原因。 一个类（大到模块，小到方法）承担的职责越多，它的可复用性就越小。一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中某个职责变化时，可能会影响其它职责。 单一职责原则是实现高内聚、低耦合的指导方针，需要设计人员发现类的不同职责并将其分离。 开闭原则 Open-Closed Principle (OCP)，软件实体（类）应当对拓展开放，对修改关闭。 尽量在不修改原有代码的基础上进行拓展。 抽象化是开闭原则的关键。 里氏代换原则 Liskov Substitution Principle (LSP),所有引用基类的地方必须能透明的使用其子类的对象。 在软件中，将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立。 里氏代换原则是实现开闭原则的基础。 父类设计成抽象类或者接口，让子类继承。运行时，子类实例替换父类实例。 依赖倒转原则 Dependency Inversion Principle (DIP)

作者： pengdai 出处： https://www.cnblogs.com/pengdai 一、开发原则 S：单一职责SRP O：开放封闭原则OCP L：里氏替换原则LSP I：接口隔离法则 D：依赖倒置原则DIP 合成/聚合复用原则 迪米特法则 在软件开发中，前人对软件系统的设计和开发总结了一些原则和模式， 不管用什么语言做开发，都将对我们系统设计和开发提供指导意义。本文主要将总结这些常见的原则和具体阐述意义。 面向对象的基本原则(solid)是五个，但是在经常被提到的除了这五个之外还有迪米特法则和合成复用原则等，所以在常见的文章中有表示写六大或七大原则的； 除此之外我还将给出一些其它相关书籍和互联网上出现的原则； Single-Responsibility Principle，一个类，最好只做一件事，只有一个引起它的变化。单一职责原则可以看做是低耦合、高内聚在面向对象原则的引申，将职责定义为引起变化的原因，以提高内聚性减少引起变化的原因。 一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。（Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.），即又定义有且仅有一个原因使类变更

内聚性： 一个模块的组成元素之间的功能相关性。 就一个类而言，应该仅有一个引起它变化的原因。 当需求变化时，该变化会反映为类的职责的变化，如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个。 如果一个类承担的职责过多，就等于把这些职责耦合在一起。一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。 这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。 什么是职责？ 在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的类必须要重新编译。 在这种情况下

一、依赖倒置原则(DIP) 高层模块（稳定）不应该依赖于底层模块（变化），二者都应该依赖于抽象（稳定） 抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定） 条件：有稳定的类A，不稳定的类B、C，有抽象或者接口D（稳定） 让A依赖B/C则造成依赖倒置，因为是稳定依赖不稳定 正确应该让A、B、C依赖于接口D。稳定依赖稳定，不稳定依赖稳定。 依赖倒置原则其实就是面向接口编程 二、开闭原则（OCP） 类模块应该是可扩展的，但是不可修改 简单工厂模式违反了开闭原则，所以它不在23个设计模式里面。工厂方法和抽象工厂模式遵循了开闭原则。 开闭原则就是功能扩展对外开放，代码修改对内关闭 三、单一原则（SRP） 一个类应该仅有一个引起它变化的原因 变化的方向隐含着类的责任 一个类只负责一件事情，一个职责（对象的创建和使用分离，也是符合单一原则） 四、里式（Liskov）替换原则（LSP） 子类必须能够替换它们的基类（IS-A） 不要改变父类原有的功能，不然就是组合了而不是继承了 子类可以扩展父类的功能，但不要改变父类原有的功能 五、接口隔离原则（ISP） 设计接口功能尽量细粒度，最小功能单元 不应该强迫客户程序依赖它们不用的方法 接口应该小而完备 设计接口功能尽量细粒度，最小功能单元 六、迪米特原则（LoD） 又叫最少知识原则，就是说一个对象应当对其他对象尽可能少的了解

结合日常开发生产，总结Mysql数据库开发设计原则如下： 尽量不在数据库做运算 在mysql中尽量不要使用如：md5()、Order by Rand()等这类运算函数 尽量控制单表数据量 单表数据量过大后会影响数据查询效率 2.1单表数据量预估： ①. 纯 INT 不超过 1000W ②. CHAR 不超过 500W 2.2同时要尽量做好合理的分表： 通过 USERID 来分表（根据 ID 区间分表） 按 DATE 分表（按天、周、月分表） 按 AREA 分表（省、市、区分表） 2.3分区表的适用场景主要有： ① 表非常大，无法全部存在内存，或者只在表的最后有热点数据，其他都是历史数据； ② 分区表的数据更易维护，可以对独立的分区进行独立的操作； ③ 分区表的数据可以分布在不同的机器上，从而高效使用资源； ④ 可以使用分区表来避免某些特殊的瓶颈； ⑤ 可以备份和恢复独立的分区。 避免使用NULL字段 在数据库表字段设计的时候尽量都加上NOT NULL DEFAULT ‘’ 3.1 很难进行查询优化 3.2 NULL列加索引，需要额外空间 3.3 含NULL复合索引无效 不在数据库里存图片 如果将图片全部存在数据库，将使得数据库体积变大，会造成读写速度变慢。 图片存数据库的弊端： 对数据库的读/写的速度永远都赶不上文件系统处理的速度 数据库备份变的巨大，越来越耗时间

开闭原则（Open Closed Principle，OCP）的定义是：软件实体应当对(提供者的)扩展开放，对(使用者)的修改关闭。 开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。 开闭原则是面向对象程序设计的终极目标，设计模式的其他各项原则和其他各种设计模式，都是对开闭原则的体现。 可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。 来源： https://www.cnblogs.com/asenyang/p/11761131.html