其實 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 能做這個做那個帶來什麼好處，
藉此我不但可以觀察出這人的資質也能觀察出他一部份的人格，
雖然不能單就這方面就武斷的說一個人是否有資質或人格如何，
但總是可以做為參考之一，
所謂的綜合評價就是從各種零零星星的觀察和試探得來的，
對於尋覓人才或決定重大工作該交給誰時還是有一定的幫助。