超前的设计或者过度的设计都不是良好的设计，很多时候我们等到代码在第一次变化的时候可以及时作出反应就够了
单一责任原则(The Single Responsibility Principle )
根据实际情况，拿捏需求的拆分力度，根据拆分的块，来设计对应的类
单一责任原则：我们设计一个类的时候，应该尽量把类的职责单一化；那么我们拿到需求的时候，应该对需求进行分析，再拆分职责，再设计对应的类。在实际工作中吧，其实大部分的程序猿都知道这个道理，主要的阻力是开发时间(偷懒),为了方便处理就不搞太多类了；还是有个原因，就是如果拆分力度大，拆分的太细，那么可能会出现一个简单的需求，你写了好几个类，这样也不是可取的，这种有点过度设计了，没有必要。
举个例子吧，我是做iOS的，就说说界面相关的需求吧，比如说现在产品的需求是做一个word功能的属性面板，里面有几个模块：选择字体，设置对齐方式，设置字体颜色，每个模块都是列表(tableView)，那么在开发前，就应该拆分好，比如说属性面板(容器类),三个子模块(对应三个类)，这样来开发，这就是单一责任的应用了
再举个例子，比如这时候要设计一个工厂类，工厂类需要生产A，B产品，还有一个原料的预加工，现在的需求是原料的预加工，A和B都是一样的，也就是说A和B可以共用这个方法，那么这三个功能就都堆在工厂类里面了。这样是违背了单一责任原则了，但是如果需求确实这边简单，比较小需求，那么这样来开发我觉得也没有问题，毕竟对于大部分怼业务的程序猿来说，又快又稳的出货才是王道。
如果第二期需求来了，要求改动A产品的预加工方式，那么这时候，A和B就不可以公用一个预加工方法了，那么这个时候，就是要及时作出重新设计的考虑了，而且这时候的考虑可以多考虑一下未来可能的改动。
说回刚来产品要求改A产品的预加工需求，如果我们改了工厂类的预加工方法，那么B产品就受影响了。这个就说明了单一责任原则的重要性了，可能降低以后版本迭代中，改动的影响面。对于这个例子，可能一些同学觉得这个很简单就知道我改动预加工方法会影响到B产品，问题是，在比较大项目，复杂的项目中，有时候改动了一个地方，影响到另一个地方是很难发现的，测试阶段发现还好，有时候可能不是很明显，也不是严重的影响，有可能上线了好久才偶然间发现
除了类需要遵循单一职责原则，方法也同样需要，一般方法内的代码不能太多
开闭原则(The Open Closed Principle)
用抽象构建框架，用实现扩展细节
开闭原则：就是写的代码即要有开放性，也要有封闭性，比如现在写一个加法需求，如果一开始就写一个加法类，那么后期扩展，有减法，乘法，除法等，那么是不是继续创建新的类，那么这些加减乘除是不是应该会存在共用的东西，那么就可以抽成一个计算类，这个计算类可以做一些共用的约束，比如计算类可以有formula公式方法，result计算结果的方法，然后加减乘除继承于计算类，重写对应的方法即可。
那么这样的操作，就是对计算类封闭，但是计算类又对外开放，比如继承他，去实现一些细节问题
所以开闭原则说的就是这个意思，用抽象构建框架，用实现扩展细节，比如抽象类(计算类),实现细节由加减乘除子类去做。
需要说明的是，对修改关闭不是说软件设计不能做修改，只是尽量不要做不必要的修改。怎么才能做到呢？那就是有相应的扩展性。
其实，软件有相应的扩展性是好处，但是不能说每个地方都有扩展。反而造成了代码的臃肿。所以这里的扩展与修改关闭是有限制的。这个结合实际的工作开发，如果我们遇到的需求，都考虑弄个抽象类，都自己考虑了以后的一堆扩展，不是说这个考虑不好，只是在开发上浪费了时间，有可能你的架构，在未来很长时间都没有用上，那么这就形同臃肿的架构设计，所以实际开发，还是要按照实际情况去处理，不要为了达到开闭原则写开闭原则。
还有抽象层尽量保持稳定，尽量不修改，因为我们在开发中，修改老旧代码，评估最多的是影响面，如果动到了抽象层，意味着影响面很大
里氏替换原则(Liskov Substitution Principle)
规范子类的书写规则，实现父类抽象方法，不能覆盖父类的具体方法，以此达到父类的方法不被覆盖和父类可以出现的地方，子类就能出现(意思就是比如一个方法的参数是传父类类型，那么这时候传子类进去，也得是没有问题的)
我们设计基类的时候，应该尽量做到基类是抽象的，尽量抽象，如果一个基类的功能够完善，那么这个应该定义为具体类，而不是基类，因为越完善越具体的类，以后子类继承他，子类的扩展性就越差。这就违背了开闭原则。
至于里氏替换原则，说的就是规范一些子类写法的规则，比如
- 子类可以实现父类的抽象方法，但是不能覆盖父类的具体方法
- 子类可以增加自己特有的方法
- 当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
- 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
第三和四点不太理解，这有一个详细的问题，但是我没看懂(https://blog.csdn.net/qq_3496...
说简单点就是开闭原则就是父类尽量抽象，子类扩展，里氏替换原则就是子类实现的细节怎么来写，怎么规范，还有继承必须确保父类所拥有的性质在子类中仍然成立。
接口隔离原则(Interface Segregation Principle)
接口尽量细化，不要臃肿，这里接口的意思就是oc的代理，java的interface
比如现在接口1有5个方法，类A依赖接口1的1-3个方法，类B依赖接口1的3-5个方法；那么类A依赖接口1就必须实现这5个方法，但是4、5方法对于类A来说是完全没有必要实现的，所以这样的接口1设计就是臃肿的，所以我们应该细化他，变成两个接口，对应类A和B
在oc中代理方法有可选的，那么似乎就没有这个问题了，这么看也确实没有，但是@protocol设置@optional的意思是，可以实现，也可以不实现，是非必须的意思。接口隔离原则就是完全不必要实现的，这种情况就需要考虑拆分，细化接口
依赖倒置原则(Dependency Inversion Principle)
面向抽象(接口)编程
接口，抽象，意思就是定义一种规范，协议，自己不实现具体的代码，只是指明了大方向的意思，比如一个公司的老板就是接口，就是抽象的，因为他不用做细节的东西，但是他指定的方向，规范
细节就是具体的实现
比如在iOS中，协议就是接口，抽象类的抽象方法也是接口，我们常说要面向接口编程，而不是面向实现编程，因为接口是文档的，细节的实现是多变的。我们的编程是追求稳定维护程序的，所以我们要面向接口编程
举个例子
初级程序猿类primary
方法：我的工资是1万
薪酬管理类
方法：claculate:(primary *)pri
那么薪酬管理类可以计算出初级程序猿的工资了，但是有个问题，如果要计算中级程序猿的话，那薪酬管理类不就得再添加方法，因为claculate:(primary *)pri方法的入参是初级程序猿类，那这样不行，以后越来越多岗位不就得总去修改薪酬管理类。
所以这时候，我们要面向接口编程
定义一个协议
@protocol EmployeeDelegate
- (void)calculateSalary;
@end 薪酬管理类
- (void)claculate:(id)pri; 这样每个岗位都实现代理方法，然后薪酬管理类的入参是实现了对应代理方法的类，这样就不用新增岗位，就去改管理类的代码了，这就是面向接口编程的一个例子了
总结
单一责任原则是最基本的编程要求，一般我们主要一个类一个责任，一个方法一个责任这样写编写代码。关于代码整洁的话，我的理解就是做到抽取代码，方法内容简洁，对应的方法内做对应的事，这样可以方便以后的查找，维护。
开闭原则就是说要用抽象搭建框架，实现扩展细节，细节交给具体类或者子类来处理和扩展
里氏替换原则就是规范子类的规范；
接口隔离原则，接口（这里的接口指oc的协议）细化，不要臃肿；
依赖倒置原则，就是面向接口编程
我对SOLID之间关系的理解：单一责任原则是最基本的编程原则；开闭原则是整个程序架构的最终目标，里氏替换原则、接口隔离原则，依赖倒置原则都是为了实现开闭原则