關於面向對象編程的一點思考

面向對象編程的對象有兩種，第一種是現實世界中的對象在軟件中的表示（暗含了類間的一部分關係，如包含等），另一種是爲了表示現實世界中對象之間相互作用而虛構起來的類（暗含了類間的另一部分關係，如協作等）。面向對象的思維有兩種突出表現形式，第一種是專注於對象本身的活動，儘量讓對象本身的活動限制在自身，當然那些本來就需要其他對象協助的工作是決不能讓一個類自身完全負責的，這種表現形式得到的是高內聚、低內聚性；第二種表現形式是面向契約編程，在第一種表現形式中還要求不能只關注於某個具體類本身的活動，需要的是進行抽象，把那些公共的東西都抽離出來，放到上一層類中作爲契約，而讓後繼的類實現這些契約，或加入一些更加具體的契約讓其後繼的類實現，解決一般性的問題總是比解決某個具體問題更容易。面向契約編程中，許多動作都在高層完成，可以避免爲許多低層類做同樣的操作。理解了面向契約編程後，不管是JAVA中的接口、C++中的虛基類或模板，使用的原則都是一樣的，最重要（但也最難）的事情就是建立合適的契約（抽象的本質）。
面向對象的方式在短期內是看不到好處的，甚至還會使實現功能的時間變長（實際中許多項目有的時候實現功能是優先級最高的事情），這是因爲各個類自成一體，需要維護他們之間的交互，另外爲了維護契約，需要做大量與功能無關的工作，並且如果事先沒有做好抽象，契約建立得不合適，後面往往面臨着改動契約，改動契約的傷害是巨大的，這意味着依賴於這些契約的實際操作很可能需要變化。另一方面，就算是在高層對對象進行操作，但是每一個操作的實際步驟還是需要一行代碼一行代碼地敲出來。基於這兩方面的考慮，所以面向對象的編程方式短期內不會得到好處。但是從長遠的角度來看呢，假設契約建立是合適的，許多可以共享的功能都已經以合適的類實現，那麼複用就會變得容易很多，可以直接複用或寫一個外覆類或Adapter之類的東西就夠了，應對新添加的特殊情況也容易許多，寫一個針對這種特殊情況的子類就好了，修改很小，編譯變得更快。
面向對象編程的方式是一把雙刃劍，好的抽象可以節省工程的整體時間，不好的抽象會更加浪費工程的時間。還有就是基於契約的編程方式意味着按規矩辦事，所以到了後期有的操作不得不在很彆扭的方式下實現，比如，本來有一個可以直接利用的類，但是爲了符合契約，卻不得不多寫一個外覆類或Adapter等。好的抽象來源於好的需求分析，好的需求分析不是具體而完備的，而是對高層的，具有重大影響的那些需求的全面分析。好的需求分析只能經驗中得來——從自己的經驗和別人的——除此之外別無他法。