面向对象范式&&设计模式
抽象类
抽象类经常被描述为“不能实例化的类”。这个定义是正确的-在实现层次上。但是在概念层次定义抽象类才更有助于理解。其概念为其他类的占位符。
生
那也就是说，他们给我们为一组相关的类命名的方法。这让我们可以把一组类当作一个概念来处理。
事实上，需要理解抽象类并不困难。尤其从概念上理解而不是从语法和实现层次上。生物这是一种人为产生的概念，其本质就是一种抽象类，而且生物所共有的特性就是所谓的纯虚函数，例如 1.应激性 2.繁殖与发展 3.摄食……（生物的特征本来有7个来着，不过我初中一结束就全部忘掉了）。生物是不能够实例化的，你也无法说出一种名为“生物”的生物。而且生物界是一个多重继承的关系，生物下面还有动物,然后脊椎动物，然后鸟类，然后界门纲目科属种我就不举例了。实际上能够实例化的类只有“杜鹃”这种已经没有纯虚函数的物种。它overload了所有的函数，并且有自己的行为。
里氏代换原则（LSP）
Liskov Substitution Principle（里氏代换原则）：子类型(subtype)必须能够替换它们的基类型。
反过来的代换不成立
“软件单位的功能不受到影响”
设计方法
一种面对对象的设计方法是:观察问题->提取名词->创建对象->提取动词(即对象行为)->添加方法(特指类成员函数)->提取抽象(形成继承及多态).但是这样将注意力集中与名词和动词往往导致臃肿的类体系,也可以说是组合爆炸.更优秀的方法应该是在创建对象的时候使用共同点/变化点分析.
- 发现并封装变化点
- 优先使用对象组合,而不是类继承
变化点是可以体现在类继承当中的,当一个基类派生出多个子类.这些不同子类之间的差别就是变化点.之所以推荐优先使用对象组合,是因为这样可以讲变化点独立开来,从而使将来的变化(不断变化的需求)不会影响到现在的代码.
自顶向下,逐步求精
很早之前就接触过这个概念,我当然能看懂每字每句的含义,但是一直没有理解到底什么叫做自顶向下,也许只是因为我接触的太早了, 在我们英文的C++教材,how to program里面过早的告诉我们这点,也许作者希望我们能够先有设计模式这样一种概念,然后再慢慢加深理解.
为什么要在设计模式里面说自顶向下呢?一个优秀的pattern必然是一个联系精密结构优美的整体,在这个整体的基础上,不断的分化,最终形成各个小的部分,这和自顶向下的思想是同步的.而我们一般书写程序都是从细节开始慢慢向上层写,因为细节总是很容易写的,例如我最近在写的一个LBS的软件,我先写了获取地理座标的类,获得了longitude和latitude然后自然就想到解析地址,随后再到上传地址给服务器,从服务器获取在本机周围的人的名单,最后处理表现.对于代码来说,这样来写完全符合人类思维逻辑,但是对于日常生活(还有设计模式)来说,却刚好相反,你在描述一样东西的时候是绝对不会从细节开始描述的,例如你想描述一座房子,总是整体->局部的顺序.
但是,自顶向下也有自己不可避免的弊端:接口设计和细节实现之间的不匹配以及接口的过度投资.第一点当然可以由长久的开发经验和优秀的设计来弥补,后面一点确是很难弥补的,因为无法确定最终需要的细节是什么.不过和自底向上相比,依然有着优势,在重构的时候负担会轻松的多.一个程序难免需要重构,第一次实现的时候就能确认细节,在重构的时候就可以充分考虑扩展性和灵活性来为之更新了.
参考
- 里氏代换原则
- 设计模式精解-Alan&James
