冒号和他的学生们（连载27）——接口服务

冒号和他的学生们（连载27）——接口服务2011-07-03 BlogJava 郑晖27．接口服务

律己宜严，待人宜宽 ——《洪应明·菜根谭》

叹号幡然反省：“以前我们做OOP编程时，总是专注于如何利用其他类来解决问题，而较少考虑自己设计的类对其他类的影响。”

引号翻开以前的笔记：“前面提过，OOP的世界是民主制的，所有对象都是独立而平等的公民，有权利寻求服务，也有义务提供服务。看来我们是光惦着权利而忘了义务了。”

冒号继而提出：“作为服务的提供者，最重要的是讲诚信。首先，服务要有可靠性，不能阳奉阴违——即接口必须履行它的承诺；其次，服务要有稳定性，不能朝令夕改——即接口一经公开，不得随意变更。”

句号迅即领悟：“从抽象的角度看，服务的可靠性保证了规范抽象，服务的稳定性保证了数据抽象。”

“孺子可教也！”冒号喜赞道，“相比而言，前者更为重要，但遗憾的是，只有后者才有法律保障——如果接口被废弃或其签名发生变化，固然会牵连客户，至少还可通过编译器来发现和修改；而规范只是语义上的契约，没有语法上的约束，不在编译器的监管范围之内。”

引号插言：“编译器管不着，那只有靠单元测试了。”

“这正是单元测试的主要目的。”冒号很认同，“此外，高质量的服务还要有纯粹性和完备性。Unix有一个哲学：‘一个程序只做一件事，但要做好’。用在OOP上，则是：‘一个类只提供一套服务，但要完善’。譬如，同为手机，老式的大哥大提供的服务是纯粹的，现代的智能手机则不是——除了打电话，还能摄像、听音乐、打游戏、上网等等，完全是手机与掌上电脑的结合体。又如，同为通讯工具，手机提供的服务是完备的，而BP机提供的服务是不完备的——只能接收信息，不能发送信息。”

叹号摇头晃脑：“提供的服务过多则不纯粹，过少则不完备。如此设计出的类是不是要达到‘增一分则肥，减一分则瘦’的美人标准啊？”

“编程毕竟是门实践活儿，完美无缺的设计如梦中佳人，可以追求却难以企及。”冒号笑了笑，“其实关键不在于服务数量的多寡，而在于服务的一致性和关联性。连贯一致的服务是良好的抽象与封装的结果，同时也是‘高聚合、低耦合’的保证。”

“作一个服务的提供者真不容易啊。”问号叹道，“那么，作为服务的享受者有什么讲究吗？”

逗号鼻腔里发出共鸣声：“哈，享受服务还需要讲究吗？”

“当然有。”冒号断然道，“作为服务的享受者，最重要的是讲规矩。享受人家的服务，自然得按人家的规则，否则服务将得不到保障。比如，你可以在超市的货架上任意选取商品，但不能偷偷溜进货舱去取。”

逗号辩道：“可货舱想进也进不去啊。正如合适的封装，是禁止客人进入私有接口的。”

冒号作一引喻：“我们不妨这么假设，货舱的正门挂着‘非工作人员莫入’的牌子。但是你偶然发现，通往洗手间的过道尽头正好是货舱的后门，既没有上锁，也没有挂牌。请问你会不会大摇大摆地走进去？”

逗号哑口无言。

冒号循循善诱：“超市的工作人员也许不该为图方便而开放后门，但那是管理者的事，作为客户显然不应乘虚而入。商品从货舱到货架之前可能会有装箱、拆箱、条码打印、条码扫描等操作，客户直接从货舱拿货无疑将破坏这种程序，于人于己皆无益处。同样地，作为他人代码的客户，就应按他人所设计的方式去重用，如此才能保证预期的效果。至于他人代码是否有效杜绝了一切可能的漏洞，那是监管软件质量的负责人的职责。”

引号表示理解：“这就好比客户购买了一款产品，却不按使用说明书进行操作，由此而引起的一切后果，厂家概不负责。”

“就是这个理儿。”冒号轻锤桌面，“当然事物是一分为二的。生活中有一个司空见惯的现象：许多行人跨越护栏、横穿马路。一方面，行人应该遵守交通规则，不应破坏道路的‘封装性’。另一方面，有些交通设计者没有‘以人为本’的客户意识，为行人提供的斑马线、天桥或隧道之间相距过远。从客观上说，不够完备的服务是导致行人违规的一大诱因。”