菜鸟回应，有错请各位大大指正。
※ 引述《hsnucsc (hsnugo)》之铭言：
: 3.物件化程度
: 在同个例子中, 狗叫声Bark, 有两种作法
: 一是String bark;
: 二是Bark bark; (后面还有barkList, 不过先简化一点问题)
: 如果用二, 就可以将吠声比较交给Bark, 后面即使修改Bark的比较方法
: 也只要不需动到声音辨识器或其他用到Bark的class
: 但是这是一个我困扰很久的问题
: 我怎么知道以后会不会修改?
: 如果我99%确定不会再修改, 那我直接用String bark, 程式的效率不是比较好
如果现阶段不知道以后会不会修改，那就不要花脑筋在这上面了，不
然你会发现你设计了一堆用不到的“弹性”。
以后修改了怎么办？若狗吠声突然要常常换来换去怎么办？
这就是你需要“重构(Refactoring)”的时候，而如何重构又是另一
个议题了....
SA需刚刚好，
以弹性为例，将80%可以快速过滤以及确认的弹性处理好，剩下20%你
烦恼该不该保留弹性的部分，你花了80%的时间去想或许仍旧无法得
到答案。在还没有面对外界复杂又多变的应用之前，你能做的，是在
“开发时间”与“程式弹性”之间做一个最佳的平衡。