1提高编码质量，代码可读性和可维护性。
 
2代码编写规范
 
2.1 删除所有无用代码 
 2.2 必须给代码添加注释，一个类的注释字数不得小于代码的百分之20% 
 2.3 建议遵循30秒原则。如果另一个程序员无法在三十秒内无法知道你的函数在做什么，如何做以及为什么要这样做，那么说明你的代码是难于维护的，需要得到提高。 
 2.4 一个函数的代码长度不允许超过100行，超过一百行的函数建议在不破坏原子性的基础上进行拆分。 
 2.5 变量都应在方法或者类的头部集中定义 
 2.6 保证一行代码只做一件事 
 2.7 使用括号来控制操作符的运算顺序，以免使用java默认的操作符优先级顺序。 
 2.8 代码格式化：对代码进行格式化，再进行提交。 
 2.9 接口不允许没有方法或者变量的声明
 
命名规范 
 3.1 各种标识符的命名要使用有实际意义的英文单词或者英文单词缩写，缩写词及英文单词要收录在项目的简写词汇表中。切忌使用阿拉伯数字和拼音进行命名。 
 3.2 类名：首字母大写，每个单词首字母都需要大写。 
 3.3 方法名：首字母小写，其余单词首字母都需大写。 
 3.4 全局变量，和常量名称要求全部字母大写。 
 3.5 参数名称与局部变量基本相同，区别在于参数名称需要加上冠词a ，an 或者在单词结尾以s结束。 
注释规范 
 4.1 注释需要注意的事项： 
 ★注释应该用中文清晰表达意思，应该是程序看起来更清晰，更容易理解 
 ★注释要尽量简明，避免装饰性的注释。 
 ★注释不但要说明做什么，还应当说明为什么要这样做。最好先写注释表明要做什么，再进行编码。 
 
4.2 类的注释 
 ★类的用途，目的。包括其他人感兴趣的介绍。 
 ★已知bug,当然最好是修改好所有的错误，但有时可能暂时没有办法修改，或者没有时间修改。 
 ★开发和维护该类的历史列表，记录每一次修改的作者，日期，修改的内容。 
 ★列举类的各种稳定状态，说明调用成员函数使类的状态产生的变迁(可选)。 
 ★同步问题（可选） 
 ★对主要的算法必须加以说明，主要流程必须给予引导性说明 
 标准格式： 
 如果对已经版本话的类进行了修改，需要按照如下格式为每一次修改附加修改历史记录： 
 // 修改人 + 修改日期 
 // 修改说明 范例：
 
// 李四 2010/07/02 
 // 添加错误数据修改后继续批量保存的处理函数 saveBatch( 
 @Bind(key = “itemParams”, defaultValue = “”) String itemParams, 
 @Bind(key = “pid”, defaultValue = “”) String pid)。 
 // 王小二 2010/07/02
 
4.3 接口注释： 
 ★接口的注释风格基本与类的注释风格相同； 
 ★在别人使用接口之前，必须了解接口所包含的概念。检验一个接口是否应该定义的简单方法是：你是否能★够容易的描述接口的用途； 
 ★接口如何应当和不应当被使用。开发者需要知道该接口如何被使用，也希望知道该接口不能被怎样使用。
 
4.4 函数的注释 
 ★函数头注释必须包括：函数执行了什么功能，为什么要这样处理；函数处理过程中对对象的哪些属性 
 ★可能进行更改；函数执行前后，对象的状态； 
 ★比较、循环等控制结构加注释（可选）； 
 ★在代码的功能并非一目了然的情况下，应当说明为什么要这样做； 
 ★局部变量必须加注释； 
 ★复杂难写的代码必须加注释；
 
4.5类属性的注释: 
 ★描述域的用途。使别人知道如何去使用它； 
 ★对于有着复杂事物规则的域，可以加入范例来说明。有时候一个简单的小例子，抵的上千言万语；

开了博客，为了能够更好的学习，对于自己不了解和还没有掌握的知识加以归类，巩固以及加强。
现在主要针对的是代码设计的原则，在设计代码的时候，不能总是想到哪就打到哪，还需要有个大致的流程，否则写出来的代码也是很繁冗，不够简洁。对于自己的代码编程还没达到一个期望的程度，对于代码的设计。主要注意以下的六大原则：
单一职责
一个类或者一个接口，最好只负责一项职责。

开闭原则
一个软件实体如类、模版和函数应该对扩展，对修改关闭；

里氏替换原则
子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法； 
* 子类可以增加自己特有的方法； 
* 当子类的方法重载父类的方法时，方法的形参要比父类方法的输入参数更佳宽松； 
* 当子类的方法实现父类的抽象方法时，方法的返回值要比父类更加严格；

依赖倒置原则
 低层模块尽量都要有抽象类或者接口，或者两者都有； 
* 变量的声明类型尽量是抽象类或者接口； 
* 使用继承时遵循里氏替换原则；

接口隔离原则
* 一个接口只服务于一个子模块或业务逻辑，服务定制； 
* 通过业务逻辑压缩接口中的public方法，让接口看起来更加精悍； 
* 已经被污染了的接口，尽量修改，如果变更风险太大，则用适配器模式进行转化； 
* 根据具体的业务，深入了解逻辑，用心感知去控制设计思路；

迪米特原则
定义：一个对象应该对其他对象保持最少的了解，其核心精神就是：不和陌生人说话，通俗之意就是一个对象对自己需要耦合关联调用的类应该知道的少；这会导致类之间的耦合度降低，每个类都尽量减少对其他类的依赖。

 单一职责原则 Single Responsibility Principle
 
 定义：一个类或者一个接口，最好只负责一项职责。
 
 问题由来：类T负责两个不同的职责P1和P2。由于职责P1需要发生改变而需要修改T类，就有可能导致原来运行正常的职责P2功能发生故障。
 
 解决方法：遵循单一职责原则。分别建立新的类来对应相应的职责；这样就能避免修改类时影响到其他的职责；
 
 
 
 当遇到职责扩散的时候，在逻辑足够简单的时候，才可以在代码级别上面违反单一职责原则，只有类中方法数量足够少，才可以在方法级别上违反单一职责原则；
 
 
 优点：类的复杂性将会降低，可读性将会大大提高，维护性也会提高。
 
 
 里氏替换原则 Liskov Substitution Principle
 
 在使用基类的地方可以任意使用其子类，能保证子类完美替换基类；这一种精神其实是对继承机制约束规范的体现。在父类和子类的具体实现中，严格控制继承层次中的关系特征，以保证用子类替换基类时，程序行为不发生问题，且能正常进行下去。
 
 对于继承来说，父类定义了一系列的规范和契约，虽然不强制所有的子类必须遵从，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破环。
 
 
 
 如果非要重写父类的方法，比较通用的方法是：原来的父类和子类都继承一个更加通俗的基类，原有的继承关系去掉，采用依赖、聚合、组合等关系代替；
 
 
 原则包含了一下四层含义： 
 * 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法； 
 * 子类可以增加自己特有的方法； 
 * 当子类的方法重载父类的方法时，方法的形参要比父类方法的输入参数更佳宽松； 
 * 当子类的方法实现父类的抽象方法时，方法的返回值要比父类更加严格；
 
 
 依赖倒置原则 Dependence Inversion Principle
 
 定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象，其核心思想是依赖于抽象；
 
 问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来完成；这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原则操作；假如修改类A，会给程序带来不必要的风险。
 
 解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I来间接与类B和类C发生联系，则会降低修改类A的几率；
 
 在实际中，我们一般需要做到以下三点： 
 * 低层模块尽量都要有抽象类或者接口，或者两者都有； 
 * 变量的声明类型尽量是抽象类或者接口； 
 * 使用继承时遵循里氏替换原则；
 
 
 接口隔离原则 Interface Segregation Principle
 
 定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上，否则将会造成接口污染；类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现它们不需要的方法；
 
 原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少；就是说，我们要为每个类建立专用的接口，而不要试图去建立一个庞大的接口供所有依赖它的类去调用；
 
 
 
 注意，接口尽量小，但是要有限度，对接口进行细化可以提高程序设计灵活性，但是如果过小，则会导致接口数量尽量小，使设计复杂化。所以一定要适度，为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来；
 
 
 规则： 
 * 一个接口只服务于一个子模块或业务逻辑，服务定制； 
 * 通过业务逻辑压缩接口中的public方法，让接口看起来更加精悍； 
 * 已经被污染了的接口，尽量修改，如果变更风险太大，则用适配器模式进行转化； 
 * 根据具体的业务，深入了解逻辑，用心感知去控制设计思路；
 
 如何实施接口隔离，主要有两种方法： 
 1. 委托分离，通过增加一个新的接口类型来委托客户的请求，隔离客户和接口的直接依赖，注意这同时也会增加系统的开销； 
 2. 多重继承分离，通过接口的多重继承来实现客户的需求；
 
 
 迪米特法则
 
 定义：一个对象应该对其他对象保持最少的了解，其核心精神就是：不和陌生人说话，通俗之意就是一个对象对自己需要耦合关联调用的类应该知道的少；这会导致类之间的耦合度降低，每个类都尽量减少对其他类的依赖。
 
 
 合成复用原则
 
 原则是尽量使用合成/聚合的方式，而不是使用继承；
 
 开闭原则
 
 定义：一个软件实体如类、模版和函数应该对扩展，对修改关闭；
 
 解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是修改已有的代码来实现变化；
 
单一职责原则：实现类要职责单一；
里氏替换原则：不要破坏继承体系；
依赖倒置原则：面向接口编程；
接口隔离原则：设计接口的时候要精简单一；
迪米特法则：降低耦合；
 
 开闭原则：总纲，对扩展开放，对修改关闭；

单一职责原则 Single Responsibility Principle
 
定义：一个类或者一个接口，最好只负责一项职责。
 
问题由来：类T负责两个不同的职责P1和P2。由于职责P1需要发生改变而需要修改T类，就有可能导致原来运行正常的职责P2功能发生故障。
 
解决方法：遵循单一职责原则。分别建立新的类来对应相应的职责；这样就能避免修改类时影响到其他的职责；
 
 
 
当遇到职责扩散的时候，在逻辑足够简单的时候，才可以在代码级别上面违反单一职责原则，只有类中方法数量足够少，才可以在方法级别上违反单一职责原则；
 
 
优点：类的复杂性将会降低，可读性将会大大提高，维护性也会提高。
 
 
里氏替换原则 Liskov Substitution Principle
 
在使用基类的地方可以任意使用其子类，能保证子类完美替换基类；这一种精神其实是对继承机制约束规范的体现。在父类和子类的具体实现中，严格控制继承层次中的关系特征，以保证用子类替换基类时，程序行为不发生问题，且能正常进行下去。
 
对于继承来说，父类定义了一系列的规范和契约，虽然不强制所有的子类必须遵从，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破环。
 
 
 
如果非要重写父类的方法，比较通用的方法是：原来的父类和子类都继承一个更加通俗的基类，原有的继承关系去掉，采用依赖、聚合、组合等关系代替；
 
 
原则包含了一下四层含义： 
 * 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法； 
 * 子类可以增加自己特有的方法； 
 * 当子类的方法重载父类的方法时，方法的形参要比父类方法的输入参数更佳宽松； 
 * 当子类的方法实现父类的抽象方法时，方法的返回值要比父类更加严格；
 
 
依赖倒置原则 Dependence Inversion Principle
 
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象，其核心思想是依赖于抽象；
 
问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来完成；这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原则操作；假如修改类A，会给程序带来不必要的风险。
 
解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I来间接与类B和类C发生联系，则会降低修改类A的几率；
 
在实际中，我们一般需要做到以下三点： 
 * 低层模块尽量都要有抽象类或者接口，或者两者都有； 
 * 变量的声明类型尽量是抽象类或者接口； 
 * 使用继承时遵循里氏替换原则；
 
 
接口隔离原则 Interface Segregation Principle
 
定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上，否则将会造成接口污染；类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现它们不需要的方法；
 
原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少；就是说，我们要为每个类建立专用的接口，而不要试图去建立一个庞大的接口供所有依赖它的类去调用；
 
 
 
注意，接口尽量小，但是要有限度，对接口进行细化可以提高程序设计灵活性，但是如果过小，则会导致接口数量尽量小，使设计复杂化。所以一定要适度，为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来；
 
 
规则： 
 * 一个接口只服务于一个子模块或业务逻辑，服务定制； 
 * 通过业务逻辑压缩接口中的public方法，让接口看起来更加精悍； 
 * 已经被污染了的接口，尽量修改，如果变更风险太大，则用适配器模式进行转化； 
 * 根据具体的业务，深入了解逻辑，用心感知去控制设计思路；
 
如何实施接口隔离，主要有两种方法： 
 1. 委托分离，通过增加一个新的接口类型来委托客户的请求，隔离客户和接口的直接依赖，注意这同时也会增加系统的开销； 
 2. 多重继承分离，通过接口的多重继承来实现客户的需求；
 
 
迪米特法则
 
定义：一个对象应该对其他对象保持最少的了解，其核心精神就是：不和陌生人说话，通俗之意就是一个对象对自己需要耦合关联调用的类应该知道的少；这会导致类之间的耦合度降低，每个类都尽量减少对其他类的依赖。
 
 
合成复用原则
 
原则是尽量使用合成/聚合的方式，而不是使用继承；
 
开闭原则
 
定义：一个软件实体如类、模版和函数应该对扩展，对修改关闭；
 
解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是修改已有的代码来实现变化；
 
单一职责原则：实现类要职责单一；
里氏替换原则：不要破坏继承体系；
依赖倒置原则：面向接口编程；
接口隔离原则：设计接口的时候要精简单一；
迪米特法则：降低耦合；
 
开闭原则：总纲，对扩展开放，对修改关闭；