设计原则

一、SOLID原则

      个人认为单一职责、里式替换、接口隔离、依赖倒置都是为开闭原则服务的，即代码的扩展性。主要原因还是需求一直再变更，原有代码扩展性不强，如果修改已有代码可能会引入多余的测试、bug等工作量。单一职责是站在某个类、方法本身去设计；里式替换原则是父子关系设计；接口隔离和依赖倒置都是高层依赖底层时，对底层的要求，本质上就是底层变更后不会影响高层的代码变更。

1、单一职责（A调用B，B站在自己的角度考虑如何设计）

      以场景来分析某个类、模块、方法等是否具备唯一职责。而单一职责是一个主观的原则，一般是以具体的场景分析是否具备。具体就是不要设计大而全的类，采用细而功能单一的类。

       具体可以根据：代码的长度、命名是否明确（一般类、方法等名字都不明确，代码自然就是不够单一职责的）、依赖不要太多、大量方法操作某几个属性。

        单一职责：是站在类、方法本身去设计的。

2、开闭原则（主观、大层面原则）

      对扩展开放、对修改关闭。其实就是代码的扩展性问题。我理解扩展一般是横向扩展，而修改则是上下修改的。

      如何判断？没有破坏原有的代码逻辑、没有破坏原有的测试用例。

      扩展性可以考虑：面向接口而非实现编程、暴露不可变隐藏可变的、封装抽象思想，以及其他几大原则，我认为本身都是用于服务开闭原则的。如：单一职责，一个方法职责单一，修改他的可能性越低。

       而修改并不是一点代码都不该，本身就不现实，尽可能的将修改更集中、更少、更上层，避免修改核心代码。

3、里式替换原则（父子关系原则）

      子类能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变，正确性不被破坏。

      反例：违背父类的功能、违背父类的输入输出异常等约定、违背任何特殊的说明。比如：父类在检测失败时，抛IllegalArgumentException异常，而子类却返回null，这本身就破坏了原有的语义。尽管子类可以替换父类，那只不过是多态的性质而已。

4、接口隔离原则（A调用B，A对B接口的要求）

      A要求B，不要给我提供多余的不需要的接口，接口内部不要给我多余的信息，不要让我实现多余的接口等。

5、依赖倒置（A依赖B，A对B的要求）

      高层模块不依赖底层模块，而是以抽象为缓冲；抽象不依赖具体实现，具体实现细节依赖抽象。本身是A依赖B的，按理说，B怎么提供A就怎么使用，而现在是A对依赖的B提出来一系列的要求，所以叫依赖倒置或依赖反转等。

 

二、kiss原则：尽量保持简单、易懂。比如：不要使用太过复杂的正则表达式、太过高级的语法。kiss原则是站在代码编写的角度来说的。但是简单、易懂都是比较主观的看法，具体问题具体分析。

 

三、DRY：Don't Repeat Yourself.主要是站在语义的角度来理解。

           代码重复、语义不重复。是符合DRY原则的。如：校验username和password，刚开始的代码完全一样，但是语义不一样，password更可能会变更等，即使保留两份一样的代码也是可以的。

           代码不重复、语义重复。比如：校验username的代码，业务逻辑完全一样，但是因为多位同事实现了两份，且在不同的地方调用了，本质上就是重复的代码。

           代码执行重复。比如：username代码，在同一个方法中被调用多次校验username，本身也是不符合DRY原则的。