从地铁闪灯看抽象与稳定性

首先程序属于渐进编程，你永远无法知道你现在做的事情将来会变成怎样。这不同于建筑。你就在自己的一亩三分地上面造房子，住宅，只局限于睡觉、用餐、看电视，当然，你也可以有游泳池，但总体上，它是可预测的。你可以把你所有想做的事情收罗到一块，整理计划，慢慢把图纸画出来。程序确是个多变的世界。你都不知道你做的东西下个月会变成什么。整体规划就成了一种费力不讨好的事情。我们只能务实的实现一小个任务，然后以后的事情再去慢慢分析、考虑。既然未知可以以后考虑，那么我们当前需求也可以分割成若干个小任务，逐一抽象叠加实现。我们不要去考虑整体把握了，因为永远把握不住。（渐进性编程思维）

任何一个功能都是从一个看似主要的功能出发开始思考的。我们想就地铁闪灯做一个控制程序。首先我们确定我们要做什么？无非告诉坐地铁的人，我们在那里。简单来说，就是做个接口实现设置当前站点的功能。

function setStation($station){};

设置站点怎么弄呢？把设置站点的灯点亮，把它还没去过的前面的站点点亮。那么，我们这里就需要一个站点的列表，以及一个站点和灯的对应关系。为了更好的组织，采用了class

class Station

{

static $stationLigntMap = array(“上地”=>1, “西二旗”=>2， “”龙泽=>3);

public static function setStation($station){//实现根据列表显示本站和未来站的逻辑代码-循环调用：Light::set};

}

我们需要控制灯的状态，所有有setLight(灯编号，状态（亮或者不亮）);当然，这里用clss

class Light

{

public static function set($lightId,$status){};

}

我们切换站的时候只需要出发调用Station::setStation(“上地”)就好了

通过以上代码我们就实现了上面的要求。

有一天，我们需要加入快到站闪烁的功能。我们只需要添加一个正在去往某站的接口

class Station

{

static $stationLigntMap = array(“上地”=>1, “西二旗”=>2， “”龙泽=>3);

public static function goingTo($station){}

public static function setStation($station){//实现根据列表显示本站和未来站的逻辑代码-循环调用：Light::set};

}

然后再Light里面加入闪烁的status的新状态，便好了

突然发现，setStation是很2的命名方式，很程序化，应该是到了某站，改为Station::arrival($station),Station::goingTo($station),Light::set(1, ‘flicker’)（闪烁）

仔细体会，应该会从中发现面向对象和抽象给我们带来的好处。

我们这里再来探讨下，这里的变化和抽象元素的稳定性。这里面最稳定的，无非是站点这个概念，和灯这个概念，我们一般认为在整个亮灯系统中，这两个概念都会永垂不朽，我们把特别稳定的做成类，到站和运行中这两个也相对稳定的。站点有可能变，比如说某一站没开通，灯设置显示状态比较稳定，我们把状态做成一个参数，来提高它的可扩展性。

总体看来，稳定度和类、函数、参数，内部分装是线性关系的，我们尽量把所有不稳定的封装起来，使变化带来的改变最小。这个的根本是业务抽象。