不用設計模式我們開發出來的程式照樣能用，那為什麼我們還要用設計模式呢？設計模式在開發中有什麼作用呢？使用設計模式和不使用設計模式的程式有什麼不同呢？等等這一系列的問題，相信每個初學者甚至從事多年開發的Coder都會這樣的疑問（地基打不好，房子能建好？（碼字不容易，不喜勿噴哈！
推薦個俱樂部：
http：//kotlinclub。com/
））；設計模式的六大原則：
一、單一職責原則，實現類要職責單一
我就這一個任務，把這一個任務幹好就行，別讓其他人影響我，我想輕鬆地活著；
二、里氏替換原則，不要破壞繼承體系
要想繼承老子的財產，必須按照老子的來，否則別想繼承
三、依賴倒置原則，要面向介面程式設計
高層模組不應該依賴底層模組，二者都該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象
四、介面隔離原則，在設計介面的時候要精簡單一
吃喝玩樂樣樣在行，幹別的還是再找個人吧！
五、迪米特原則，要降低耦合
我就認識你，就你給我談，別人不行！
六、開閉原則，要對擴充套件開放，對修改關閉
老子就這麼點財產，想要更多錢自己整去！
以上對原則的介紹有點xx，但凡識字就應該能理解啥意思吧，實在不懂，我也沒法了；每個人可能對設計原則有不同的理解，但是萬變不離其宗，都是建房子前需要打的地基，地基越牢，蓋得越高； 這些原則在開發中發揮著一定的作用，有優點也有不足，我們在使用的時候就需要根據當前場景選擇最合適的原則了；基於這些設計原則，衍生出了設計模式，每一種設計模式都遵循著對應的設計原則，原則就六條，但是設計模式卻有23種；555……整那麼多條條框框幹啥呢！不都說九九歸一，返璞歸真嗎？為啥還要那麼麻煩？（蓋房子不打地基，房子能蓋起來不？）
設計模式分為三大類，二十三小類（不要問我誰分的，我也不知道）：
建立性：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
結構性：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行為性：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。
這些設計模式就是程式的地基，一旦打好地基想怎麼造就怎麼造；
扯了這麼多，進入正題：建立型模式之一建造者模式在kotlin中的應用：
The intent of the Builder design pattern is to separate the construction of a complex object from its representation。 By doing so the same construction process can create different representations。
建造者設計模式的目的是將複雜物件的構造與其表示分離。透過這樣做，相同的構造過程可以建立不同的表示。
建造者模式在哪使用都是發揮著同樣的作用，本質不變嘛！在我看來也就在程式碼風格上有些不同，kotlin在coding的時候更簡潔，呼叫的時候更方便而已；下面分別使用kotlin寫了一個開啟小程式的工具類，這個工具類使用了建造者模式：
class WXMiniLaunchUitls（ activity： AppCompatActivity， appId： String， userName： String， appPath： String， appType： String） { companion object { val MINIPTOGRAM_TYPE_RELEASE = “0” val MINIPTOGRAM_TYPE_DEBUG = “1” val MINIPTOGRAM_TYPE_REVIEW = “2” } private val mActivity = WeakReference（activity） private val mAppId： String = appId private val mUserName： String = userName private val mAppPath： String = appPath private val mAppType： String = appType @SuppressLint（“Recycle”） fun openMini（） { val resolver： ContentResolver = mActivity。get（）！！。contentResolver val uri = Uri。parse（“content：//com。tencent。mm。sdk。comm。provider/launchWXMiniprogram”） val path = arrayOf（mAppId， mUserName， mAppPath， mAppType， “”） var cursor： Cursor if （resolver。query（uri， null， null， path， null）。also { cursor = it！！ } ！= null） { cursor。close（） } } class Builder { var appId： String = “” var userName： String = “” var appPath： String = “” var appType： String = “” fun setAppId（appId： String）： Builder { this。appId = appId return this } fun setUserName（userName： String）： Builder { this。userName = userName return this } fun setAppPath（appPath： String）： Builder { this。appPath = appPath return this } fun setAppType（appType： String）： Builder { this。appType = appType return this } fun build（activity： AppCompatActivity）： WXMiniLaunchUitls { return WXMiniLaunchUitls（activity， appId， userName， appPath， appType） } }}
呼叫時不再使用new關鍵字，類似於直接呼叫靜態方法：
WXMiniLaunchUitls。Builder（）。setAppId（“”） 。setUserName（“”） 。setAppPath（“”） 。setAppType（WXMiniLaunchUitls。MINIPTOGRAM_TYPE_DEBUG） 。build（this） 。openMini（）
這只是最基本的一種建造者模式實現方式，看出來跟Java有什麼不同嗎？變數的宣告？物件的例項化？kotlin一直不溫不火的，出世那麼久，也就剛出來的時候比較火，難道它不值得用？我不這麼認為，當你使用習慣了kotlin，你會發現愛不釋手，不再想使用Java，kotlin的特性那麼多，還是多多研究研究吧！
看到這裡有人就會有這樣的疑惑，一個工具類而已，至於使用設計模式嗎？至不至於嘛！說實話，專案中我會使用設計模式，但是不會使用建造者模式，可能會使用單例模式，至於為啥你就細品吧！這個類也就我隨便建的，今天主要說建造者模式：建造者模式最常見的使用者就是dialog，透過呼叫builder設定不同的屬性，只需要設定用到的，不需要用的屬性愛咋地咋地，有這個場景的你就可以考慮是否使用建造者模式了；設計模式的存在讓我們的程式碼更健壯，易維護，讓程式更加穩定。
