漫谈设计模式–设计原则

研磨设计模式中说到，设计模式是指在软件开发中，经过验证的，用于解决特定环境下，重复出现的，特定问题的解决方案。也就是说，设计模式是一种解决方案，是解决特定问题的一种方法，一种手段。前人在遇到这类问题时，使用这样一种解决方案，便可解决这类特定问题，因此也是前人的经验总结。

设计原则只是思想上的指导，设计原则是高度概括和原则性的，只是告诉你不应该违反这些原则，否则会带来不好的影响。而设计模式是实现上的手段，常常可体现多个设计原则，设计原则是设计模式的根。常见的设计原则有

1)单一职责原则

一个类应该仅有一个引起它变化的原因，如果一个类有多个引起它变化的原因，那么意味着这个类有多个职责。我们有时候看到某些代码文件代码有2000,3000行，大多是没有遵循单一职责原则，也就是说职责太多了，引起它变化的原因比较多，这时候代码是极不好维护的，最好能拆分类。
2)开放关闭原则

这是最核心的原则，对扩展开放，对修改关闭。因为修改先前的源代码很容易引入新的Bug，故此需对修改关闭，而系统经常需要应付变化，故此针对变化的地方应该留下扩展的方式。设计程序时，分离变化与不变化的部分，为变化的部分留下扩展的方式，难点就在于分离变与不变，项目初期一般无法预测变化的地方，故此项目初期不应过度设计。

其实实现分离变与不变，并不是只能通过设计模式来实现，我们还可以把变化的部分放在服务器，让服务器动态下发，这样更灵活，可随时调整变化的部分，而不是更新客户端才能应付变化。
3)里氏替换原则

子类型必须能够替换它们的父类型，但是子类型有时候覆盖父类型的方法，故此有时候子类型不能替换父类型，此时违反了里氏替换原则。里氏替换原则是实现开闭原则的一种重要方式，开闭原则常采用继承的方式来实现扩展，里氏替换原则保证了子类型能替换父类型，只有正确替换，才能实现可扩展。
4)依赖倒置原则

依赖于抽象，不要依赖于具体类。高层模块不应该依赖于底层模块，二者都应该依赖于抽象。底层的接口应该是高层提出的，然后是由底层实现的。底层接口的所有权在高层，因此是一种所有权的倒置。

控制反转和依赖注入,依赖倒置：

应用程序依赖ioc容器注入它需要的外部对象

ioc容器控制应用程序需要的外部对象的创建

注意: ioc容器并不是指框架，java，.net都有各自的ioc容器，像spring就有它自身的容器，容器控制外部对象的创建一般都是通过配置文件，android里布局文件用xml描述也是依赖注入的一个例子，应用程序不需要自身去创建各个view对象，而是依赖于android的容器去创建各个view对象，并组合在一起，让activity显示。

传统程序里都是在应用程序里创建A需要的B对象，并设置回A对象，让A对象持有B对象的引用，而现在都是由容器去创建B对象，并设置回A对象里，因此容器掌握了主动权，故此称为控制反转。
5)接口隔离原则

不应该强迫客户依赖于他们不用的方法。这个原则用来处理那些比较庞大的接口，这种接口通常有较多的操作声明，涉及到很多的职责。客户在使用这样的接口时，通常会有很多他不需要的方法，这些方法对于客户来讲，是一种接口污染，相当于强迫用户在一大堆“垃圾方法”中去寻找他需要的方法。因此这样的接口应该被隔离，应该按照不同的客户需求来分离成针对客户的接口。这样的接口，只包含客户需要的操作声明，这样既方了客户的使用，也可以避免因误用接口而导致的错误。
6)最少知识原则

只和你的朋友谈话。应该尽量减少对象之间的交互，对象只和自己的朋友交互，从而松散类之间的耦合。通过松散类之间的耦合来降低类之间的相互依赖，这样在修改系统的某一个部分的时候，就不会影响其它的部分，从而是使得系统具有更好的可维护性。