设计原则

开闭原则： 对于类，模块函数等扩展要开放，对于修改要关闭。 依赖倒置： 接口或抽象是高层，要面向高层编程，不应该面向实现类（实现类是低层）去变成。 单一职责： 对一个类，或者一个功能，只用负责一个职责。 接口隔离原则： 接口中要单一（方法尽量的少），尽量细化，不能臃肿。 迪米特原则： 低耦合，高内聚（两个类相互调用的，互相知道得信息越少越好，避免在修改某一个类的时候对另一个类影响过大） 里氏替换原则： 继承与派生的规则（在继承父类时候要注意可以扩展方法，但是尽量不要修改父类方法或者删除对方法的引用，以及尽量不要重写父类方法） 合成复用原则/组合： 尽量使用组合和聚合少使用继承的关系来达到复用的原则。 来源： https://www.cnblogs.com/songyinan/p/11745756.html

《 OO设计原则总结 》一文中我提出了一个问题： 如何更好的使用这些原则？ 怎样在实践中遵守这些原则，使用三种视角思考问题就是答案之一； 本文内容包括： 1. 为什么我们过早的纠缠于细节？问题的本质是什么？ 2. 救命稻草 --Martin Fowler 的三层视角理论 3. 三层视角 -- 回头再说 OO 设计原则 为什么我们过早的纠缠于细节？问题的本质是什么？ 做设计时过早的关注细节几乎是多数程序员的泥沼，也是我自己的顽疾。就像我刚开始工作不久要做一个自动更新的系统，设计会议上开发组老大定了使用 FTP 协议完成，你知道我脑袋里面想的是什么？ -- “ Indy 组件好像不支持中文” …... 过早的关注细节，大体上可能有两种原因：1.经验丰富，举一反三，纲举目张，各种技术玄妙如数家珍 2.没有什么经验，只知道点技术细节，难以跳出思维桎梏；我知道我是后者，以前是现在也是。 人是有惰性的，人们习惯性的做自己熟练精通的事情。所以做设计的时候，当对大框架缺少把握能力的时候，潜意识里我更愿意去思考那些细节。这是在偷懒，所有的技术细节、问题都是没有疑问的(我们不是做科研)，或者是有疑问你可以很容易获得解答无论是开发文档还是在社区。细节的解决方案总是显而易见，但并非肯定是最好的入手点。 有时候我真的要做设计了，我想要避免陷入“细节泥沼”可是我还是无意中把细节扯进来，这是为什么？剖析自己

描述：按照哪一种思路或者标准来实现功能。功能相同，可以有不同的设计方案来实现。伴随着需求增加，设计的作用才能体现出来 结合《UNIX/LINUX 设计思想》 准则1: 小即时美 准则2: 让每个程序只做好一件事 准则3: 快速建立原型（规划了一个东西，做了三年，做完发现不是用户想要的，先做个小的，再修改） 准则4: 舍弃高效率而取可移植性（比如软件比较低效，但是他后面可以被硬件抹平） 准则5: 采用纯文本来存储数据 （可读性方便，存二进制可读性很差） 准则6: 充分利用软件的杠杆效应（软件复用，能抽象的抽象，能复用的复用） 准则7: 使用shell脚本来提高杠杆效应和可移植性 准则8: 避免强制性的用户界面（linux只有命令行，用户界面占很多内存） 准则9: 让每个程序都称为过滤器 小准则： 允许用户定制环境 小准则： 尽量使操作系统内核小而轻量化 小准则： 使用小写字母并尽量简短 小准则： 沉默是金 小准则： 各部分之和大于整体 小准则： 寻求90％的解决方案（只解决90%的人的问题，剩下的10%爱用不用） 演示：沉默是金 ＋ 让每个程序称为过滤器 比如终端输入：ls，会输出所有文件和文件夹，ls其实就是过滤器。他把当前的所有文件和文件夹给过滤出来 还可以通过输入：ls | grep 'package'。在ls下所有的文件中过滤出文件名含package的文件 当输入ls |

首先提一下java的设计原则: 1.CHANGE (能应对变化) 2.KISS(keep it simple &studio 保持代码简单的易读性) 3.DRY(don't repeat youself 不要写一些重复的代码) 4.SRP(single responsibility principle 单一职责原则) 5.OCP(open closed principle 对外开放,对内封闭) 6.LSP(liskov substitution principle 里氏置换原则) 7.ISP(interface single principle 接口隔离原则) 8.DIP(dependence Inversion principle 依赖倒置原则) 当然,还有其他很多例如:CARP LOD COC .... 关于java的设计原则,网上有很多.可以参考: http://blog.csdn.net/gaolei1201/article/details/47082783 现在,开始要说的是,在什么样的场景下使用他们. 案例:输出三行 hello World 首先,我们肯定想到的是: public class HelloWorld { public static void main(String[] args) { System.out.println("Hello World");

设计原则 有说五大原则，六大原则，七大原则；这不重要，重要的是了解这些原则是什么；设计原则要有取舍； 开闭原则： 定义：一个软件如实体、类模块和函数应该对扩展开放，对修改关闭。 开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求 用抽象构建框架，用实现扩展细节 提高软件系统可复用性及可维护性 作用 开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。具体来说，其作用如下。 1. 对软件测试的影响 软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行。 2. 可以提高代码的可复用性 粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。 3. 可以提高软件的可维护性 遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。 接口应该是稳定且可靠的 实现方法 可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。 因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时

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

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

7 种设计原则，它们分别为 开闭原则 、 里氏替换原则 、 依赖倒置原则 、 单一职责原则 、 接口隔离原则 、 迪米特法则 和本节所介绍的合成复用原则。 这 7 种设计原则是软件 设计模式 必须尽量遵循的原则，各种原则要求的侧重点不同。其中，开闭原则是总纲，它告诉我们要对扩展开放，对修改关闭；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；单一职责原则告诉我们实现类要职责单一；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合度；合成复用原则告诉我们要优先使用组合或者聚合关系复用，少用继承关系复用 来源： https://www.cnblogs.com/wygflying163/p/11640245.html

前言： 怎么设计自动化测试用例？是不是所有的手动用例都适合转成自动化测试用例？ 设计自动化测试用例需考虑的方面： 1、并不是所有的手工用例都要转为自动化测试用例。 考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分成多个用例来实现脚本。 2、选择的用例最好可以构建成场景。 例如，一个功能模块，分多个用例，多个用例使用同一个场景。 3、选择的用例可以带有目的性。 例如，这部分是用例做冒烟测试，那部分用例是做回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。 选取的用例可以是主体流程，这部分适用于冒烟测试。 4、选取的用例可以是你认为是重复执行，很烦琐的部分。 例如，字段验证、提示信息验证这类，这部分适用于回归测试。 5、自动化测试也可以用来做配置检查、数据库检查。这些可能超越了手工用例，但也算用例拓展的一部分，项目负责人可以有选择地增加。 6、平时在手工测试时，如果需要构造一些复杂的数据或重复一些简单的机械式动作，则告诉自动化脚本，让它来帮你，或许你的效率会因此而得到提高。 在编写自动化测试用例过程中应该遵守以下几点原则： 1、一个用例为一个完整的场景，从用户登录系统到最终退出并关闭浏览器。 2、一个用例只验证一个功能点，不要试图在用户登录系统后把所有的功能都验证一遍。 3、尽量少的编写逆向逻辑用例

概述 简单介绍一下七大设计原则： 开闭原则 ：是所有面向对象设计的核心，对扩展开放，对修改关闭 依赖倒置原则 ：针对接口编程，依赖于抽象而不依赖于具体 单一职责原则 ：一个接口只负责一件事情，只能有一个原因导致类变化 接口隔离原则 ：使用多个专门的接口，而不是使用一个总接口 迪米特法则（最少知道原则） ：只和朋友交流（成员变量、方法输入输出参数），不和陌生人说话，控制好访问修饰符 里氏替换原则 ：子类可以扩展父类的功能，但不能改变父类原有的功能 合成复用原则 ：尽量使用对象组合(has-a)/聚合(contanis-a)，而不是继承关系达到软件复用的目的 合成复用原则 定义 合成复用原则(Composite/Aggregate Reuse Principle,CARP)是指尽量使用对象组 合(has-a)/聚合(contanis-a)，而不是继承关系达到软件复用的目的。可以使系统更加灵 活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。 继承我们叫做白箱复用，相当于把所有的实现细节暴露给子类。组合/聚合也称之为黑箱 复用，对类以外的对象是无法获取到实现细节的。要根据具体的业务场景来做代码设计， 其实也都需要遵循 OOP 模型。 示例 还是以数据库操作为例，先来创建 DBConnection 类: /** * @author eamon.zhang * @date