在学习了一段时间后Java后我们每个人都会使用，可是我们仅仅实现了业务就算完成了吗？
今天来看一下软件设计中常见的设计原则以及开发中的建议
设计原则
单一职责原则
单一职责原则,全称Single Responsibility Principle, 简称SRP. A class should have only one reason to change 类发生更改的原因应该只有一个
单一职责的定义可以理解为：一个对象或者方法，只做一件事。
单一职责原则的核心就是解耦和增强内聚性。
一般实际应用中接口和方法必须保证单一职责
例如方法层面：一个方法只做一件事，这个很好理解；接口层面呢，也是一个接口之处理一种逻辑，不要让类去实现冗余的接口
遵循单一职责原则的过程中，最大的难点就是职责如何划分，划分过细，会导致类过多，也会导致维护困难，划分过粗，可能会违背单一职责原则。
开放-封闭原则
一个软件实体应当对扩展开放，但对修改关闭
这种是理想情况，不可能完全实现，因为需求修修改改😭
怎么样才能做到对扩展开放，对修改封闭呢？
- 方法1：抽象一个接口或者抽象类，定义公共的方法，从而方便扩展。
- 方法2：引用接口或者抽象类，不依赖具体实现类。
- 方法3：接口和抽象类不能修改，可以继承接口或者抽象类从而达到扩展的目的。
发现没有，都是围绕着抽象来进行处理的
在进行抽象的时候，如果需要定义一些通用的方法实现，并且这些方法在多个类中有相似的实现逻辑，那么可以考虑使用抽象类
如果需要定义一些规范或者约束，但不关心具体的实现，或者需要多继承能力，那么可以考虑使用接口
在最初开发的时候，先假设变化永远不会发生，这有利于我们迅速完成需求。当变化发生并 且对我们接下来的工作造成影响的时候，可以再回过头来封装这些变化的地方。然后确保我们不会掉进同一个坑里。
里氏替换原则
所有引用基类（父类）的地方必须能透明地使用其子类的对象。 通俗的说，子类可以扩展父类功能，但不能改变父类原有功能。
里氏替换原则的核心思想就是继承，所以优点就是继承的优点
我觉得里氏替换应该是继承的标准，比如在继承中我们子类尽量不要去覆盖父类的非抽象方法，因为父类这些非抽象方法的实现是在设定一系列的规范和契约，如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏
另一方面要保证透明使用父类的可行性，就要求我们类重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松；另一方面子类实现父类的抽象方法时，返回值要更严格，就是为了防止透明调用父类时，发生类型的向上转型，比如父类返回值是List，子类返回值是Collection，List转型为Collection时向上转型不安全，idea也会提示修改
依赖倒置原则
抽象不应该依赖于细节，细节应当依赖于抽象。 换言之，要针对接口编程，而不是针对实现编程
因为抽象则是相对稳定的，抽象是从众多的事物中抽取出共同的、本质性的特征，是比较难被改变的
依赖抽象，大大提高代码的健壮性，风险自然而然就被降低了
接口隔离原则
类间的依赖关系应该建立在最小的接口上。
类似于单一职责原则
最少知识原则
最少知识原则也称迪米特法则，其含义是：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某个方法的话，可以通过第三者转发这个调用。
一个类对其它类知道的越少越好，就是说一个类应当对其他类有尽可能少的了解，只和朋友通信，不和陌生人说话，知道的越多，越麻烦。
其主要是为了类和类之间的解耦，使程序中的类实现高内聚低耦合。
