物件導向，經常聽，但卻不經常做。或者說想做，但沒有做吧！某構架師和我說，中國百分之90%的程式設計師都在講著物件導向，卻有80%的人寫著面向過程的**，我覺得不是面向過程，是面向模組，其實面向模組如果寫得好的話，應該也不錯的！只不過大家所寫的面向模組只能自己用（大部分），所以根本就得不到重用.
物件導向最終想解決的問題就是**重用，應變業務經常變動(非常小的專案且業務不經常變動例外）。其實對物件導向的理解，我也不深刻，算是一知半解而以吧，要是只是說三大特性（封裝,繼承,多型）的話，我想大部分程式設計師都知道，但我覺得只會用，沒什麼用。主要是思想，在寫**的時候要有那種意識。
一般我們在分析的時候，都會想，這個系統有什麼功能，我們應該做什麼。這個「有什麼功能」就是乙個用例，用例就是描述一件事，比如說借書，應該先做什麼，再做什麼。大概是這樣「借書人員應該先到圖書管，出示借書證，圖書管理員檢驗借書證，再查詢借書人員所要借的書，交給借書人員」，這就是乙個完整的用例。一般我們會想，先是怎麼樣再是怎麼樣。對，分析用例的時候大家都是這樣，也應該是這樣。這使大多數人往往很容易深陷下去，寫**的時候，也是這樣想了，這樣就成了面向過程的程式設計了。
用例確實要寫（畫）出來，系統分析人員可以根據使用者，得到系統的一些物件，比如（借書人員，圖書管理員）這些物件，他們能做什麼事（行為），物件裡面就包含他們的行為，然後在業務層裡，比如說借書這個業務，再集合起這些物件的一些行為，就變成了業務層（應該是業務外觀層）只是一些行為的集合，沒有具體的實現，具體的實現都應包含在物件的行為裡面。這樣的話，如果是業務有變動的話，大部分情況下我只是修改一些業務外觀層借書業務裡面的一些物件的行為呼叫，當然一般的業務修改除了要改變業務層之外，物件的裡面的行為也會有修改但很少影響到多個物件的關聯即使是有，問題也不大，最起碼這些全都是分開的，容易理解。其實看上去好像「面向模組」也是這樣一回事，但用面向模組的話具體的實現（物件的行為）存放的位置會顯得很亂(在我目前的公司我是這樣感覺的），如果是使用面向過程，給我的感覺所有的東西都是整合在一起 了，想修改很麻煩，因為很難把握所有**（超過一定的行數就容易出錯，越多行的**越容易出錯），相反物件導向不同，因為你在寫物件的時候，你不知他會在**用到他這個行為，所以你只要關心當前這個物件的行為是否正確就行了！比如上面提到的借書業務，使用面向過程的話，你要顧慮到的**是整個用例，但如果使用物件導向的話，你只要考慮其中的一小部分（可能是管理員查詢借書人員要借的書），這一小部分的**絕對是比整個借書流程的**少的！所以出錯的機會也就小很多。
看了上面，我覺得寫得挺亂的（文采不好，請見諒），可能您不知我在寫什麼感覺是東一句西一句的，其實我想表達就只是說，業務層裡主要的只是物件的一些行為的集合而以;
上面純屬個人見解，也可能我的見解是錯的，但起碼深思過有收穫，如果是錯的，請您提出來，謝謝！
一點小體會
最近一段時間3個工作周的封閉開發。比較累，也從原來的按時間工作改變為按量工作。工作量完不成得加班完成。在 這一塊體會比較多的 1 寫好注釋，不要太多，能表達清楚意思就行。2 在動手寫 之前，花時間想清楚自己的思路，以及自己準備在什麼地方做改動。要考慮周全，嚴謹，簡單。如果改動步數過多，該思考一下是否...
Session的一點體會
一直以來，沒有怎麼去好好研究session。只是大概知道用session來記錄會話狀態，知道瀏覽器關閉後session會丟失，知道伺服器端會記錄session，知道伺服器重啟有時會引起session丟失。僅此而以！後來發現的問題 一是如果用乙個瀏覽器不同的標籤卡來進行登入操作，那麼最後一次登入的會話...
一點管理的體會
績效考評體系不能太重型，網際網路專案要講究輕裝快跑，看重創新，看重措施落地，看重效率。所有的管理都不直接創造價值，相反還都要成本。所以管理要考慮投入產出比。比如，10人的團隊，因為一項管理活動每人每天需花15分鐘填表，人均月薪10000，那麼乙個月下來，成本 15 60 8 10000 10 312...