OOP思想與設計

 OOP——物件導向程式設計。 OOP思想，則是指物件導向本身的思想理念。而OOP設計，並不是指將程式碼均封裝成類別就可以了。因為，如果那樣，那僅是指物件導向程式設計。

        OOP－物件導向編程，只是一種做法。 OOP思想才是根本。重要的不是做法，而是實際要達成的目標。

        JAVA語言總是能絕大部分達成物件導向的目標。原因相當簡單。那是因為語言本身的限制。

        JAVA的一切都需要在類別中。不允許類別外部的單獨的函數。設計模式，即是因為JAVA的產生才有的。從這一點說，JAVA改變了軟體世界的想法。

        OOP的目標，是要讓程式碼符合SOLID原則。這些原則，在所有講解設計模式的著作的開篇均會被介紹。

        但這是理論目標。實際的目標，則是要回答，我們為什麼要這麼做。因為，我們對未來總是未知的。我們不清楚需求會發生什麼變化。我們今天或許在有限時間內只能提供一個簡易的版本。但日後肯定要擴展。我們所做的或許在今天已經涵蓋了一切，但有一天，我們會發現，還有一個部件，沒有被考慮進去。

        如果沒有物件導向，那麼，我們用最簡單的switch case結構已經完成了。正因為如此，我們不得不重新修改我們的核心程式碼。但是，如果我們的程式碼符合SOLID原則，那麼，我們要做的，無非是為現有程式碼增加一個新的CLASS。

        不難發現：插件思想，源自OOP。那麼，此時如果我們再看OOP，那不僅是將散亂的程式碼封裝成類別的問題了。

        我們需要遵循SOLOD原則，明確何為抽象，何為具體。我們雖只提供有限的針對具體問題的程式碼，但它們全部依賴整體的抽象。再有同類新的具體問題，我們就是只要增加類別。這是設計模式思想的核心。

        OOP設計，遠非如此。程式碼可讀性，可維護性，還在於目錄於文件中。表面上，這都不是重要的細節。但實際是極為重要的。特別是針對某一問題的核心模組的設計，或者，設計一個PHP開發框架。目錄的可讀性，或是否符合OOP，則很大程度上決定了人們對它的理解的速度，以及願意接受的程度。例如SYSMFONY的目錄結構就不是很好。儘管是老牌的，早期佔領市場較大。但仍被一些新的框架所瓜分市場。回過頭來，那些程式碼設計得並不是相當優秀的，例如KOHANA，CI卻相當容易被人接受，關於也是與它的目錄結構有關。這也是國內一些框架能夠被使用者接受的原因。並不是單一的因為，它是中文版的。

        由此可見，OOP設計的思想，不只是在程式碼方面，而是架構，設計的全方位。

        Php框架的問題，絕大多數是因為，開源的系統，沒有真正經歷過超大專案的有足夠經驗的人作為架構師。這是相當情有可原的。但是，如果一個企業做開源，運作多年後，系統越做越大，則越做越複雜，而不能夠有一個明確的易於上手易於維護的架構，則是一種悲哀。

        有人說，這些企業可以利用這一點，針對那些需要進行二次開發的顧客賺錢。其實，賺這樣的錢，永遠是有限的。因為，一個好的核心架構，將會帶來真正的軟體產業化。並且會節省大量成本。

        其實，把話說回來，發展框架實際上是相當的簡單的東西。簡單到可以用一兩句話來概括：一是提供不同的類別庫供使用者調用，讓使用者少寫程式碼。二是讓使用者輕鬆增加自己需要的插件，減輕使用者的開發。這實際上是相互呼叫的關係系統。 MVC系統中，純OOP的框架，後者就是框架呼叫使用者的程式碼。而這一方面，最為突出的即是使用者介面元件。 PHP在大量的這一類的框架。但都是非常的初級。沒有一個能與JAVA中的FCS，或TYPESTRY相比的。甚致一些初學者還能發布一個200KB不到的標籤引擎。程式碼不用看，就可以想像得出來，絕對不會有設計模式，更不可能遵循SOLID原則。那麼，擴展，維護都將是相當大的問題。

        於是我們想到，以及有多少網路企業，他們的網站是PHP的，表面上來看，PHP似乎會降低成本，但能降低到多少？關鍵還是在於從OOP程式碼到OOP架構，OOP架構的層次，決定了技術部門開發的效率與成本。