關於物件導向程式設計的一點思考

　　物件導向程式設計的物件有兩種，第一種是現實世界中的物件在軟體中的表示（暗含了類間的一部分關係，如包含等），另一種是為了表示現實世界中物件之間相互作用而虛構起來的類（暗含了類間的另一部分關係，如協作等）。物件導向的思維有兩種突出表現形式，第一種是專注於物件本身的活動，儘量讓物件本身的活動限制在自身，當然那些本來就需要其他物件協助的工作是決不能讓一個類自身完全負責的，這種表現形式得到的是高內聚、低內聚性；第二種表現形式是面向契約程式設計，在第一種表現形式中還要求不能只關注於某個具體類本身的活動，需要的是進行抽象，把那些公共的東西都抽離出來，放到上一層類中作為契約，而讓後繼的類實現這些契約，或加入一些更加具體的契約讓其後繼的類實現，解決一般性的問題總是比解決某個具體問題更容易。面向契約程式設計中，許多動作都在高層完成，可以避免為許多低層類做同樣的操作。理解了面向契約程式設計後，不管是JAVA中的介面、C++中的虛基類或模板，使用的原則都是一樣的，最重要（但也最難）的事情就是建立合適的契約（抽象的本質）。

　　物件導向的方式在短期內是看不到好處的，甚至還會使實現功能的時間變長（實際中許多專案有的時候實現功能是優先順序最高的事情），這是因為各個類自成一體，需要維護他們之間的互動，另外為了維護契約，需要做大量與功能無關的工作，並且如果事先沒有做好抽象，契約建立得不合適，後面往往面臨著改動契約，改動契約的傷害是巨大的，這意味著依賴於這些契約的實際操作很可能需要變化。另一方面，就算是在高層對物件進行操作，但是每一個操作的實際步驟還是需要一行程式碼一行程式碼地敲出來。基於這兩方面的考慮，所以物件導向的程式設計方式短期內不會得到好處。但是從長遠的角度來看呢，假設契約建立是合適的，許多可以共享的功能都已經以合適的類實現，那麼複用就會變得容易很多，可以直接複用或寫一個外覆類或Adapter之類的東西就夠了，應對新新增的特殊情況也容易許多，寫一個針對這種特殊情況的子類就好了，修改很小，編譯變得更快。

　　物件導向程式設計的方式是一把雙刃劍，好的抽象可以節省工程的整體時間，不好的抽象會更加浪費工程的時間。還有就是基於契約的程式設計方式意味著按規矩辦事，所以到了後期有的操作不得不在很彆扭的方式下實現，比如，本來有一個可以直接利用的類，但是為了符合契約，卻不得不多寫一個外覆類或Adapter等。好的抽象來源於好的需求分析，好的需求分析不是具體而完備的，而是對高層的，具有重大影響的那些需求的全面分析。好的需求分析只能經驗中得來——從自己的經驗和別人的——除此之外別無他法。