上週修改乙個bug，本來以為只需要做一些小調整就可以，後來還是發現由於受物件間的狀態影響，出現了另乙個錯誤。這也讓我進一步思考對於系統設計和建模來說：物件導向是錯誤的，會帶來後期的很多問題。
在物件導向的設計中，系統是由物件和讓物件狀態發生改變的方法，讓物件到達另一種狀態來達到目的的。當系統漸漸變大，物件漸漸變多，每個物件間的糾纏越來越多的時候乙個物件的狀態受到多個控制訊號的機會就越來越多，作為狀態的使用者，你越來越無法判斷你所用物件的狀態——時常由於外部改動讓狀態發生的改變，你的程式設計假設也就失敗。這通常會造成bug的產生，而且很難定位和修復這樣的bug。
從**的觀點來說，操作物件的**和物件結合的太緊密，你復用的機會會越來越少，物件上的方法是針對這個物件的特化方法，你很難加以利用。所謂的高內聚讓你對於已有的方法只能看，而不能用，相信對於維護**的同學特別有這樣的感覺：你的需求基本上另乙個物件已經滿足了80%的功能，或者你想剝離其中某個方法，會發現根本沒有辦法撥出來，這個方法跟物件緊密的結合在了一起。
對於維護除錯來說，你會發現當系統出現問題時候，你很難改變物件上的方法，很多時候看似有問題的方法對於這個特定的物件來說居然是正確的，前提是有很多setup讓物件處理這樣的狀態。在除錯的時候好像一些幾何相關的謎題，你移動了乙個角度，以為這樣就能通過，其實移動帶來的***讓你無法通過。
系統的設計還是要採用函式式的結構，把系統看做乙個資料轉換器(transform)，而不是狀態修改器(modification)。輸入點上，資料是已經求值後的不可變(immmutable)值，經由資料變換，資料的二次變換，資料的三次變換(可能是要呈現的記過)，比如輸出html。系統更多的像是一些管道相連的一大堆通用資料處理器。
當系統出現問題時，你可以檢查輸入/輸出，或者直接模擬輸入/輸出來診斷問題。這個有點像是維修模組化的電子元件，方法通常有兩個：
你如果觀察維修小工，你會發現他會在這兩個方法見頻繁轉換。
由於是同用資料結構和通用資料處理，這讓復用變的可以**（predict），如果輸入和輸出可以達到你的需求，那麼這個函式你就可以拿來使用。好像維修小工，並不在意某個電容是哪個生產商生產的一樣，達到要求就能用。
函式式架構的重點在於連線而構成的系統。通用的元件(資料結構)加上通用的變換(函式)，而不是由乙個個定製的物件(型別例項)而組成的，這樣的系統很脆弱，壞了你沒有辦法維修和更換——因為都是定製的。
總結下來，當系統變得複雜以後，通過狀態變化帶來的***讓系統變得脆弱和無法維護，而函式是的資料加通用處理機制會讓系統工作的更好。
首發:
物件導向 初識物件導向
面向過程思想 步驟清晰簡單，第一步做什麼，第二步做什麼.面向過程適合處理一些較為簡單的問題 物件導向思想 物以類聚，分類的思維模式，思考問題首先會解決問題需要分哪些類，然後對這些類進行單獨思考，最後才是對某個分類下的細節進行面向過程的思索 物件導向適合處理複雜的問題，適合處理需要多人協作的問題 對於...
學習物件導向之物件導向的術語
類類作為設計藍圖來建立物件的 段，它描述了物件的特徵 該物件具有什麼樣的屬性，怎樣使用物件完成一些任務，他對事件進行怎樣的響應等！物件物件是類的乙個例項，通常通過呼叫類的乙個建構函式來建立它！方法方法是在類中定義的函式，一般而言，乙個方法描述了物件可以執行的乙個操作www.cppcns.com！屬性...
物件導向 物件的組合
組合 乙個類的例項可以當做引數傳給另乙個類的例項 class school def init self,name,address self.name name self.address address class course def init self,name,price,outline,sch...