写代码时是否必要遵循几大设计原则？

1、单一职责原则
意思大概是一个模块、一个类、一个方法中，职责是明确的，每个功能是单一的，如果职责过于复杂就又可以继续拆分。
单一职责原则 无论什么时候都应该有用，职责分离后，结构变得更加清晰，更加简单易懂，容易扩展修改，容易理解和维护。

2、对扩展开放，对修改关闭
意思是写好的功能模块或者类或者函数，对于内部的修改是拒绝的，对于扩展来增强功能是开放的。
为什么提倡写好了一个函数后不要去改它？一个点可能是比如spring，如果每个版本都把方法名、参数、实现的内容改一下，那引入这些函数的广大项目开发者估计难受的很。
一个接口或者函数应该在设计之初就明确自己的职责提供什么功能，除非是实现这种功能的方式需要优化去改动，而不应该去改变这个函数当初的职责。
为什么要改代码？业务逻辑变了那就要改，那如果是添加功能呢？最好还是重用和扩展吧，那如果一开始就设计的复杂冗余，后面也只能调整了。

3、里氏替换原则
字面意思：父类出现的地方，都可以使用子类替代。
子类继承父类，需要父类接口的地方当然可以使用子类对象。所以子类是一定能够替代父类。这只是从语法上理解，这样的话那代码怎么写只要不报错就可以运行还用得着设计原则呀。。
子类能够替换父类，主要在于子类重写了父类的方法，重写过程中必然是改变了内容，里氏替换原则需要重写确保一点，就是不忘初心，父类的方法本来是算平方的，你给重写成算立方，这时候父类出现的地方还用这个子类，估计会出问题，原来意思都变了。

4、接口隔离原则
意思：不强制要求使用依赖不相关的接口
比如设计如下接口：

interface 电源{
	充电（）{}
	吃饭（）{}
}

你想充电吗？来吧实现电源接口，然后吃饭接口用不上怎么办？但是不写实现会报错的哦？
那到底电源接口是用来充电的还是用来吃饭的？充电吧，实现吃饭算啥意思；吃饭吧，那咋叫电源接口？
所以隔离吧，分开吧。
这里的接口不单是接口的概念，可以理解为其他层面，理解成类，那么类的职责就应该专一，理解成方法，那么方法就不应该实现太多的功能，不然对于哪些只需要部分功能的调用者来说是没法复用的。
而且，关联越少，改动的牵涉就越少，改动就越有针对性，就容易扩展维护。

5、依赖倒转原则
来看下别人的描述：

就是说，不要写死依赖，依赖都是依赖抽象的协议或概念，依赖方和被依赖方通过这个抽象协议来具体的组合到一起。
比如：

interface Database {
	void connect();
}

//DatabaseConnection依赖抽象接口Database
class DatabaseConnection{
	public void connect(Database database){}
}
//Mysql实现接口
class Mysql implements Database {
	void connect(){
		//mysql的连接方式
	}
}

这样DatabaseConnection不会被具体哪种数据库绑定死，具体依赖控制权给到了具体使用者，和具体实现解耦了依赖关系，无依赖污染，对于扩展非常方便。

6、迪米特法则
这命名词不达意啊，就跟"爱因斯坦理论"一样（小时候书中的偶像人物）。
还有个名字：最少知道原则
跟那句“永远不要来找我，我会去找你”神似。
不要老是什么地方都要插一手，关系复杂后很难梳理。也不要对那些与自己无关的知道的太多，专心于自己能做的部分。
最少知道，也就是最少依赖，也是各司其责，最终同一功能高内聚，不同功能低耦合，之间关系简单明了。

---

以上六大原则，目的好像都是为了一个：简单而强大。