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

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