個人從寫Cobol出身，C,VB,C++,Java,PHP都碰過一些，但我從碰Java後就變成是OO的喜好者，因為它具有的一些特性，使得在系統設計與未來擴充性，感覺上更加靈活。但個人碰到的瓶頸是
(1)我有沒有足夠的business knowledge去，把作業流程給OO與模組化。
(2)design pattern能力不足，我所弄出的架構是不是有效率的(不敢奢求"最"有效率)。
所以我認為其實系統最加的擴充性與彈性，還是在"人"！

OO不是萬能
如果客戶要求的修改, 必須修改 Object 或擴充原有 Object , 影響可大可小
不過 OO 是潮流

對於已經是用循序型軟體開發完成的案子, 要改成 OO, 要考慮花費的人力和時間

您問的是一個概念的問題，所以、我以概括性的說明方式來回答您！
物件導向、究其原理就是以模組與功能性導向來成就程式！
所以若能依其既有之規則來去設計與使用、他就有點像是在拼接立體拼圖一樣，而參數就是連通立體拼圖內部的管線似的、使數據可以在拼接的過程中能有序與正確的傳遞下去。
如果系統分析做的好、您可以在不同的位置設下連結點（或嵌入點），這時候當需求產生小改變就取出小圖塊更換，若是大變更則又連結點將大型區塊給斷開來、前或是後在嵌入其他模組與物件或版塊來完成，好比：把「賽車」的「光頭胎」在下雨時馬上更換「雨胎」，賽車是主體、光頭胎與雨胎就是物件中的一環！
為了比較容易瞭解、所以我用拼圖與輪胎做比喻，當然物件導向的程式設計絕對不像拼圖那麼容易作業與解釋，其深入研究之處還是很多的、但就是比較方便與人性化才會取得現在超過半邊天！您有興趣是可以深入的！
但是別忘了、物件導向也有用產生器來設計與規劃，所以若是切割點（連結點、嵌入點）、沒規劃好，資料沒有註記完整，當要局部修改時是會有一些難度的！提醒您注意！

這要看你怎麼設計OO.OO設計的正確,當然變動機會小.如果你隨便拆(猜)的話.怎麼設計都一樣

架構設計得彈性不好, 面對未來的新需求, 就會遇到牽一髮動全身、大幅修改的問題. 物件導向設計要有彈性, 建議應大量使用design pattern. 這與您提到的物件導向方法本身或瀑布式開發流程, 並沒有直接關連.

除非你有X光電眼, 可以看透一切物件, 因此物件導向的的設計重點是介面. 如果是Java, 那就是interface囉.
設計上要用interface來思考.擴充的彈性也更大, 而採用何種軟體工程是在於人力資源與專案資源的分配.

另外, 瞎子摸象的故事是很有啟發性的, 重點是要徹底了解要解決的問題, 要充實Domain Knowledge才能從問題
中找出"物件", 這與模組化與功能沒啥直接關聯, 不然一頭大象被瞎子分成好幾個模組後, 如何組成原來的大象?
這是國內用物件導向的一個重大誤解, 模組化與功能導向頂多是一個物件導向的邊際利益罷了.

Object-oriented 方便經常需要修改，易於維護；如果是為了快速擴充，那應該朝 Object-based 方向設計，可以利用 3rd Party 的 Domain / Know-how 與專業；對於一次性程式，Procedure / function 會是比較快的開發方式