前言
上一篇介绍了《Head First设计模式》这本书的一个大纲，这一篇说下我对这本书里提到的一些设计原则的思考。
学习设计原则或者整个设计模式之前，我们都应该坚定的一个原则就是：简单设计、简单实现。能简单做到的就不要复杂化，设计原则和设计模式更适用于复杂系统的，不要乱用。
设计原则就像是马克思主义一样，它给全世界的无产阶级提供一个根本性的思想指导，而不是行为指导。在不背离基本原则的情况下，执行的人是可以随意发挥的，中国特色社会主义就是在马克思主义指导下的一个最适合中国发展的特色产物，生搬硬套只会像苏联一样僵化而崩溃。
在学习中，本没有对错，适合的才是最好的。
封装变化
将系统中可能变化的地方提取出来，单独做一个方法（或类），这样再发生变化的时候只要修改这个方法（或类）就可以了，而不需要修改整个设计。因为改的越多，出错的可能就越大。
目标：系统中的某部分改变不会影响其他部分
提取时机：如果每次新的需求一来，都会使某方面的代码发生变化，那么你就可以确定这部分的代码需要被抽出来
多用组合，少用继承
什么是组合：讲几个类结合起来使用（has-a：有一个）
什么是继承：直接继承父类（is-a：是一个）
组合可以将算法族封装成类，也可以在”运行中动态的改变行为“
继承容易造成过度亲密，因为子类对父类的了解总是超过后者的主观愿望。
针对接口编程，不针对实现编程
”针对接口编程“真正的意思是”针对超类型编程“，充分利用了多态的特性。
多态是指面向对象语言中，接口的多种不同的实现形式。Charlie Calverts对多态的描述：多态性是允许你将父对象设置成为一个或更多的他的子对象相等的技术，赋值之后，父对象就可以根据当前赋值给它的子对象的特性以不同的方式运作 --来源 百度百科
针对实现编程（Dog是Animal的具体实现）
Dog dog = new Dog();
dog.bark();
针对接口编程（知道对象是dog，但是利用animal进行多态调用）
Animal animal = new Dog();
animal.makeSound();
为交互对象之间的松耦合设计而努力
将对象之间的相互依赖降到最低。
系统设计时应有的意识就是：软件是“软”的，从根本上就是具有可变的特性的，所以我们的终极目标就是设计出高内聚、低耦合的系统，以便随时应对用户的需求变更。
单一职责原则：类应该只有一个改变的理由
尽量让每个类保持单一责任
修改代码很容易造成很多意想不到的错误，所以我们应该尽量降低每个类的变化几率。
内聚被用来度量一个类或模块是否紧密地达到单一目的或责任，当一个类或模块被设计成只支持一组相关的功能时，具有高内聚；被设计支持一组不相关的功能时，具有低内聚
开闭原则：类应该对扩展开放，对修改关闭
应对各种需求的变化，不应该需求一变化就去直接改类的实现。
保证核心代码不变，然后在此基础上扩展以实现需求。也就是说要允许类容易扩展，在不修改现有代码的情况下就可搭配新的行为。（比如观察者模式，不需要修改核心代码，只需要加入新的观察者就好了）
这个原则需要依赖的原则就是：单一职责原则，只有单一职责的类才能更好地达到对修改关闭这个要求。
依赖倒置原则：依赖抽象，不依赖具体类
不能让高层组件依赖低层组件，而且都应依赖于抽象
变量不可以持有具体类的引用
不要让类派生自具体类
不要覆盖基类中已实现的方法（基类中已实现的方法，应该由所有的子类共享）
最少知识原则：只和朋友交谈
不要让太多的类耦合在一起，免得修改系统的一部分会影响到其他部分。
减少对象之间的交互，减少了对象之间的依赖
可能会导致复杂度和开发时间的增加，并降低运行时的性能
好莱坞原则：别找我，我会找你
别调用我们，我们会调用你
高层组件调用低层组件 ，避免有环状依赖
将决策权放在高层模块中，以便决定如何以及何时调用低层模块
个人收获
设计原则是帮助我们解决变化问题的，所以请将他们用在正道上，不要滥用，再好的方法如果滥用的话都会失去它的意义。
在用设计原则解决问题的同时，很可能会导致复杂度和开发时间的增加，并降低运行时的性能，所以在设计的时候要权衡，如果代价大于收益的话我们就考虑要不要用了。
网友评论