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