01.當(dāng)談?wù)撁嫦驅(qū)ο蟮臅r(shí)候，我們到底在談?wù)撌裁矗?/h3>
面向?qū)ο缶幊痰挠⑽目s寫是 OOP，全稱是 Object Oriented Programming
面向?qū)ο缶幊潭际峭ㄟ^(guò)使用面向?qū)ο缶幊陶Z(yǔ)言來(lái)進(jìn)行的，但是夜畴，不用面向?qū)ο缶幊陶Z(yǔ)言色查，我們照樣可以進(jìn)行面向?qū)ο缶幊碳粑稹７催^(guò)來(lái)講枯夜，即便我們使用面向?qū)ο缶幊陶Z(yǔ)言弯汰，寫出來(lái)的代碼也不一定是面向?qū)ο缶幊田L(fēng)格的，也有可能是面向過(guò)程編程風(fēng)格的
我們沒(méi)必要糾結(jié)到底是四大特性還是三大特性湖雹，關(guān)鍵還是理解每種特性講的是什么內(nèi)容、存在的意義以及能解決什么問(wèn)題曙搬。
隨著編程語(yǔ)言的不斷迭代摔吏、演化，人們發(fā)現(xiàn)繼承這種特性容易造成層次不清纵装、代碼混亂征讲，所以，很多編程語(yǔ)言在設(shè)計(jì)的時(shí)候就開(kāi)始摒棄繼承特性橡娄，比如 Go 語(yǔ)言诗箍。但是，我們并不能因?yàn)樗饤壛死^承特性挽唉，就一刀切地認(rèn)為它不是面向?qū)ο缶幊陶Z(yǔ)言了滤祖。
按照嚴(yán)格的定義，很多語(yǔ)言都不能算得上面向?qū)ο缶幊陶Z(yǔ)言瓶籽，但按照不嚴(yán)格的定義來(lái)講匠童，現(xiàn)在流行的大部分編程語(yǔ)言都是面向?qū)ο缶幊陶Z(yǔ)言。
面向?qū)ο蠓治觯∣OA）和面向?qū)ο笤O(shè)計(jì)（OOD）
面向?qū)ο蠓治鼍褪且闱宄鍪裁此芩常嫦驅(qū)ο笤O(shè)計(jì)就是要搞清楚怎么做汤求，面向?qū)ο缶幊叹褪菍⒎治龊驮O(shè)計(jì)的的結(jié)果翻譯成代碼的過(guò)程。
02.封裝严拒、抽象扬绪、繼承、多態(tài)分別可以解決哪些編程問(wèn)題裤唠？
- 封裝
類僅僅通過(guò)有限的方法暴露必要的操作挤牛，也能提高類的易用性。如果我們把類屬性都暴露給類的調(diào)用者巧骚，調(diào)用者想要正確地操作這些屬性赊颠，就勢(shì)必要對(duì)業(yè)務(wù)細(xì)節(jié)有足夠的了解格二。而這對(duì)于調(diào)用者來(lái)說(shuō)也是一種負(fù)擔(dān)。相反竣蹦，如果我們將屬性封裝起來(lái)顶猜，暴露少許的幾個(gè)必要的方法給調(diào)用者使用，調(diào)用者就不需要了解太多背后的業(yè)務(wù)細(xì)節(jié)痘括，用錯(cuò)的概率就減少很多长窄。
- 抽象
抽象這個(gè)概念是一個(gè)非常通用的設(shè)計(jì)思想，并不單單用在面向?qū)ο缶幊讨懈倬部梢杂脕?lái)指導(dǎo)架構(gòu)設(shè)計(jì)等挠日。而且這個(gè)特性也并不需要編程語(yǔ)言提供特殊的語(yǔ)法機(jī)制來(lái)支持，只需要提供“函數(shù)”這一非澈采啵基礎(chǔ)的語(yǔ)法機(jī)制嚣潜，就可以實(shí)現(xiàn)抽象特性、所以椅贱，它沒(méi)有很強(qiáng)的“特異性”懂算，有時(shí)候并不被看作面向?qū)ο缶幊痰奶匦灾弧?/p>
在面對(duì)復(fù)雜系統(tǒng)的時(shí)候，人腦能承受的信息復(fù)雜程度是有限的庇麦，所以我們必須忽略掉一些非關(guān)鍵性的實(shí)現(xiàn)細(xì)節(jié)计技。而抽象作為一種只關(guān)注功能點(diǎn)不關(guān)注實(shí)現(xiàn)的設(shè)計(jì)思路，正好幫我們的大腦過(guò)濾掉許多非必要的信息山橄。
抽象作為一個(gè)非常寬泛的設(shè)計(jì)思想垮媒，在代碼設(shè)計(jì)中，起到非常重要的指導(dǎo)作用航棱。很多設(shè)計(jì)原則都體現(xiàn)了抽象這種設(shè)計(jì)思想睡雇，比如基于接口而非實(shí)現(xiàn)編程、開(kāi)閉原則（對(duì)擴(kuò)展開(kāi)放丧诺、對(duì)修改關(guān)閉）入桂、代碼解耦（降低代碼的耦合性）
我們?cè)诙x（或者叫命名）類的方法的時(shí)候，也要有抽象思維驳阎，不要在方法定義中抗愁，暴露太多的實(shí)現(xiàn)細(xì)節(jié)，以保證在某個(gè)時(shí)間點(diǎn)需要改變方法的實(shí)現(xiàn)邏輯的時(shí)候呵晚，不用去修改其定義
- 繼承
繼承最大的一個(gè)好處就是代碼復(fù)用蜘腌。我們也可以通過(guò)其他方式來(lái)解決這個(gè)代碼復(fù)用的問(wèn)題，比如利用組合關(guān)系而不是繼承關(guān)系饵隙。繼承的概念很好理解撮珠，也很容易使用。不過(guò)金矛，過(guò)度使用繼承芯急，繼承層次過(guò)深過(guò)復(fù)雜勺届，就會(huì)導(dǎo)致代碼可讀性、可維護(hù)性變差娶耍。很多人覺(jué)得繼承是一種反模式免姿。我們應(yīng)該盡量少用，甚至不用榕酒。
- 多態(tài)
多態(tài)特性能提高代碼的可擴(kuò)展性和復(fù)用性胚膊。多態(tài)也是很多設(shè)計(jì)模式、設(shè)計(jì)原則想鹰、編程技巧的代碼實(shí)現(xiàn)基礎(chǔ)紊婉，比如策略模式、基于接口而非實(shí)現(xiàn)編程辑舷、依賴倒置原則喻犁、里式替換原則、利用多態(tài)去掉冗長(zhǎng)的 if-else 語(yǔ)句等等
03.面向?qū)ο笙啾让嫦蜻^(guò)程有哪些優(yōu)勢(shì)何缓？面向過(guò)程真的過(guò)時(shí)了嗎
相較于面向?qū)ο缶幊桃灶悶榻M織代碼的基本單元株汉，面向過(guò)程編程則是以過(guò)程（或方法）作為組織代碼的基本單元。它最主要的特點(diǎn)就是數(shù)據(jù)和方法相分離歌殃。相較于面向?qū)ο缶幊陶Z(yǔ)言，面向過(guò)程編程語(yǔ)言最大的特點(diǎn)就是不支持豐富的面向?qū)ο缶幊烫匦则疲热缋^承氓皱、多態(tài)、封裝勃刨。
面向?qū)ο缶幊滔啾绕鹈嫦蜻^(guò)程編程的優(yōu)勢(shì)主要有三個(gè)波材。
- 對(duì)于大規(guī)模復(fù)雜程序的開(kāi)發(fā)，程序的處理流程并非單一的一條主線身隐，而是錯(cuò)綜復(fù)雜的網(wǎng)狀結(jié)構(gòu)廷区。
- 面向?qū)ο缶幊瘫绕鹈嫦蜻^(guò)程編程，更能應(yīng)對(duì)這種復(fù)雜類型的程序開(kāi)發(fā)贾铝。面向?qū)ο缶幊滔啾让嫦蜻^(guò)程編程隙轻，具有更加豐富的特性（封裝、抽象垢揩、繼承玖绿、多態(tài)）。利用這些特性編寫出來(lái)的代碼叁巨，更加易擴(kuò)展、易復(fù)用、易維護(hù)璃谨。
- 從編程語(yǔ)言跟機(jī)器打交道的方式的演進(jìn)規(guī)律中，我們可以總結(jié)出：面向?qū)ο缶幊陶Z(yǔ)言比起面向過(guò)程編程語(yǔ)言狡蝶，更加人性化、更加高級(jí)贮勃、更加智能贪惹。
面向?qū)ο缶幊掏ㄟ^(guò)類這種組織代碼的方式，將數(shù)據(jù)和方法綁定在一起衙猪，通過(guò)訪問(wèn)權(quán)限控制馍乙，只允許外部調(diào)用者通過(guò)類暴露的有限方法訪問(wèn)數(shù)據(jù)，而不會(huì)像面向過(guò)程編程那樣垫释，數(shù)據(jù)可以被任意方法隨意修改丝格。因此，面向?qū)ο缶幊烫峁┑姆庋b特性更有利于提高代碼的易維護(hù)性棵譬。
函數(shù)本身就是一種抽象显蝌，它隱藏了具體的實(shí)現(xiàn)。我們?cè)谑褂煤瘮?shù)的時(shí)候订咸，只需要了解函數(shù)具有什么功能曼尊，而不需要了解它是怎么實(shí)現(xiàn)的。從這一點(diǎn)上脏嚷，不管面向過(guò)程編程還是是面向?qū)ο缶幊搪嫫玻贾С殖橄筇匦浴２贿^(guò)父叙，面向?qū)ο缶幊踢€提供了其他抽象特性的實(shí)現(xiàn)方式神郊。這些實(shí)現(xiàn)方式是面向過(guò)程編程所不具備的，比如基于接口實(shí)現(xiàn)的抽象趾唱∮咳椋基于接口的抽象，可以讓我們?cè)诓桓淖冊(cè)袑?shí)現(xiàn)的情況下甜癞，輕松替換新的實(shí)現(xiàn)邏輯夕晓，提高了代碼的可擴(kuò)展性。
繼承特性是面向?qū)ο缶幊滔啾扔诿嫦蜻^(guò)程編程所特有的兩個(gè)特性之一（另一個(gè)是多態(tài)）
基于多態(tài)特性悠咱，在實(shí)際的代碼運(yùn)行過(guò)程中蒸辆，調(diào)用子類新的功能邏輯，而不是在原有代碼上做修改乔煞。這就遵從了“對(duì)修改關(guān)閉吁朦、對(duì)擴(kuò)展開(kāi)放”的設(shè)計(jì)原則，提高代碼的擴(kuò)展性渡贾。除此之外逗宜，利用多態(tài)特性，不同的類對(duì)象可以傳遞給相同的方法，執(zhí)行不同的代碼邏輯纺讲，提高了代碼的復(fù)用性擂仍。
當(dāng)然，我們不能說(shuō)熬甚，利用面向過(guò)程風(fēng)格就不可以寫出易復(fù)用逢渔、易擴(kuò)展、易維護(hù)的代碼乡括，但沒(méi)有四大特性的幫助肃廓，付出的代價(jià)可能就要高一些。
04.哪些代碼設(shè)計(jì)看似是面向?qū)ο蠡迕冢瑢?shí)際是面向過(guò)程的盲赊？
面向?qū)ο蠓庋b的定義是：通過(guò)訪問(wèn)權(quán)限控制，隱藏內(nèi)部數(shù)據(jù)敷扫，外部?jī)H能通過(guò)類提供的有限的接口訪問(wèn)哀蘑、修改內(nèi)部數(shù)據(jù)。所以葵第，暴露不應(yīng)該暴露的 setter 方法绘迁，明顯違反了面向?qū)ο蟮姆庋b特性。數(shù)據(jù)沒(méi)有訪問(wèn)權(quán)限控制卒密，任何代碼都可以隨意修改它缀台，代碼就退化成了面向過(guò)程編程風(fēng)格的了。
在設(shè)計(jì)實(shí)現(xiàn)類的時(shí)候哮奇，除非真的需要将硝，否則，盡量不要給屬性定義 setter 方法屏镊。除此之外，盡管 getter 方法相對(duì) setter 方法要安全些痰腮，但是如果返回的是集合容器（比如例子中的 List 容器）而芥，也要防范集合內(nèi)部數(shù)據(jù)被修改的危險(xiǎn)。
在面向?qū)ο缶幊讨邪蛑担Ｒ?jiàn)的全局變量有單例類對(duì)象棍丐、靜態(tài)成員變量、常量等沧踏。我們常用的各種 Utils 類歌逢，里面的方法一般都會(huì)定義成靜態(tài)方法，可以在不用創(chuàng)建對(duì)象的情況下翘狱，直接拿來(lái)使用秘案。靜態(tài)方法將方法與數(shù)據(jù)分離，破壞了封裝特性，是典型的面向過(guò)程風(fēng)格阱高。
我們把程序中所有用到的常量赚导，都集中地放到這個(gè) Constants 類中。不過(guò)赤惊，定義一個(gè)如此大而全的 Constants 類吼旧，并不是一種很好的設(shè)計(jì)思路。
- 首先未舟，這樣的設(shè)計(jì)會(huì)影響代碼的可維護(hù)性圈暗。
- 其次，這樣的設(shè)計(jì)還會(huì)增加代碼的編譯時(shí)間裕膀。
- 最后员串，這樣的設(shè)計(jì)還會(huì)影響代碼的復(fù)用性。
第一種是將 Constants 類拆解為功能更加單一的多個(gè)類
當(dāng)然魂角，還有一種我個(gè)人覺(jué)得更好的設(shè)計(jì)思路昵济，那就是并不單獨(dú)地設(shè)計(jì) Constants 常量類，而是哪個(gè)類用到了某個(gè)常量野揪，我們就把這個(gè)常量定義到這個(gè)類中访忿。這樣也提高了類設(shè)計(jì)的內(nèi)聚性和代碼的復(fù)用性。
在定義 Utils 類之前斯稳，你要問(wèn)一下自己海铆，你真的需要單獨(dú)定義這樣一個(gè) Utils 類嗎？是否可以把 Utils 類中的某些方法定義到其他類中呢挣惰？如果在回答完這些問(wèn)題之后卧斟，你還是覺(jué)得確實(shí)有必要去定義這樣一個(gè) Utils 類，那就大膽地去定義它吧憎茂。
類比 Constants 類的設(shè)計(jì)珍语，我們?cè)O(shè)計(jì) Utils 類的時(shí)候，最好也能細(xì)化一下竖幔，針對(duì)不同的功能板乙，設(shè)計(jì)不同的 Utils 類，比如 FileUtils拳氢、IOUtils募逞、StringUtils、UrlUtils 等馋评，不要設(shè)計(jì)一個(gè)過(guò)于大而全的 Utils 類放接。
在面向?qū)ο缶幊讨校惖脑O(shè)計(jì)還是挺需要技巧留特，挺需要一定設(shè)計(jì)經(jīng)驗(yàn)的纠脾。你要去思考如何封裝合適的數(shù)據(jù)和方法到一個(gè)類里玛瘸，如何設(shè)計(jì)類之間的關(guān)系，如何設(shè)計(jì)類之間的交互等等諸多設(shè)計(jì)問(wèn)題乳乌。
不管使用面向過(guò)程還是面向?qū)ο竽姆N風(fēng)格來(lái)寫代碼捧韵，我們最終的目的還是寫出易維護(hù)、易讀汉操、易復(fù)用再来、易擴(kuò)展的高質(zhì)量代碼。只要我們能避免面向過(guò)程編程風(fēng)格的一些弊端磷瘤，控制好它的副作用芒篷，在掌控范圍內(nèi)為我們所用，我們就大可不用避諱在面向?qū)ο缶幊?br> 中寫面向過(guò)程風(fēng)格的代碼采缚。
05.接口vs抽象類的區(qū)別针炉？如何用普通的類模擬抽象類和接口？
接口vs抽象類的區(qū)別
1. 抽象類和接口的語(yǔ)法特性
- 抽象類不允許被實(shí)例化扳抽，只能被繼承篡帕。它可以包含屬性和方法。方法既可以包含代碼實(shí)現(xiàn)贸呢，也可以不包含代碼實(shí)現(xiàn)镰烧。不包含代碼實(shí)現(xiàn)的方法叫作抽象方法。
- 接口不能包含屬性楞陷，只能聲明方法怔鳖，方法不能包含代碼實(shí)現(xiàn)。類實(shí)現(xiàn)接口的時(shí)候固蛾，必須實(shí)現(xiàn)接口中聲明的所有方法结执。
2. 抽象類和接口存在的意義
- 抽象類是對(duì)成員變量和方法的抽象，是一種 is-a 關(guān)系艾凯，是為了解決代碼復(fù)用問(wèn)題献幔。
- 接口僅僅是對(duì)方法的抽象，是一種 has-a 關(guān)系趾诗，表示具有某一組行為特性斜姥，是為了解決解耦問(wèn)題，隔離接口和具體的實(shí)現(xiàn)沧竟，提高代碼的擴(kuò)展性。
3. 抽象類和接口的應(yīng)用場(chǎng)景區(qū)別
- 判斷的標(biāo)準(zhǔn)很簡(jiǎn)單缚忧。如果要表示一種 is-a 的關(guān)系悟泵，并且是為了解決代碼復(fù)用問(wèn)題，我們就用抽象類
- 如果要表示一種 has-a 關(guān)系闪水，并且是為了解決抽象而非代碼復(fù)用問(wèn)題糕非，那我們就用接口。
06.為什么基于接口而非實(shí)現(xiàn)編程？有必要為每個(gè)類都定義接口嗎朽肥？
- 我們?cè)谧鲕浖_(kāi)發(fā)的時(shí)候禁筏，一定要有抽象意識(shí)、封裝意識(shí)衡招、接口意識(shí)篱昔。在定義接口的時(shí)候，不要暴露任何實(shí)現(xiàn)細(xì)節(jié)始腾。接口的定義只表明做什么州刽，而不是怎么做。而且浪箭，在設(shè)計(jì)接口的時(shí)候穗椅，我們要多思考一下，這樣的接口設(shè)計(jì)是否足夠通用奶栖，是否能夠做到在替換具體的接口實(shí)現(xiàn)的時(shí)候匹表，不需要任何接口定義的改動(dòng)。
- 很多人在定義接口的時(shí)候宣鄙，希望通過(guò)實(shí)現(xiàn)類來(lái)反推接口的定義袍镀。先把實(shí)現(xiàn)類寫好，然后看實(shí)現(xiàn)類中有哪些方法框冀，照抄到接口定義中流椒。如果按照這種思考方式，就有可能導(dǎo)致接口定義不夠抽象明也，依賴具體的實(shí)現(xiàn)宣虾。這樣的接口設(shè)計(jì)就沒(méi)有意義了。不過(guò)温数，如果你覺(jué)得這種思考方式更加順暢绣硝，那也沒(méi)問(wèn)題，只是將實(shí)現(xiàn)類的方法搬移到接口定義中的時(shí)候撑刺，要有選擇性的搬移鹉胖，不要將跟具體實(shí)現(xiàn)相關(guān)的方法搬移到接口中
“基于接口而非實(shí)現(xiàn)編程”，這條原則的另一個(gè)表述方式够傍，是“基于抽象而非實(shí)現(xiàn)編程”甫菠。后者的表述方式其實(shí)更能體現(xiàn)這條原則的設(shè)計(jì)初衷。
- 這條原則的設(shè)計(jì)初衷是冕屯，將接口和實(shí)現(xiàn)相分離寂诱，封裝不穩(wěn)定的實(shí)現(xiàn)，暴露穩(wěn)定的接口安聘。上游系統(tǒng)面向接口而非實(shí)現(xiàn)編程痰洒，不依賴不穩(wěn)定的實(shí)現(xiàn)細(xì)節(jié)瓢棒，這樣當(dāng)實(shí)現(xiàn)發(fā)生變化的時(shí)候，上游系統(tǒng)的代碼基本上不需要做改動(dòng)丘喻，以此來(lái)降低代碼間的耦合性脯宿，提高代碼的擴(kuò)展性。
- 做任何事情都要講求一個(gè)“度”泉粉，過(guò)度使用這條原則连霉，非得給每個(gè)類都定義接口，接口滿天飛搀继，也會(huì)導(dǎo)致不必要的開(kāi)發(fā)負(fù)擔(dān)窘面。至于什么時(shí)候，該為某個(gè)類定義接口叽躯，實(shí)現(xiàn)基于接口的編程财边，什么時(shí)候不需要定義接口，直接使用實(shí)現(xiàn)類編程点骑，我們做權(quán)衡的根本依據(jù)酣难，還是要回歸到設(shè)計(jì)原則誕生的初衷上來(lái)。只要搞清楚了這條原則是為了解決什么樣的問(wèn)題而產(chǎn)生的黑滴，你就會(huì)發(fā)現(xiàn)憨募，很多之前模棱兩可的問(wèn)題，都會(huì)變得豁然開(kāi)朗袁辈。
- 我們?cè)诙x接口的時(shí)候菜谣，一方面，命名要足夠通用晚缩，不能包含跟具體實(shí)現(xiàn)相關(guān)的字眼尾膊；另一方面，與特定實(shí)現(xiàn)有關(guān)的方法不要定義在接口中
07.為何說(shuō)要多用組合少用繼承荞彼？如何決定該用組合還是繼承冈敛？
類的繼承層次會(huì)越來(lái)越深、繼承關(guān)系會(huì)越來(lái)越復(fù)雜鸣皂。而這種層次很深抓谴、很復(fù)雜的繼承關(guān)系，一方面寞缝，會(huì)導(dǎo)致代碼的可讀性變差癌压。因?yàn)槲覀円闱宄硞€(gè)類具有哪些方法、屬性荆陆，必須閱讀父類的代碼滩届、父類的父類的代碼……一直追溯到最頂層父類的代碼。另一方面慎宾，這也破壞了類的封裝特性丐吓，將父類的實(shí)現(xiàn)細(xì)節(jié)暴露給了子類。子類的實(shí)現(xiàn)依賴父類的實(shí)現(xiàn)趟据，兩者高度耦合券犁，一旦父類代碼修改，就會(huì)影響所有子類的邏輯汹碱。
繼承最大的問(wèn)題就在于：繼承層次過(guò)深粘衬、繼承關(guān)系過(guò)于復(fù)雜會(huì)影響到代碼的可讀性和可維護(hù)性。
從理論上講咳促，通過(guò)組合稚新、接口、委托三個(gè)技術(shù)手段跪腹，我們完全可以替換掉繼承褂删，在項(xiàng)目中不用或者少用繼承關(guān)系，特別是一些復(fù)雜的繼承關(guān)系冲茸。
繼承改寫成組合意味著要做更細(xì)粒度的類的拆分屯阀。這也就意味著，我們要定義更多的類和接口轴术。類和接口的增多也就或多或少地增加代碼的復(fù)雜程度和維護(hù)成本难衰。所以，在實(shí)際的項(xiàng)目開(kāi)發(fā)中逗栽，我們還是要根據(jù)具體的情況盖袭，來(lái)具體選擇該用繼承還是組合。
有一些特殊的場(chǎng)景要求我們必須使用繼承彼宠。如果你不能改變一個(gè)函數(shù)的入?yún)㈩愋亡雲(yún)⒂址墙涌冢瑸榱酥С侄鄳B(tài)兵志，只能采用繼承來(lái)實(shí)現(xiàn)醇蝴。比如FeignClient 是一個(gè)外部類，我們沒(méi)有權(quán)限去修改這部分代碼想罕，但是我們希望能重寫這個(gè)類在運(yùn)行時(shí)執(zhí)行的 encode() 函數(shù)悠栓，這個(gè)時(shí)候，我們只能采用繼承來(lái)實(shí)現(xiàn)了
感悟：選中使用組合還是繼承按价，要考慮場(chǎng)景惭适。如果類之間的繼承結(jié)構(gòu)穩(wěn)定，層次比較淺楼镐，關(guān)系不復(fù)雜癞志，我們就可以大膽地使用繼承。反之框产，我們就盡量使用組合來(lái)替代繼承凄杯。
