在平時的工作中，我們總是能看到以下類似的程式碼。比如一個簡單的表單檢測功能，分別對各個程式碼模組進行檢測，也清晰明瞭。但卻在不知不覺中建立了很多全域性變數，而且存在被團隊中的小朋友覆蓋的風險，接下來看看如何進行小小的改動
行為程式碼
單例模式：即對某一類屬性和方法進行統一的封裝，達到井然有序的模式。
我們只需要將這類檢測表單功能的程式碼都收集到一個變數中，統一對外暴露，只需要知道這個變數就可以透過點語法得到自己想要的方法，而不需要記住那麼多的方法名稱。修改程式碼如下
複製到一個變數中
使用就如下面所示，但發現Check被使用的好幾遍，還能不能接著最佳化呢？
依次呼叫
透過觀察，我們會發現他們都被封裝到一個變數中，那this是不是都指向同一個變數呢？我們可以在每一個方法中返回this，修改如下
返回this
測試呼叫是
鏈式呼叫
此時的程式碼不僅井井有條，呼叫也能鏈式呼叫。
到此，我們來思考一個問題？這到家都呼叫同一個變數，如果有人重寫了某一個變數裡面的方法檢查規整，是不是其他地方也會受到影響呢？
答案是會的，那如何解決呢？
解決方法就是，不直接對外暴露這個變數，而是透過方法返回，此時每一個呼叫者得到檢查方法，怎麼變更都不會影響到其他使用者
返回檢測物件
總結一下：設計模式的使用更多的是為了讓程式碼更加清晰可讀，也透過好的設計模式可以解決很多複雜的問題。
持續更新設計模式，透過簡單的小案例帶你一點點了解設計模式
