最近又看了一下java基礎，看到面向對象的內容，繼承像是模仿了自然界的繁衍。

　　提出來這種思想就是為了讓編碼更簡單，從適應計算機的思考更多向適應人的思考方式轉變。現在代碼中的那些類文件都有在去實現面向對象，編程的布局和架構仍然偏向面向過程，有些繁瑣。

　　框架裏需要記憶的內容很多，而且不能很好的用一條邏輯貫穿起來，都是因為有什麽樣的需要所以要怎麽去處理。這樣框架用起來其實也是比較頭痛的事情，很多東西都需要一直記著。一段時間不用，再回來找的話也需要時間去熟悉。也就是框架繞的彎比較多，邏輯比較繞。

　　首先自己對面向對象的理解就是，站在對象的角度上觀察思考問題。編碼的時候對於一個類，不該知道的不讓它知道。每一個類都有明確的職責劃分，功能不重復。就顯得比較解耦，而且出問題的時候也比較容易找到相應的類。

　　在做軟件架構的時候，可以把整改項目看成一個公司。這個公司有多個部門，每一個類都是一個人。梳理工作流程和分配職責的時候，就把這個項目看成一個服務公司的運營，需要有那些部門，安置哪些人，哪些人需要做些什麽。

　　每當進來一個訪問就是一個客戶。這個客戶走到前臺，如何提供好的前臺；前臺記錄好服務後交給後邊處理，如何提供一個好的公司內部環境；內部再像裏邊有數據庫部門，根據客戶和公司的實際要求分配這個部門的占地和裏邊數據的安排情況。

　　每一個軟件裏的問題，當把軟件映射成一個公司之後，發現在“公司”角度下都已經有很好的處理方式，即使還沒有的，由於直接是對人和人之間的處理，所以思考問題也是直接用人的思考方式就可以，不需要再理會計算機的思考方式。也就是不需要理會過程中需要怎樣去周轉才能實現那些功能，只要都映射成人，需要做什麽，數據需要空多少，再有新功能的時候怎麽分配都顯得很直白。

　　可以想象成每個網站或者界面操作都是有一個服務員的，這個服務員告訴你改填哪裏，要做什麽選擇，需要等待多久，等一些列的問題。當網站需要新功能的時候就是告訴這個服務員需要多做些什麽事，去掉一些功能的時候就是告訴這個服務員什麽業務不做了。公司中部或者後部也做相應的人員和職責調整，使得業務繼續運行。這樣，每一個功能的增加或者變遷，都可以很容易整理通思路，然後映射到實際代碼上。對於整個軟件的架構來說，清晰容易了很多。

　　架構本身的目的是讓團隊裏每個人都可以專註做自己擅長的那部分，前端的就只前端，中部的就只中部，數據庫的就看好數據庫。垮“部分”做事是比較頭痛的，像java代碼和sql代碼之間的切換、和html和js的切換，因為涉及到不同的邏輯，所以從代碼層統一處理起來是很頭痛的事情（特別是要考慮一些深層次問題的時候）。於是做好了代碼軟件到現實公司的映射，就可以很容易鋪展開各層間的思考，都用同一種邏輯連通好了之後，再彼此轉化成相應的代碼邏輯就可以了。

　　這樣比較容易看清大局和一些涉及跨域的處理。

　　網頁是平鋪給人的，單純地像一張紙讓人填。架構的時候想象成是一個服務員在旁邊引導客戶填寫這張紙，只是服務員沒有顯示到屏幕上而已。這個看似簡單其實很重要，而且真去抽象那個空間的時候是需要一定想象力的，把所有的過程都通過服務員對接好。只不過最後顯示出來的事一張紙，背後的思考是一個迎接客戶的服務員。

　　這樣想可以比較容易把功能找全，比較容易貫通軟件需求和各個環節的配合、分工。最重要的事，抽象成人後，不管是增加還是刪除一些功能，都可以很少的實現，因為它順從人的自然思考方式，它的思考空間是人最熟悉的“人和人的交互空間”。不再是解決計算機問題，是解決兩個人之間的、一個公司各部門之間的協作問題。

　　希望路過的架構師或者編程人員有留意著去做份嘗試，這是一個很有趣的建模方式。

面向對象的架構