房間計費系統的改造已經開始了很長一段時間，隨著最近兩天感覺有點線索。
對這次重構。剛開始計畫的是先做資料庫，然後優化下，列出每乙個視窗對錶的訪問關係，抽出經常使用的訪問作為儲存過程，然後把訪問資料庫的經常用法封裝成sqlhelper.這部分就是資料庫的部分。
然後就是軟體的結構：總體上是分了七層：三層+實體+外觀+抽象工廠+d層介面。儘管計畫的非常好。可是在詳細分層這裡想了非常久。
最先是對d層開始下手的。d層是什麼？是對錶的訪問，將對資料庫的讀取和寫入都封裝成d層的類，那麼。類又依照什麼分呢？後來想了想曾經學習三層的時候做的7層的登陸視窗，那個時候，d層是依據表來的，將訪問每張表的方法總綜合寫成乙個類。
對於d層：基本是依照表來，將表抽象出乙個類或者幾個類，在每乙個類裡面，盡量讓全部的方法去訪問表中同樣的字段，也就是說。儘管d層主要依照表來，可是也用功能去輔助分類，比方，對於訪問兩張表的情況。就將這種方法依據功能放在相似與他功能實現上有聯絡的類中。
做完d層之後，向上到了介面層，才發現慘了。事實上我應該先做介面的。由於d層是用來實現介面層的，而不是介面層依據d層出現的。也就是說。程式設計要面向介面。唉。當時怎麼就沒想起來呢？
接著做的是實體層。實體層是做什麼的呢？先想想我們曾經程式中是怎樣傳遞資料的：我們比方。我們註冊乙個學生。這個學生可能寫到學生資訊表裡面有十幾條欄位值要寫進去，傳遞過程中在程式內部寫這麼多的值是非常easy丟掉一兩個的，有了實體層。我們能夠非常好的發揮封裝的作用，將全部資料打包傳遞。就像給你寄個快遞一樣，不管多大還是多小，都給你打個包，不至於丟失什麼東西。
對於抽象工廠，延續抽象工廠+反射+配置檔案的高大上的做法，返回介面，後來寫**的時候，發現修改起來果然很easy。當我修改d層的時候，上面的東西根本不用動。
接著是b層。對於b層。它接收從u層過來的資料，向下送到d層進行處理，並將d層返回的資料放在這裡進行推斷和處理，並將結果返回給u層。可是它是怎樣進行分類的，這個問題想了好久。看大家部落格和當面交流，大家都大致是這樣做的：1，依照u層視窗來。2。依照用例來；。。。。事實上我是比較看好依照用例來的。由於假設u層有非常多視窗的話，會造成b層類過多。
可是依照用例來也是有問題的，假設我新增功能，就要去修改類。
好像怎麼著都不完美。後來。想到設計模式上說的一句話：不論什麼需求的變動都是須要成本的。我認為如今這個階段我還是選擇一種方法做下去比較好，假設實現的過程中。發現了更好的方法，能夠再去修改。
對於外觀層。是對b層的進一步抽象，這次做到最後的時候，去掉了外觀層，由於感覺這個系統太小了。b層的抽象程度已經相當高了，加了外觀層就是冗餘 了。
這樣。僅僅剩下最後的u層。它僅僅用來實現主要的輸入輸出就能夠了。
解耦完成~~~~
HTTPS的層次結構和防範物件
http固然足夠好，但是在安全方面有著很大隱患 1 與伺服器進行通訊使用的是明文，內容可能會被竊聽 http協議本身並不具備加密功能，所以無法對請求和響應的內容進行加密 2 使用http協議的伺服器與客戶端都不會驗證通訊方的身份，可能遭遇偽裝。所謂不驗證通訊方身份的意思是，比如說服務端，在服務端接收...
物件導向和基於物件的區別
很多人沒有區分 物件導向 和 基於物件 兩個不同的概念。物件導向的三大特點 封裝，繼承，多型 卻一不可。通常 基於物件 是使用物件，但是無法利用 現有的物件模板產生新的物件型別，繼而產生新的物件，也就是說 基於物件 沒有繼承的特點。而 多型 表示為父類型別的子類物件例項，沒有了繼承的概念也 就無從談...
物件導向和基於物件的區別
以我現在的認知，只是知道的是vb是基於物件的程式語言 c 是物件導向的程式語言。那我們如何區分什麼是基於物件，什麼是物件導向？根據上述的兩種程式語言我們就可以知道 物件導向 和 基於物件 是兩個不同的概念了吧！基於物件是使用物件，意味著它們有像c 的結構加函式這樣的物件，然而這只是到達物件導向語言的...