有人說設(shè)計(jì)模式是為了彌補(bǔ)Java語言的缺陷，你覺得是這樣嗎？如果你從語言的角度來看設(shè)計(jì)模式，那是對(duì)的。一些設(shè)計(jì)模式彌補(bǔ)了Java語言的不足，其中最明顯的是singleton模式。Java本身不提供單例

有人說設(shè)計(jì)模式是為了彌補(bǔ)Java語言的缺陷，你覺得是這樣嗎？

如果你從語言的角度來看設(shè)計(jì)模式，那是對(duì)的。一些設(shè)計(jì)模式彌補(bǔ)了Java語言的不足，其中最明顯的是singleton模式。

Java本身不提供單例對(duì)象創(chuàng)建，需要通過單例模式實(shí)現(xiàn)。什么樣的餓、懶、多線程都要注意DCL、易變關(guān)鍵字等，導(dǎo)致面試題很多。

在現(xiàn)代語言中，許多提供了創(chuàng)建單例對(duì)象的語法，例如scala和kotlin的對(duì)象關(guān)鍵字。

從架構(gòu)的角度來看，設(shè)計(jì)模式將組件關(guān)系解耦。

假設(shè)我們要實(shí)現(xiàn)一個(gè)帶有上載服務(wù)的文件服務(wù)器來上載文件。我們可以調(diào)用convertservice來轉(zhuǎn)換文件。Uploadservice屬于核心模塊upload module，convertservice屬于非核心模塊conversion module。

如果uploadservice直接調(diào)用convertservice來執(zhí)行轉(zhuǎn)換，則核心模塊依賴于非核心模塊。如下圖所示：

非核心模塊相對(duì)不穩(wěn)定，核心模塊相對(duì)穩(wěn)定。核心模塊對(duì)非核心模塊的依賴將導(dǎo)致核心模塊的不穩(wěn)定性。所以可以使用策略模式來解耦：

看箭頭方向，現(xiàn)在轉(zhuǎn)換模塊依賴于上傳模塊，轉(zhuǎn)換模塊的變化不會(huì)影響上傳模塊。依賴的方向改變了。這就是傳說中的“依賴倒置”

隨著架構(gòu)設(shè)計(jì)的演變?yōu)槭裁错?xiàng)目中需要用到SOA框架？

當(dāng)我們?cè)?0多年前接觸到SOA概念時(shí)，主要來自IBM和Oracle的領(lǐng)先廠商以及一些國內(nèi)中間件制造商都在跟進(jìn)。人氣不亞于區(qū)塊鏈、中間平臺(tái)和aiot。所有公司都使用自己的產(chǎn)品和解決方案組合來推斷SOA。更典型的產(chǎn)品是ESB、BPM、portal，有時(shí)還有DP開發(fā)平臺(tái)。當(dāng)時(shí)很多企業(yè)決定構(gòu)建SOA，軟件開發(fā)者甚至ERP廠商都必須與SOA有關(guān)聯(lián)，否則他們不知道怎么談電影，不好意思跟別人打招呼。

SOA面向服務(wù)架構(gòu)是一種設(shè)計(jì)理念和架構(gòu)規(guī)范，用于構(gòu)建靈活的it架構(gòu)，支持隨需應(yīng)變的業(yè)務(wù)。

然而，應(yīng)用軟件廠商強(qiáng)調(diào)的集成更多的是大規(guī)模系統(tǒng)模塊之間的集成，而中間件廠商強(qiáng)調(diào)的是異構(gòu)應(yīng)用系統(tǒng)之間的集成。

很多時(shí)候，企業(yè)系統(tǒng)必須基于SOA進(jìn)行集成，但僅僅依靠ESB、BPM和門戶是不夠的。必須有MDM主數(shù)據(jù)治理、IDM統(tǒng)一權(quán)限、統(tǒng)一賬戶和統(tǒng)一認(rèn)證。MDM是深度應(yīng)用集成（如BPM跨異構(gòu)系統(tǒng)過程集成）和深度數(shù)據(jù)集成（DW、BI、BD、DSS、DAP和其他數(shù)據(jù)分析平臺(tái)項(xiàng)目）的基礎(chǔ)。SOA產(chǎn)品的綜合集成項(xiàng)目是基礎(chǔ)，只有產(chǎn)品是不夠的。需要甲方的高層支持，需要業(yè)務(wù)部門、應(yīng)用廠商、信息部門的高效合作、拼搏和妥協(xié)。這是一個(gè)考驗(yàn)交付團(tuán)隊(duì)和甲方能力和決心的大項(xiàng)目，經(jīng)過十多年的投入，從產(chǎn)品的實(shí)施、管理體系的實(shí)施、解決方案的實(shí)施、企業(yè)文化的實(shí)施等方面都提煉出了許多最佳實(shí)踐，已成為數(shù)據(jù)鏈敏捷集成的基因。

試問設(shè)計(jì)模式、架構(gòu)模式和架構(gòu)風(fēng)格的異同點(diǎn)？

架構(gòu)模式描述了子系統(tǒng)或模塊的粗粒度解決方案，以及它們之間的關(guān)系。

體系結(jié)構(gòu)風(fēng)格是描述特定應(yīng)用領(lǐng)域中系統(tǒng)組織的通用模式，是系統(tǒng)的主要設(shè)計(jì)和組織設(shè)計(jì)。風(fēng)格是圖案的外在表現(xiàn)。這三種方法的共同點(diǎn)是，它們都用于設(shè)計(jì)，是一組可重用的方法。區(qū)別：前兩者的粒度不同。設(shè)計(jì)模式定義子系統(tǒng)或組件的微觀結(jié)構(gòu)，而架構(gòu)模式從子系統(tǒng)或模塊及其關(guān)系的層次描述粗粒度的解決方案。后兩者的區(qū)別在于前者側(cè)重于描述系統(tǒng)的內(nèi)部組織，而后者側(cè)重于描述結(jié)構(gòu)的外部表現(xiàn)。

為什么移動(dòng)端UI要有設(shè)計(jì)規(guī)范？

您好，我認(rèn)為至少有三個(gè)理由可以說明為什么應(yīng)該有移動(dòng)終端的設(shè)計(jì)規(guī)范。

1. 對(duì)于設(shè)計(jì)師：為后續(xù)版本迭代和多人合作提供指導(dǎo)，保持產(chǎn)品的統(tǒng)一性；由于一個(gè)項(xiàng)目從開始到下一次更新迭代需要很長(zhǎng)時(shí)間，可能會(huì)有很多設(shè)計(jì)師參與，但每個(gè)人的風(fēng)格不同，會(huì)影響整體視覺體驗(yàn)，所以有了規(guī)范，設(shè)計(jì)師就可以在產(chǎn)品視覺上得到統(tǒng)一，便于更新迭代。

2. 對(duì)于開發(fā)：提供標(biāo)準(zhǔn)化的組件樣式以減少開發(fā)重復(fù)時(shí)間。

因?yàn)橛辛艘?guī)范，以后的維護(hù)就方便多了，設(shè)計(jì)師不需要再做標(biāo)記，開發(fā)時(shí)也不需要重新寫樣式，直接修改內(nèi)容。

3. 對(duì)于用戶：符合大眾的視覺體驗(yàn)。因?yàn)楝F(xiàn)實(shí)中，人們?cè)谠O(shè)計(jì)移動(dòng)終端產(chǎn)品時(shí)，在字體、圖標(biāo)間距等方面都有一個(gè)普遍的習(xí)慣

下面的圖是我收集的部分規(guī)范與大家分享，大家一起學(xué)習(xí)