什麼是設計模式

　曾有人調侃，設計模式是工程師用於跟別人顯擺的，顯得高大上；也曾有人這麼說，不是設計模式沒用，是你尚未到能懂它，會用它的時候。

先來看一下比較官方的解釋：「設計模式（Design pattern）是一套被反覆使用、多數人知曉的、通過分類的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的；設計模式使代碼編制真正工程化；設計模式是軟件工程的基石脈絡，如同大廈的結構同樣。」

 

　　今天咱們來聊聊CSS的設計模式。

　　設計模式，這個詞彙咱們常見，幾乎全部的編程語言都會有幾套，但深刻研究的人很少，緣由以下：

　　一、彷佛沒有太大必要性去強調它，有問題了改一下或者按團隊規範來就行；

　　二、不去使用一些既有的模式也無傷大雅；

　　三、很多人所接觸的業務量級尚未達到須要規劃和組織的程度，光寫佈局，寫特效，照顧兼容，就夠喝一壺的了，沒有意識去思考一些方法論的問題。

　　固然，這三者都是我經歷過的，相信你也是~

　　咱們都會長大，都會慢慢的作更多、更大、更復雜的項目，這個時候，就須要自上而下，全流程的去思考一些問題。後臺不說，只講前端，好比：風格的制定、色調、模塊、佈局方式、交互方式、邏輯等等，若是再加上團隊合做，若再沒有一個規劃的話，要不了多久，那些看起來沒問題的代碼，就會暴露出各類問題，模塊命名、類的命名、文件的組織、共用模塊的提取、代碼的複用、可讀性、擴展性、維護性。它們看起來只是一些簡單的小動做，卻須要你看得更遠，避免未來出問題須要付出更大的代價，甚至被迫整個項目重構，可謂，功在當代，利在千秋~

　　既然要對CSS進行設計，那麼確定是它自己存在一些問題或者缺陷，其中，一個最明顯的就是，它的任何一個規則，都是全局性的聲明，會對引入它的頁面當中全部相關元素起做用，無論那是否是你想要的。而獨立及可組合的模塊是一個可維護系統的關鍵所在。下面，咱們就從多個層面來探討一下，到底該怎樣寫CSS，纔是更科學的。

　

　從需求出發

　　分

　　咱們剛開始學習寫字的時候，是不會去考慮，寫出來的某句話好很差，文章結構合適不合適，由於咱們是意識不到的。寫代碼也同樣，剛開始，咱們只是去定義規則，能用對了屬性，語法正確，把頁面實現出來了，就好。慢慢地，就會發現，頁面也是有結構的，咱們按照頁面的結構去組織代碼，會不會更好？好比，分紅頭部、導航、側邊欄、banner區、主內容區、底部等。

　　然而這樣貌似仍是不夠，由於還有一些東西，複用度是很高的，又很差把它歸爲任何一個固有模塊，好比：麪包屑、分頁、彈窗等，它們不適合被放到某一個固有模塊的代碼中，就能夠單獨的分出一段專屬的css和js，或許，這就是組件化的由來~

　　拆

　　在分了以後，咱們的代碼看起來已經比以前好不少了，組織清晰，維護性大幅提升，可是，好像仍是不夠，咱們會發現另一些東西，很細小，但複用度也很高，它們一樣不適合被放到模塊中去，好比，邊框、背景、圖標、字體、邊距、佈局方式等等。若是咱們在每一個須要它們的地方，都定義一次，它們會被重複不少次，顯然，這背離好的實踐，會形成代碼冗餘和維護困難。因此，咱們須要「拆」。拆過以後會怎樣？咱們想在哪裏用能夠直接加，須要改的時候統一改。

　　排

　　通過了「分」、「拆」，咱們的代碼結構已經十分清晰，各個內容模塊，功能模塊，UI模塊都乖巧的等待召喚，那麼還差什麼？是的，還差有序的組織，分類清晰以後，還須要排列有序，從不一樣緯度去考量，咱們總能精益求精。

　　3、Meta CSS

　　原子類，也能夠稱之爲「無語義」類，像這樣：

 

　　它的特色是什麼？樣式和結構、內容無關，預先定義好這麼一組規則，在須要的地方加上便可，我相信每一個人第一次看到這種寫法的時候，都會想：還能這樣寫啊？！是的，總有一些人，一些新的思想和方法會涌現出來，它就是其中之一，固然，並非在稱讚其自己有多麼好，而是說這種現象和過程是好的，它自己常常被人吐槽，好比：「這樣寫和直接內聯有區別嗎？」、「若是要調整樣式，就要去改HTML，維護更加麻煩，也有違樣式和結構分離的初衷」等等，其實我我的也是不同意上面這種寫法的，若是你要把這些抽離出來，那麼還有什麼抽不出來的呢？並且這些屬性，在項目之間，頁面之間，模塊之間，並無太大的通用性，把這些抽出來，只不過是稍微懶省勁兒些，但爲了照顧到更多狀況，你必須寫入冗餘代碼，是得不償失的。

　　雖然它有缺點，我我的同意另外的一些東西分出來，好比：浮動（float）、文本佈局（text-align）、Flexbox佈局等，這些是沒有那麼多可能性的值，並且使用頻繁，複用方便，改動較少，除此以外，你還能夠提取另一些公共的小顆粒類，好比按鈕的種類，文字顏色的種類等，這些和CSS自己無關，和項目相關，這就是借鑑其思想，而不是直接拿來用。

　　4、BEM

　　嚴格說來，BEM不是一套有骨有肉的模式，也不只僅侷限你在CSS的層面去規劃，它是一種怎樣去組織、編寫代碼的思想，並且，看似簡單的它，對前端界的影響倒是巨大的。

　　它的核心以下：

　　Block（塊）、Element（元素）、Modifier（修飾符）

　　它幫助咱們定義頁面中每一部分的級別屬性，從某種意義上說，也是一種「拆」。命名規則以下：

 

　　它的出現，曾給很多人帶來啓發，可是也有另外一部分人仍然抱着挑剔的態度，譬如：

　　一、風格不統一，顯得代碼不夠整潔美觀

　　二、可能會致使類名過長

　　仍是前面說的，你能夠不去直接用它，但要清楚它的優勢：可以使得咱們僅經過類名就知道哪些代碼是屬於一個模塊內，以及在模塊中所起的做用。而後借鑑之。

　　固然，BEM集聚了不少人的心血，也獲得了不少的讚譽，其中就包括OOCSS的做者。因此，它確定不是這麼簡單。它還會告訴你，怎樣配合着js來寫，你的文件怎樣組織更好，項目該怎麼構建等。詳細能夠到官網去查閱。

　從實際出發，決定結果的人是你

　　到底怎樣使用設計模式？

　　雖然已經有成熟的設計模式，但在實際當中，你可能以爲哪一個跟本身的項目都不能徹底吻合，或者你要去爲了使用它們而調整，成本很高。其實，咱們不須要去迎合模式，要讓模式爲我所用，你須要去了解它們背後的原理，要知道它們用什麼方式解決了什麼問題，而後借鑑之，用它的方式解決咱們的問題，就好，這樣就不須要做難要不要用，也不須要糾結選哪一個，不是簡單的說哪一個好，哪一個很差，總有咱們可以用得上它的地方。海納百川，集百家衆長。

　　我我的一直以來所堅持的另外一個觀點就是，前端開發的三駕馬車——html、css、js，不要，也不能孤立的去談那樣好或者這樣好，咱們極少會有隻用一次的代碼或者模塊，也不會只寫一種語言，三駕馬車都是在一塊兒協做的，都是會有複用、擴展和團隊合做多方面的因素在裏面。故而，不能抱着這樣的想法：我如今就在作這個，它就是惟一的，就是固定的，沒問題。其實不少問題都是潛在的，要帶着發展眼光去看待。項目的文件之間，項目之間，團隊成員之間，不論你的分工是哪塊，都要考慮到先後的影響和可能給合做帶來的不便。

　　怎樣纔是最佳實踐？有「實踐」，纔有「最佳」，脫離實際狀況談最佳，就是空中樓閣。那麼，最好的模式，不是哪一個經典的模式，而是在項目進行中，不斷的磨合調整而出的。故而，不須要再害怕看起來不明覺厲的設計模式，也不須要由於本身還不懂設計模式而鬱悶，它就是人們總結出來的實戰方法，你也能夠有本身的模式~