快速云需求决定设计面向对象最大的设计陷阱

　　通过面向对象的思路，我们可以把任何事物都看成一个对象然后单独处理，从理想的角度，任何一个微小的单元都可以以一个对象的形式表示。比如我们可以用如下代码表示一个人以及它的姓名：
　　1.不分离姓名
　　class 人 {
　　public string 姓名;
　　}
　　但是这个世界是很复杂的，姓名本身是由姓和名组成的。如果我们需要需要单独处理姓和名时，要怎么办?于是我们可以这么拆分：
　　2.直接分离姓名
　　class 人 {
　　public string 姓;
　　public string 名;
　　}
　　但我们会碰到这个问题：姓和名本身是一个整体，处理姓名的逻辑不应该放在人这个类里面，而应该单独提取出来。于是代码改为：
　　3. 提取姓名为单独一个类，然后单独处理
　　class 人 {
　　public 姓名 姓名;
　　}
　　class 姓名 {
　　public string 姓;
　　public string 名;
　　}
　　这是一个非常理想的状态：任何事物都被表示成了一个独立的对象。但其实作者都是懒的，没人会愿意为姓名单独写一个类然后单独处理它。除非逻辑非常复杂需要单独处理时，才会选择把它提取出来。
　　同样一个人，把它写成面向对象的代码之后，却有3种不同的写法(1. 不分离姓名。 2. 直接分离姓名。 3.提取姓名为单独一个类，然后单独处理)。而决定我们用哪个写法的是最需求。需求是软件开发中最不稳定的因素，因此面向对象的代码经常需要重构和重写。这就是面向对象中的一个设计陷阱。
　　再来看一个例子：
　　abstract class 鱼 {private int 价格;
　　private int 口感;public int get价格(){ return 价格; }
　　public int get口感(){ return 口感; }
　　public abstract string get名字();
　　}
　　class 鲤鱼: 鱼 {
　　public override string get名字() {
　　return ＂鲤鱼＂;
　　}
　　}
　　class 桂鱼: 鱼 {
　　public override string get名字() {
　　return ＂桂鱼＂;
　　}
　　}
　　这是一个最普通的面向对象的代码了。从上面看似乎完美到没有任何问题：通过鱼这个类以及它的多态特性，我们可以很轻松地处理所有鱼。
　　但是这时加了一个需求，我们需要处理金鱼，于是写了这么一行代码：
　　class 金鱼: 鱼 {
　　public override string get名字() {
　　return ＂金鱼＂;
　　}
　　}
　　看上去依然完美，但问题是：金鱼是不能吃的，获取它的口感是没有任何意义的!但是通过继承，我们的金鱼也是可以有口感的。同时，还浪费了一个内存用来存储这个没有意义的口感字段。
　　现实中，很多人都忽视了这个问题：反正没意义，这个函数不要调用就行了。对的，但如果一个继承了一个父类之后，5个函数是有意义的，20个函数是没有意义的，这时我想作者该犯洁癖了吧。问题主要是在于继承一个类之后，有一些成员是不必要或者无意的，有2个改法：
　　1. 让金鱼不继承于鱼：这不科学，金鱼本来就是鱼，除了口感，其它的继承都是有意义并且需要使用的。
　　2. 提取一个公共父类：
　　abstract class 鱼 {
　　private int 价格;
　　public int get价格(){ return 价格; }
　　public virtual int get口感() { throw new Exception(＂无意义＂) }
　　public abstract string get名字();
　　}
　　abstract class 可以吃的鱼 : 鱼 {
　　private int 口感;
　　public override int get口感() { return 口感; }
　　}
　　class 鲤鱼: 可以吃的鱼 {
　　public override string get名字() {
　　return ＂鲤鱼＂;
　　}
　　}
　　class 桂鱼: 可以吃的鱼 {
　　public override string get名字() {
　　return ＂桂鱼＂;
　　}
　　}
　　class 金鱼: 鱼 {
　　public override string get名字() {
　　return ＂金鱼＂;
　　}
　　}
　　仔细研究，你会发现网上很多代码，它定义了一个抽象类，并且名字是 XXXBase, XXXCore 或者一个类XXX还定义了一个类叫 XXXImpl 。这些抽象类就像上例中可以吃的鱼这个类一样，都是为了继承而存在的。这里，我们同样有这个问题：
　　父类的设计会因为需求和子类的增加和不得不作一些修改(如提取另外一个公共父类)。因此面向对象的代码经常需要重构和重写。这就是面向对象中的又一个设计陷阱。
　　总结一下上面的2个例子，就是：需求增加，代码就要重构。所以很多人认为这是一个只能靠经验才能解决的问题，只要写的代码够多了，就能预感到未来的需求并减少重构量。就像上例中，我们有经验就会先写好一个可以吃的鱼这个类。但这终究是一个幻想，没有谁能真正预知到未来的需求。很多作者都喜欢预留一个XXX接口，然后写了一个XXXImpl的实现类，认为以后只写另外一个XXXImpl2类，就可以重用处理XXX接口时的所有代码。其实以后需要写另外一个XXXImpl2类的概率几乎为0 。这样反而让修改XXX接口的成本上升不少。
　　需求决定设计，需求变化会导致不断重新设计。这就是面向对象的最大设计陷阱。