菜鳥回應，有錯請各位大大指正。
※ 引述《hsnucsc (hsnugo)》之銘言：
: 3.物件化程度
: 在同個例子中, 狗叫聲Bark, 有兩種作法
: 一是String bark;
: 二是Bark bark; (後面還有barkList, 不過先簡化一點問題)
: 如果用二, 就可以將吠聲比較交給Bark, 後面即使修改Bark的比較方法
: 也只要不需動到聲音辨識器或其他用到Bark的class
: 但是這是一個我困擾很久的問題
: 我怎麼知道以後會不會修改?
: 如果我99%確定不會再修改, 那我直接用String bark, 程式的效率不是比較好
如果現階段不知道以後會不會修改，那就不要花腦筋在這上面了，不
然你會發現你設計了一堆用不到的「彈性」。
以後修改了怎麼辦？若狗吠聲突然要常常換來換去怎麼辦？
這就是你需要「重構(Refactoring)」的時候，而如何重構又是另一
個議題了....
SA需剛剛好，
以彈性為例，將80%可以快速過濾以及確認的彈性處理好，剩下20%你
煩惱該不該保留彈性的部分，你花了80%的時間去想或許仍舊無法得
到答案。在還沒有面對外界複雜又多變的應用之前，你能做的，是在
「開發時間」與「程式彈性」之間做一個最佳的平衡。