一区二区三区精品毛片,大雞巴疯狂浓精合集,91亚洲国产成人久久精品网站,一区二区三区四区免费观看,四虎AV极速,免费黄色一级片,色吊丝一区二区,国产精品自拍三级

雖然SOLID原則不能時刻有效指導編碼落地，理解這些原則背后的設計理念，讓你邁出了第一步，接下來，你需要做的是在前進的路上，不斷地進行編碼實踐、思考總結，將其內化。

做了這么多年的面向對象編程還是寫出違背SOLID原則的代碼，一看都懂、一做就被懟，敏感度不夠，如何是好？

難道SOLID原則本身就有錯？
難道我不應該涉水OOD？
……

請先屏住呼吸，我們來看看SOLID叫什么：

Single Responsibility Principle，單一職責原則
Open Close Principle，開閉原則
Liskov Substitution Principle，里氏替換原則
Interface Segregation Principle，接口隔離原則
Dependency Inversion Principle，依賴倒置原則

原則通常較為抽象，別說剛接觸OO的程序員，有一定經驗的人也不一定吃得透。要想提高對OO原則的敏感度，第一步，我們要清楚SOLID到底在講什么？本文，袁Sir的SOLID創(chuàng)業(yè)故事將為你揭開一層面紗。

設計小而精美的工具箱，提高顧客體驗

袁Sir創(chuàng)業(yè)初期經營了一家五金器具共享租用店，遇到兩類顧客，A顧客需要剪刀、錘子、扳手、電鋸，B顧客需要錘子、扳手、水果刀、梅花刀。袁Sir為了圖省事，把這個六把工具同時裝在一個工具箱里，每次都把裝有6把工具的工具箱給A或B租用。

經過幾次借還，袁Sir收到顧客的抱怨，為什么呢？因為袁Sir這么做增加了A和B的負擔，首先多了兩把工具，扛來抗去的累得多。其次，他們拿回去之后會發(fā)現：”咦，這兩個是啥，我沒要這個呀？莫非是增值服務？但我要用來做啥呢？” 結果A從未用過水果刀和梅花刀，但A還要保管好這兩工具，增加了保管的成本。同理，B顧客也會面臨同樣的問題。為了提高顧客的體驗，袁Sir把這兩類顧客的工具單獨用兩個更小的工具箱裝好，分別提供給A和B，并得到了兩類顧客的一致好評。

袁Sir從一開始圖一時的方便，塞給顧客他本不需要的東西，經過反思后，從顧客需求出發(fā)，只提供顧客想要的東西。投其所好，是他創(chuàng)業(yè)悟出的第一個處世之道。

在軟件設計中，ISP 提倡不要將一個大而全的接口扔給使用者，而是將每個使用者關注的接口進行隔離。

讓客戶堅信徒弟能代替師傅干活

袁Sir勤勤懇懇經營的五金租用店2年，掙了一大把辛苦錢，正好趕上房地產興起的年頭，家裝市場跟著興起，他果斷買下一家知名的家具廠，并跟一家私人工匠所展開了合作。

SJ是工匠所的一名木匠學徒，從師3年有余，書架、衣柜、餐桌，門、窗這些家具已經能夠到跟他的師傅如出一轍了。

袁Sir每次合作都是直接跟SJ的師傅對接，而在實際執(zhí)行過程中，師傅有時候因體力跟不上，就交給SJ去做，好在每次生產出來的家具都能夠讓袁Sir滿意。幾次合作下來，袁Sir便相信：徒弟繼承了師傅的手藝，師傅能做的這些家具，徒弟也一定能做得一模一樣。

2017年，房地產徹底瘋了，袁Sir一次性采購訂單多出了以往2倍。為了如期交付，SJ的師弟小Y也參與進來。不幸的是，個性十足的小Y打造衣柜和門窗的方式跟師傅的風格差別很大，設計出來的家具讓袁Sir一臉懵逼，始料不及的三丈大火燒盡后，袁Sir果斷地中斷了跟這家工匠會所的合作…

[LSP解讀]?小Y將其師傅的手藝繼承后，但自己又擅自修改了設計風格，結果打造的家具跟袁Sir的期望不一致，這就好比子類替換了父類，產生了不一致的行為，軟件不能正常運行，這種繼承設計存在潛在的問題。

在軟件設計中，LSP 重點強調：對使用者來說，能夠使用父類的地方，一定可以使用其子類，并且預期結果是一致的。

簡而言之，子類不應該去修改父類已有的功能（在Java中，體現為子類重寫了父類中非抽象的方法）。如果你的繼承體系中出現了這種替換后不一致的現象，需要警惕你的繼承是否合理了。

關于代碼示例，請在文末參考閱讀文章《讓里氏替換原則為你效力》。

清晰良好的合作協(xié)議，讓彼此更加信任

經過上一次不愉快的合作，袁Sir雖然少掙了一筆錢，還生了一肚子氣。但臺風來，豬想飛你也擋不住。在房地產徹底瘋了的這幾年里，袁Sir又撈了好幾大桶金。有了錢能做什么呢？當然把公司做大，再掙更多的錢呀。

袁Sir秉著 ‘麻雀雖小，五臟不能不全’ 的原則，成立了財務部、法務部、行政部、人事部、市場部、銷售部，由于期初業(yè)務量沒有大到招架不住，各部門都是光桿司令，而且人事、行政、財務、法務四個部門由小蔡獨管（袁Sir流露出了資本家的面貌）。

袁Sir要核對一個報銷單，就直接找財務部的小蔡辦了，要舉辦一場年會還得找小蔡，想了解上個月的銷售業(yè)績，他去找了銷售部的老肖，當然找的最多的還是市場部老史。

經過大半年的快速發(fā)展，各部門從光桿司令變成了群狼作戰(zhàn)。袁Sir仍然按照之前的方式辦事，但遇到了煩惱 – 前天報銷單還是小蔡在處理，昨天變成了小吳，今天又換成了小任。當然，其他部門也產生了相同的現象。苦思冥想，袁Sir出了一招：部門的負責人制定一個固定的服務列表，比如財務部小蔡提供服務列表：

核對報銷單
處理報銷
發(fā)工資
招聘新同事
評審績效
舉辦年會
審核營業(yè)執(zhí)照

袁Sir此時要處理報銷、發(fā)工資，只用找小蔡溝通就好，至于具體誰去執(zhí)行，袁Sir壓根不需要知道。當然其他部門跟財務部合作也輕松了很多。此后袁Sir對所有部門都進行了整改。

此時袁Sir終于才體會到當老板的一丁點美好了。下班合上電腦前，他敲下了一句話：部門之間得通過約定好的協(xié)議來合作，而不用關心對方內部由誰做協(xié)議所規(guī)定的事項。

[DIP解讀]?一開始，袁Sir直接找部門中某個具體執(zhí)行的人去溝通工作，此時袁Sir依賴的是具體實現細節(jié)，每次執(zhí)行的人發(fā)生變化會增加袁Sir的溝通成本。他讓小蔡提供了一個服務清單，小蔡充當了一個抽象/接口，此后他只用找小蔡溝通即可，袁Sir從依賴具體實現細節(jié)轉變到依賴抽象。

在軟件設計中，DIP 提倡使用者依賴一個抽象的服務接口，而不是去依賴一個具體的服務執(zhí)行者，從依賴具體實現轉向到依賴抽象接口，倒置過來。

各司其職，工作效率會大大提升

袁Sir起初讓小蔡統(tǒng)管了人事、行政、財務、法務四個部門，業(yè)務擴張后也只是給小蔡多招了10來個人。小蔡大腦里就不得不繃緊四根弦，他要給部門各個同事合理分配任務，確保公司能夠正常開展日常活動、人員考核培養(yǎng)、工資發(fā)放等工作，當然還有一些諸如工商督查、賬務審核、信息安全審核等敏感的活動。

暫且不說小蔡有多累，關鍵是有一次捅了個簍子，差點沒葬送公司前程。

一天，工商局來了幾個人審核公司的營業(yè)資質，就在小蔡跟工商局負責人交涉的過程中，其他管理賬目的兩位同事因為一項沒法對齊的數據起了點小爭執(zhí)，全然忘記還有工商局調查人員在，口角中抖了一些賬目相關的敏感信息，好在小蔡反應快，及時進行了制止，當然也做了一些額外的安撫工作，把這事給糊弄過去。

這事傳到袁Sir耳中，加上小蔡多次跟袁Sir反饋業(yè)務太雜，不但累且容易出簍子，袁Sir這才把幾個部門進行了拆分，人事部交給了小任，行政部交給了小邢，法務由老發(fā)掌管。

經過幾個月的驗證，讓袁Sir欣喜的是，運營成本不但沒有增加，員工的工作狀態(tài)也比之前大有改善。

從此，財務部門小蔡提供的服務列表：

核對報銷單
處理報銷
發(fā)工資

人事部門小任提供的服務列表：

招聘新員工
員工績效考核
員工培養(yǎng)

行政部小邢提供的服務列表是：

舉辦年會
接待來賓

法務部提供的服務列表是：

審核營業(yè)執(zhí)照
審核信息安全

周五晚上10點，袁Sir走出辦公室大門，哼著小曲自言自語道：還得專門的人干專門的事呀，勿貪多，貪多必失…

袁Sir睡前打開電腦，在備忘錄寫下：分離關注點（專注）是做好一件事的有效途徑，如果同時需要兼顧多項不太相關的工作，注意力就必須在不同的上下文切換，會大大降低工作效率，更糟糕的是可能會出現一些意外的災難。敲完欣慰睡去。

在軟件設計中，SRP 提倡讓一個類只處理一組相關的事情，控制了它的變化方向，后期也能更好的定位。如果引發(fā)變化的因素很多，會導致類的職責過多，難以維護，常見的上帝類就是這么形。

引入中間人讀書大使，解放自己

經過幾年的發(fā)展，袁Sir的公司儼然已經步入正軌，他開始思考公司文化建設方面的事情。

袁Sir一直對讀書非常重視，他想在公司把讀書運動搞起來，每周搞一次分享大會。起初他提議由行政部和人事部來牽頭搞，兩個部門輪流來，自己直接分別跟兩個部門負責此事的負責人對接。

兩個月過去了，公司的讀書氛圍得到大大提升，書架遍布公司各個角落，水果時間也從八卦轉向了讀書心得的分享。

欣慰之余，袁Sir也感覺有點力不從心。經常出現這種現象：有時候去他找人事部的小史商量工作，卻被告知這周輪到行政部的小鄭了，而去找小鄭的時候，被告知市場部也是組織者之一，本周輪到市場部了。

袁Sir因為業(yè)務繁忙，加上翻來覆去的對接工作，搞得心累，但他又很重視這件事情。琢磨良久，他決定給自己招一個讀書會大使（有錢了可以稍微任性一下下），每周要開展讀書運動大會前，他直接跟讀書大使對接，大使后續(xù)再去協(xié)調對應的部門開展工作。

經過這么一整改，袁Sir得到了解放，再也不用關心這周該由哪個部門組織，下次會有什么新的部門加入進來。

看著讀書運動在公司里遍地開花，袁Sir心想著年底了要給讀書最多，分享最多的同事多發(fā)12個月的年終獎…

[OCP解讀]?在一開始，袁Sir支持某個部門舉辦的讀書會，后續(xù)只要有新的部門要負責舉辦時（好比功能上的擴展），袁Sir都要改變自己的溝通方式，這意味著他自身做出修改才能支持新的需求，此時，袁Sir對修改是開放的。引入讀書大使后，相當于做了一個抽象，袁Sir只需要依賴這個抽象，再有新的部門舉辦讀書會時，他就不需要在改變溝通方式了，此時，袁Sir對修改是關閉的，對擴展是開放的。

在軟件設計中，OCP 提倡對修改關閉，對擴展開放。建議為你的服務調用者提供一個他需要的抽象、高層次的行為接口，后期你的服務有新的種類，你只需要新增一個實現該抽象、高層次接口具體服務，而不需要修改調用者的使用方式。

創(chuàng)業(yè)故事回顧

從袁Sir的故事中可以看出來，袁Sir在不同階段之所以面臨各種不同的痛點，主要原因有兩點：

關注的事情太多
關注事情的細節(jié)

創(chuàng)業(yè)初期，袁Sir這么做問題不大，公司在不斷地發(fā)展壯大（如同軟件的演變），袁Sir就需要琢磨出新的方案，而這些方案的核心觀念無非兩個：

分離關注點
引入中間人

在面向對象軟件設計中，關注點分離，其實體現的就是軟件設計的精髓 – 高內聚，低耦合，引入一個中間人則跟面向抽象編程有異曲同工之處。

寫在最后

SOLID原則，它其實是在幫助指導我們設計出高內聚，低耦合的軟件，降低軟件后期的維護成本。雖然原則不能時刻有效指導編碼落地，理解這些原則背后的設計理念，讓你邁出了第一步，接下來，你需要做的是在前進的路上，不斷地進行編碼實踐、思考總結，將其內化。

最后，我想跟技術人員共享一個關鍵詞匯 – 用戶視角/業(yè)務視角：

我們學到了的很多技巧（設計原則、設計模式、重構手法等），如果忘記初衷，失去目標，代碼寫得再炫酷、再健壯，也很難體現出應有的價值。從業(yè)務需求出發(fā)，以用戶視角看問題，致力編寫出簡潔可用的代碼即可。

參考閱讀

讓里氏替換原則為你效力

解析簡單設計原則

聊聊面向對象設計中的Is-A

寫了這么多年代碼，你真的了解SOLID嗎？

- 相關閱讀 -

超越培訓——比培訓多做一點點

使用DDD指導業(yè)務設計的一點思考

趣談編程

讓天下沒有

難懂的技術

點擊【閱讀原文】可至洞見網站查看原文&綠色字體部分的相關鏈接。

本文版權屬ThoughtWorks公司所有，如需轉載請在后臺留言聯系。

你懂SOLID原則嗎？

參考閱讀

點擊【閱讀原文】可至洞見網站查看原文&綠色字體部分的相關鏈接。