第一次機房收費系統的時候，我們側重於功能的實現，對於大範圍的使用if...else，沒有太明顯的感覺。可當我們學完設計模式之後，才發現原來多次使用if...else，會使程式產生很高的耦合性，不便修改。對於同樣的下機內容，我們除了要用到七層的知識，可能最大的收穫就是去學習如何把設計模式運用到實踐中去了。
（1）含義：
使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將這個物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個物件處理它為止。（舉個栗子：加薪非要老總批）
（2）結構圖
（1）含義：
它定義了演算法家族，分別封裝起來，讓他們之間可以相互替換，此模式讓演算法的變化，不會影響到使用演算法的客戶。（舉個栗子：商場**）
（2）結構圖
職責鏈模式解決的主要問題是：確定消費時間屬於哪個時間段（t準備時間，準備時間《至少上機時間,t>至少上機時間）
策略模式解決的主要問題是：根據使用者型別確定使用的金額計算策略
one：在實踐過程中，對我來說最大的問題就是不知道引數傳哪些？
其實分析一下不難知道：
消費時間的確定（職責鏈模式）：
(1)上機時間和下機時間（也就是下機對應的實體）；
(2)準備時間和至少上機時間（基本資料設定的實體）
使用者型別的確定（策略模式）：
(1)固定使用者單位費用和臨時使用者單位費用（基本資料設定的實體）--確定金額計算策略
(2)消費時間（職責鏈模式求得）
two：消費時間微大於至少上機時間時，如何確定消費金額？
(1)之前--超過至少上機時間的部分按照上機分鐘數算，結果四捨五入。這樣做可能出現乙個問題：當分鐘數足夠小時，消費金額會被捨掉。
(2)針對上面乙個問題，我給程式設定了乙個最低消費金額，避開了上機不扣費的情況。
three：資料型別問題（避免資料型別不一致產生的問題）
(1)上機時間和下機時間都是「time」型別
(2)消費時間是「integer」型別
four：三種下機——觀察者模式
對於三種下機模式，我們也可以使用一種設計模式來是實現，那就是觀察者模式，具體為什麼，大家可以自己去思考。
下機——職責鏈模式+策略模式（實踐篇）
學習上遠離舒適區要求我們多實踐新學習的內容，不斷突破自己，不斷提高自己，讓自己可以越來越快的適應新知識的從理論到實踐的過程。
機房重構 上下機（職責鏈模式和策略模式）
機房重構中上機功能相對好實現一些，下機用到了職責鏈模式和策略模式，職責鏈模式算時間，策略模式算消費金額 部分 dal層 public class offdal ioffidal string sql select from card where cardno cardno datatable tab...
C 機房重構 下機（職責鏈模式）
職責鏈模式 職責鏈 當客戶提交乙個請求時，請求是沿著鏈傳遞，直至有乙個concretehandler物件負責處理，接收者和傳送者都滅有對方的明確資訊，且鏈中的物件自己也並不知道鏈的結構，僅需保持乙個指向其後繼者的引用。具體實現 在機房重構中職責鏈主要用於確定學生的消費時間，以下為具體的實現 抽象類p...
C 機房重構 下機之職責鏈模式
前言 說到設計模式，又熟悉又陌生，為什麼這麼說呢？熟悉是因為學過設計模式，明白了當時學習的例子 陌生是因為放到重構不會用，參考了很多部落格，才知道如何用這個職責鏈模式。內容 bll層 沒有設計準備時間，上機滿一分鐘即收費。public class chainbll public decimal co...