其实 OO 还有一项特性就是 team work 上的便利，
每个 programmer 需要知道什么不需要知道什么都能分割得清清楚楚，
加上相关的 design pattern 带来的高应变性，
做得好的话改个规格要玩死你也是有一定难度，
要是规格变得太凶的话改用 XP + refactoring 跟它拼也要不了你的命，
就算是要改 interface 好了，
知道上头或客户老是会动到这边的话就把它再抽象化几层，
一样可以构筑出强大的应变能力来，
至于高度抽象化所造成的混乱说真的在这种环境下是不可避免的，
但是这总比复制贴上修改和乱插一堆 if else switch case 好得多了，
可称得上是诸多乱中有序技法中的王道。
早期 OOAD/OOSE 强调的是默认计，
想说这个做得好的话就能以不变应万变，
这当然是想得太美好而不切实际，
所以才会有新的方法论去描述如何做事后补救，
而这一切其实都还是在 OO 的范畴内施行，
但奇怪的是很多人一旦发现默认计不切实际后就开始提倡 OO 无用论，
真搞不清楚到底是学的人有问题还是教他的人有问题，
会被初学者一句“搞来搞去到最后还不是也要改”给撂倒的恐怕应该先充实自己再教人，
遗憾的是长年以来号称是 OO 专家却被这句话一击毙命的大有人在，
反而给了初学者击败权威自以为学的东西够了不用再进步了的错觉和偏执。
不能理解为什么要有这有那的一般都是以“整个程式都是自己一个人写”为前提在考虑，
把他们拖出这个小框框其实也是帮助他们进步的一个契机，
多让他们考虑写程式的时候如何为同事着想以及增加合作的效率，
大部分的初学者接受度还是不错的，
至少可以给他们一个为什么要学为什么要用的理由，
没有动机的话你强灌他们再多知识都没有用，
programmer 一向被套上一个自私自利不为人着想的成见并非空穴来风，
先让这些初学者在起点就摆脱这个魔咒才是最重要的事。
其实所有程式里难度最高最抽象的工作的就是设计 library，
因为这需要丰富的程式经验来规划 interface，
没有经过相当历练的人设计出来的 interface 总是自己觉得爽就好，
没想到就先不做有想到再加就好，
自己方便就行别人不方便管他去死，
任何初学者觉得没用的技术诸如 OO 概念甚至 C++ template metaprogramming，
一进入了 library 设计的范畴内马上就变得不可或缺，
原本不知道那些概念和技术是干什么用的只要一踏入这个领域马上就会豁然开朗，
想进这领域的基本上除了经验要老以外技术水准也要够，
不然设计出来的 library 很容易被人家说跟垃圾一样，
一般来说技术层次高的 programmer 讲话都不会太客气，
偏偏 library 的 user 就是 programmer 所以批评几乎都很毒，
经得起刺激的被呛个几十次几百次就会变得超强了，
这跟写 AP 被 end-user 讲不好用手感不顺功能太少的意义差很多。
有些人总是说用 OO 概念写程式很花时间，
但我认为这是他们不熟如何写出 OO 程式所造成的，
惯于撰写 OO 程式的人随便照直觉写都可以写得很 OO，
就像有经验的 C programmer 常跳过流程图就能写出结构完善的程式一样，
老练的 OO programmer 照样可以跳过 OOAD 直接写出一定水准的 OO 程式，
熟到这个地步的走 XP 这条路也已经没什么障碍了，
讲明白点就是有没有本事照直觉乱写都能写得很漂亮罢了，
而这种本事是可以靠时间和努力去训练出来的。
题外话，
对于不知道为什么需要 OO 的，
我都是建议他以多为别人着想为出发点去思考，
而不是直接跟他说 OO 能做这个做那个带来什么好处，
借此我不但可以观察出这人的资质也能观察出他一部份的人格，
虽然不能单就这方面就武断的说一个人是否有资质或人格如何，
但总是可以做为参考之一，
所谓的综合评价就是从各种零零星星的观察和试探得来的，
对于寻觅人才或决定重大工作该交给谁时还是有一定的帮助。