面向对象为何而死
参考文章：
  月薪7K的面试题---交通灯管理系统http://blog.csdn.net/zhangxiaoxiang/archive/2011/03/24/6273384.aspx#1636343
   
  这篇文章其实蛮老的，只是最近看到有关“面向对象即将死亡”的论调，心中有不平，就拿它来血祭一番。
   
  在这个简化的十字路口环境中，文中抽象出了道路、红绿灯两个对象类，并分别建立12个实例对象来模拟实际的状态。我没看完他的文章，因为看到这，我已被震到精分了。。。

  以红绿灯为例，当前通行路线上的红绿灯状态决定了此路线上的车辆能否通行，乍一看，绝对是一个重要的对象啊。但是，如果把问题换一种方式来描述就会发现另一个天地：“用红绿灯来表示当前交通管制系统中允许通行的路线”，很显然，“交通管制系统”才是隐藏在红绿灯背后真正需要被抽象出来的对象，红绿灯只是该对象中一个状态值的表达形式。
  再进一步思考，那么对于到达路口的汽车来说，是否需要获取这个“红绿灯”值来决定自己是否通过呢？如果需要，那至少需要建立表达红绿灯状态的一个公共结构来让汽车或其他对象理解交通管制系统的当前状态，但如果那样，我将亲手杀死面向对象。
  红绿灯只是“交通管制系统”的某个状态值的一种表达形式，而决定这个状态值的又是什么呢？显然，就是整个题目本身所描述的一套“游戏规则”。汽车能否通行，本质上不是红绿灯决定，而是这套规则决定的。规则是什么？在这里很简单，无非就是一系列的函数调用，最后返回一个True或者False的值来决定汽车能否通行。如此一来，在“交通管制系统”中设置一个方法（函数？子过程？随意。。。）即可，而方法中的检查规则嘛，就看交警们想怎样折腾了。

  对比文中的解决方法，现在，12个“红绿灯”对象实例已经被缩减为1个“交通管制系统”对象实例，与之类似的，12个道路对象实例也可以被简化为一个对象实例。最终，只需要两个Class，1个简单的数据结构、两个起辅助作用的枚举即可解决这个问题，而且最重要的通行规则被封装在一个独立的地方，可扩展性也得到了保证。

  想到法国DGM时期一句名言：正义而正义，多少罪恶假汝之手以行。想说一句：对象啊对象，多少不智假汝之名以行。如果某一天，面向对象真的死了，像这样滥用对象的人们，该不该去教堂忏悔一下自己的罪行呢？


------解决方案--------------------
对象不会死，因为对象是人类思维自然的处理单位
------解决方案--------------------
对象不会死