设计原则

设计模式（Design Pattern）是前辈们对代码开发经验的总结，是解决特定问题的一系列套路。它不是语法规定，而是一套用来提高代码可复用性、可维护性、可读性、稳健性以及安全性的解决方案。 1995 年， GoF （Gang of Four，四人组/四人帮）合作出版了《设计模式：可复用面向对象软件的基础》一书，共收录了 23 种设计模式，从此树立了软件设计模式领域的里程碑，人称「GoF设计模式」。 这 23 种设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性，以及类的关联关系和组合关系的充分理解。 当然，软件设计模式只是一个引导，在实际的软件开发中，必须根据具体的需求来选择： 对于简单的程序，可能写一个简单的算法要比引入某种设计模式更加容易； 但是对于大型项目开发或者框架设计，用设计模式来组织代码显然更好。 关于本教程 本教程虽然命名为“Java设计模式”，但是设计模式并不是 Java 的专利，它同样适用于 C++、C#、JavaScript 等其它面向对象的编程语言。 Java 是典型的面向对象的编程语言，所以本教程以 Java 为基础来讲解这 23 种设计模式，如果你不了解 Java，请猛击《 Java教程 》学习。 教程目录：1. 软件设计模式概述 2. GoF 的 23 种设计模式的分类和功能 3. UML中的类图及类图之间的关系 4. 开闭原则

内聚性 　　类应该描述一个单一的实体，而所有的类操作应该在逻辑上相互配合，支持一个一致的目的。 一致性 　　遵循标准Java程序设计风格和命名习惯。 封装性 　　一个类应该使用private修饰符隐藏其数据，以免用户直接访问。 清晰性 　　为使设计清晰，内聚性、一致性和封装性都是很好的设计原则。 完整性 实例和静态 　　依赖与类的具体实例的变量或方法必须是一个实例白能量或方法。如果一个变量被类的所有实例所共享，那就应该将他声明为静态的。 继承与聚合 　　集成和聚合之间的差异，就是is-a(是一种)和has-a(具有)之间的关系。例如苹果是一种水果，人具有名字。 接口和抽象 　　接口和抽象都可以用于为对象指定共同的行为。如何决定是采用接口还是类呢？通常，比较强的is-a(是一种)关系清晰的描述了父子关系，应该采用类来建模。例如苹果是一种水果，他们之间的关系就应该采用类的集成关系来建模。弱的is-a关系，也称为is-kind-of(是一类)关系，表明一个对象具有某种属性。弱的is-a关系可以使用接口来建模。例如所有的字符串都是可比较的，因此String类实现了comparable接口。 来源： https://www.cnblogs.com/cglib/p/11976339.html

目录 一、单一职责原则 二、接口隔离原则 三、依赖倒转原则 四、里氏替换原则 五、开闭原则 六、迪米特原则 七、设计原则总结 八、源代码地址 本文源码： 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、概念描述 客户端不应该依赖它不需要的接口

本文源码： 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 ()

Task1 满意之处 （1）在登录的时候下方有登录密码提示信息，对于像我这种不怎么登录教务系统不记得初始密码的人来说是非常方便的。 体现了UX设计原则第五条“适合各类用户（不绝对）”以及第七条“必要的提示和帮助文档”。 （2）页面布局整体比较整洁，且重点关注消息有标识，比较明了。以左右板块的形式，符合一般人使用习惯。 符合UX设计标准第二条“界面符合惯例”以及第四条“一致性与标准化”。 （3）响应式布局，适合于分屏和在手机上浏览网页的用户，体现了UX设计原则第五条“适合各类用户（不绝对）”。 Task2 不足之处 （1）一打开页面就看到了左边很大的一块空白区域。鉴于多数人都没有添加应用，用这么大一块区域，还放在左上方似乎有点浪费空间了，而且不够美观。 有一个系列位置效应提过系列中的第一个和最后一个项目更容易被用户记住，所以这一块空白是没必要的。 此外还带来一个问题就是在屏幕缩放时，最上面的就是我的应用。 违反了UX设计原则第二条“界面符合惯例”。 我的建议是调整一下全局页面的布局，把用的少的模块放下面，并减少所占面积，用滚动条。 （2）成绩查询时无法显示相应信息。 违反了UX设计原则第一条“给用户及时快速反馈”。 建议做好这一模块，用户一点击就能分页显示成绩信息。 （3）课表只能批量下载，不能先预览。对于只是想查看课表的人来说是不方便的，下载这部也是多余的。

继数据结构与算法之美后，王争老师的专栏又开始更新了，这次是《设计模式之美》，希望学习之后会对自己有所提升。在此记录下自己的学习笔记，希望对自己或者看到的读者都有所裨益。 为什么每个程序员都要尽早地学习并掌握设计模式相关知识？ 1. 应对面试中的设计模式相关问题 学习设计模式和算法一样，最功利、最直接的目的，可能就是应对面试了。 不管你是前端工程师、后端工程师，还是全栈工程师，在求职面试中，设计模式问题是被问得频率比较高的一类问题。特别是一些像 BAT 、 TMD 这样的大公司，比较重视候选人的基本功，经常会拿算法、设计模式之类的问题来考察候选人。 2. 告别写被人吐槽的烂代码 我们经常说， Talk is cheap，show me the code 。实际上，代码能力是一个程序员最基础的能力，是基本功，是展示一个程序员基础素养的最直接的衡量标准。你写的代码，实际上就是你名片。 3. 提高复杂代码的设计和开发能力 大部分工程师比较熟悉的都是编程语言、工具、框架这些东西，因为每天的工作就是在框架里根据业务需求，填充代码。实际上，这样的工作并不需要你具备很强的代码设计能力，只要单纯地能理解业务，翻译成代码就可以了。 但是，有一天， leader 让开发一个跟业务无关的比较通用的功能模块，面对这样稍微复杂的代码设计和开发，就发现会有点力不从心，不知从何下手了。因为只是完成功能、代码能用

有可能重复别的文章,只是自己的一个整理 单一法则 类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障或者难以维护,这就违背了单一职责 一个类只负责一件事儿,一个方法只负责一件事儿,写了太多的分支判断,去执行各自的业务逻辑时候,就容易出现职责不单一,所以只能拆分解决职责不单一的问题 类拆分:父类+子类,每个类就很简单,类内部很简单,简单就意味着稳定,未定就是开发永恒的追求,拆分以后:代码量就变多了,类增多了,(解读量增大了,理解成本增大了) 如果方法足够简单,类够少,其实违背一下单一职责也无所谓,如果方法多了,业务逻辑复杂,建议遵循单一职责。 方法的单一职责:一个方法只负责一件事儿(根据职责分拆小方法,避免分支逻辑判断) 类的单一职责:一个类只负责一件事儿 类库的单一职责:一个类库应该职责清晰 系统层面的单一职责:为通用的功能分拆系统 优点: 降低类的复杂度 提高类的可读性,因为类的职能单一,看起来比较有目的性,显得简单 提高系统的可维护性,降低变更程序引起的风险 里氏替换原则 任何使用基类的地方,都可以透明的使用其子类 继承:子类拥有基类的一切属性和行为,任何基类出现的地方都可以用子类代替 继承+透明(安全,不会出现行为不一致的情况) 在创建对象的时候尽量使用父类做变量的声明;为了能够更加灵活

8个原则 1. 依赖倒置原则DIP 高层模块(稳定), 不应该依赖于底层模块(变化), 二者都应该依赖于抽象. 抽象(稳定)不依赖于实现细节(变化), 实现细节应该依赖于抽象(稳定). 2. 开放封闭原则OCP 对扩展开放, 对更改封闭 类模块应该是可扩展的, 但是不可修改.(不是去修改,而是增加代码, 去应对需求变化) 3. 单一职责原则(SRP) 一个类应该仅有一个引起它变化的原因. 变化的方向隐含着类的责任. 4. Liskov替换原则(LSP) 子类必须能够替换他们的基类(IS-A) 继承表达类型抽象 5. 接口隔离原则(ISP) 不应该强迫客户程序依赖他们不用的方法 接口应该小(少)而完备(ISP的另一个说法) 也就是说, 没有必要,就不需要让一个接口成为public. 反面说， 能private 就不protected， 能protected就不public。 6. 优先使用对象组合,而不是类继承 类继承通常为"白箱复用", 对象组合通常是"黑箱复用" 类继承某种程度上"破坏了封装性", 父子类耦合度高 类组合, 具有良好的接口封装性, 耦合度低 7. 封装变化点 使用封装来创建对象之间的分界层, 让设计者从一侧从修改, 而不是对另一侧产生不良的影响. 8. 针对接口编程, 而不是针对实现编程 不将变量类型声明为某个具体类,而是声明为某个 接口

单一职责原则 SRP 开闭原则 OCP 里氏替代原则 LSP 依赖注入原则 DIP 接口分离原则 ISP 迪米特原则 LOD 组合/聚合复用原则 CARP 其他原则可以看作是开闭原则的实现手段或方法，开闭原则是理想状态 Java 自学指南 Java 面试题汇总PC端浏览【点这里】 Java知识图谱 Java 面试题汇总小程序浏览，扫二维码 所有资源 资源汇总于公众号 来源： https://www.cnblogs.com/ConstXiong/p/11880300.html

单一职责原则的定义 　　单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。 　　该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点： 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力； 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。 单一职责原则的优点 　　单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。 提高类的可读性。复杂性降低，自然其可读性会提高。 提高系统的可维护性。可读性提高，那自然更容易维护了。 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。 单一职责原则的实现方法