反模式設計

① struts+spring+hibernate分別用到了什麼設計模式

Spring 的AOP 體現了動態代理模式
IOC 是工廠模式
OpenSessionInViewFilter是一種反模式
struts的裡面用到了工廠模式
struts2的攔截器那裡有一個內Proxy也是代理模式
Hibernate沒怎麼分析容過 但是對每個資料庫都適用應該有策略模式

② 軟體架構師需要掌握哪些知識

架構師首先必須具有豐富的開發經驗，是個技術主管。因為他必須清楚什麼是可以實現的，實現的方式有哪些，相應的難度怎麼樣，實現出來的系統面對需求變化的適應性等一系列指標。另外，需要對面向過程、面向對象、面向服務等設計理念有深刻的理解，可以快速的察覺出實現中的問題並提出相應的改進（重構）方案（也就是通常說的反模式）。這些都需要長期的開發實踐才能真正的體會到，單從書本上很難領會到，就算當時理解了也不一定能融會到實踐中去。 在技術能力上，軟體架構師最重要也是最需要掌握的知識是構件通信機制方面的知識，包括進程內通信（對象訪問、函數調用、數據交換、線程同步等）以及進程外（包括跨計算機）的通信（如RMI、DCOM、Web Service）。在WEB應用大行其道的今天，開發者往往對伺服器間的通信關注的比較多，而對進程內的通信較少關注。進程外跨機器通信是構建分布式應用的基石，它是架構設計中的鳥瞰視圖；而進程內的通信是模塊實現的骨架，它是基石的基石。如果具體到一個基於.Net企業級架構設計，首先需要的是語言級別的認識，包括.NET的CLR、繼承特性、委託和事件處理等。然後是常用解決方案的認識，包括ASP.NET Web Service、.NET Remoting、企業服務組件等。總之，豐富的開發實踐經驗有助於避免架構師紙上談兵式的高來高去，給代碼編寫人員帶來實實在在的可行性。 其次，具有足夠的行業業務知識和商業頭腦也是很重要的。行業業務知識的足夠把握可以給架構師更多的擁抱變化的能力，可以在系統設計的時候留出一些擴展的餘地來適應可能來臨的需求變化。有經驗的設計人員可能都碰到過這樣的事，一廂情願的保留介面在需求變化中的命中率非常低。也就是說，在系統設計之初為擴展性留下來的系統介面沒能在需求變化的洪流中發揮真正的作用，因為需求的變化並沒有按照預想的方向進行，到最後還是不得不為變化的業務重新設計系統。這就是因為對業務知識的理解和對市場或者商業的判斷沒有達到一個實用的、可以為架構擴展性服務的水平。 再次，架構設計師對人的關注必須提升到架構設計之初來納入考慮的范圍，包括溝通以及對人員素質的判斷。軟體過程是團隊協作共同構建系統的過程，溝通能力是將整個過程中多條開發線粘合在一起的膠水。大家都應該碰到過事後說「原來是這樣啊，我不知道啊」或者某個開發人員突然高聲呼喊「為什麼這里的數據沒有了」之類的。溝通的目的就是盡量避免多條開發線的混亂，讓系統構建過程可以有條理的高效進行。另外，對人的關注還表現在對團隊成員的素質判斷上，比如哪些開發人員對哪些技術更熟悉，或者哪些開發人員容易拖進度等。只有合理的使用人力資源，讓合適的人做合適的事情才能讓整個軟體過程更加高效。 架構師應時刻注意新軟體設計和開發方面的發展情況，並不斷探索更有效的新方法、開發語言、設計模式和開發平台不斷很快地升級，軟體架構師需要吸收這些新技術新知識，並將它們用於軟體系統開發工作中。但對新技術的探索應該在一個理性的范圍內進行，不能盲目的跟風。解決方案提供商永遠都希望你能使用它提供的最新技術，而且它們在推廣自己的解決方案的時候往往是以自己的產品為中心，容易給人錯覺。比如資料庫，往往讓人覺得它什麼都能做，只要有了它其它什麼都不重要了。但事實上並不是如此，對於小型應用可以將許多業務邏輯用script的方式放入資料庫中，但很少看到大型應用採用這樣的做法。對於新東西需要以一種比較的觀點來判斷，包括橫向的比較和縱向的比較，最後得出一些性能、可移植性以及可升級等指標。另外，新入行的開發人員往往關心新技術動向而忽略了技術的歷史，而從DOS時代一路殺過來的開發者就對現在的技術體系有較全面的把握。

③ WEB UI設計師都看什麼書

一、《眾妙之門——網站UI設計之道2》

來自全球的知務設計師無私地分享了他們多年積累的寶貴經驗。書中涵蓋了網站UI設計相關的不同的領域，覆蓋面非常廣，具有很強的操作性和專業性。全書邏輯嚴密、言簡意賅，設計人員可以快速地找到自己想要的東西。

二、《認知與設計:理解UI設計准則(UI領域大師力作)》

張一寧 自稱「一個認為寫代碼就是做與人打交道的設計的工程師」。擁有二十多年編程經驗，從事過系統集成、金融行業應用的中間件和服務產品的研發，以及電信與互聯網服務的開發和管理。

三、《移動應用UI設計模式(簡易的UI模式參考書)》

《移動應用ui設計模式》是一本移動應用ui 設計模式參考書，分10 大類介紹了70 個移動應用設計模式（包括反模式），用400 多個屏幕截圖和圖解幫助讀者理解和利用ui 設計模式，以解決常見的設計難題，同時提供了「即學即用」式的技巧和經驗。

四、《用戶體驗要素:以用戶為中心的產品設計(原書第2版)(UI設計叢書)(全彩印刷)》

《用戶體驗要素:以用戶為中心的產品設計(原書第2版)》用清晰的說明和生動的圖形分析了以用戶為中心的設計方法（ucd）來進行網站設計的復雜內涵，並關注於思路而不是工具或技術，從而使你的網站具備高質量體驗的流程。

五、《UI進化論：移動設備人機交互界面設計（國際著名界面設計師瀝血之作！全彩印刷，正文銅版紙）》

④ 大話設計模式中哪些模式比較重要

應該來說，大話設計模式或者其他類似設計模式中的模式沒有哪個是更重要的。只專能說各自的適屬用場合或解決的問題有差別而已。

而且，學習這些設計模式的書籍，最重要的不是掌握哪幾個設計模式，而是理解設計模式的本質，從而在今後的軟體開發中可以靈活的運用相關模式，創造更加合適的模式，甚至如果有必要，採用反模式。

⑤ 介紹幾本關於UI設計的書籍

設計個QQ表情，可以用ui來實現；設計個微信小程序，也可以用ui做；做個海報，也是缺不了；還有我們鍾愛的「農葯」，更是仰仗UI……可謂是，ui的用處是很多的，你是不是也想找UI設計入門的圖書學習下？
UI設計近幾年發展時態一片良好，ui設計師也順勢成了熱門行業，但是行業專業技能人才還是很缺失的，所以我們需要必要的充電。在這里小編整理了一些UI設計入門書籍，希望能幫到大家。
Ui設計入門數據推薦：
《Photoshop CS6平面設計自學視頻教程》
本書書共分為24章，在內容安排上基本涵蓋了平面設計中所使用到的全部工具與命令。其中前16章主要從平面設計的角度出發，循序漸進地詳細講解了Photoshop的相關知識，主要內容包括Photoshop的基本操作、圖像編輯、選區的編輯與應用、文字的應用、矢量工具與形狀、圖層的相關知識、蒙版、通道、濾鏡、Web圖形處理與自動化操作等核心功能與應用技巧。《Photoshop CS6平面設計自學視頻教程》後8章則從Photoshop在平面設計中的實際應用出發，著重針對標志設計、海報招貼設計、版式與書籍裝幀設計、包裝設計和創意合成等8個方面進行案例式的針對性和實用性實戰練習，不僅使讀者鞏固了前面學到的Photoshop中的技術技巧，更是為讀者在以後實際學習工作進行提前「練兵」。
《UI設計手繪表現從入門到精通》
以UI設計為核心，系統全面地講解了UI設計手繪各個方面的知識。全書分為9章，第1章介紹了UI設計概論；第2章介紹了UI設計手繪基礎；第3章介紹了UI設計材質表現；第4章介紹了UI中基本元素的表現；第5章介紹了UI圖標設計；第6章介紹了網站UI設計；第7章介紹了游戲界面設計；第8章介紹了數碼產品主題界面設計；第9章為作品賞析，搜集了一些好的UI設計作品，以供讀者參考學習。
《Photoshop移動UI設計從入門到精通》
內容包括：移動UI的設計常識，移動UI設計的布局原則，移動UI視覺交互設計法則，移動UI的構成元素，Photoshop移動UI快速上手，UI的色彩與風格設計，移動UI文字的編排設計，移動UI圖像的摳取與合成，移動UI圖像特效質感設計，圖標、圖形、按鈕設計，常見蘋果系統UI設計，常見安卓系統UI設計，常見微軟系統UI設計，社交與免費WiFi登錄UI設計，影音與游戲UI設計。全書使用自帶素材，通過對素材的不同處理，製作出精美的界面效果。製作界面過程已被錄制為視頻，刻錄為光碟，在手機與網路中進行分享，讀者學後可以融會貫通、舉一反三，從而完成自己的作品。
新入門的朋友可以線上商城查看，當然，還需要大家了解一些關於軟體使用的書籍，上網查一下很多官網商店都有推薦。PS，AI等。
然後關於自學的問題，自學軟體的使用，基本上是沒有問題的，主要是產品問題。自學的學員大多存在的一個問題就是脫軌，閉門造車大家都聽過吧，大概就是這種感覺，而且自己心裡也沒底，不知道自己學到的有沒有實際作用。

⑥ 什麼是網站架構師

網站架構師是網站系統、功能、模塊、流程的設計師，架構師，好比版是高樓大廈的設計人權員，通常一座大廈在建之前，都先由設計師將藍圖描繪出來，包括其形狀、結構、尺寸、材料等等，然後建築工程師帶領工人們按照藍圖將大廈一層一層地建起來。

架構師首先必須具有豐富的開發經驗，是個技術主管。因為他必須清楚什麼是可以實現的，實現的方式有哪些，相應的難度怎麼樣，實現出來的系統面對需求變化的適應性等一系列指標。另外，需要對面向過程、面向對象、面向服務等設計理念有深刻的理解，可以快速的察覺出實現中的問題並提出相應的改進（重構）方案（也就是通常說的反模式）。
在技術能力上，軟體架構師最重要也是最需要掌握的知識是構件通信機制方面的知識。

⑦ 如何系統地進行架構和應用設計

軟體架構設計的目的 對於外包業務類型的項目，軟體架構設計的目的與產品類型的項目有所不同，在這里主要討論外包類型項目的軟體架構設計目的。 1、為大規模開發提供基礎和規范，並提供可重用的資產，軟體系統的大規模開發，必須要有一定的基礎和遵循一定的規范，這既是軟體工程本身的要求，也是客戶的要求。架構設計的過程中可以將一些公共部分抽象提取出來，形成公共類和工具類，以達到重用的目的。 2、一定程度上縮短項目的周期，利用軟體架構提供的框架或重用組件，縮短項目開發的周期。 3、降低開發和維護的成本，大量的重用和抽象，可以提取出一些開發人員不用關心的公共部分，這樣便可以使開發人員僅僅關注於業務邏輯的實現，從而減少了很多工作量，提高了開發效率。 4、提高產品的質量，好的軟體架構設計是產品質量的保證，特別是對於客戶常常提出的非功能性需求的滿足。 軟體架構設計的原則 軟體架構設計必須遵循以下原則： 1、滿足功能性需求和非功能需求。這是一個軟體系統最基本的要求，也是架構設計時應該遵循的最基本的原則。 2、實用性原則，就像每一個軟體系統交付給用戶使用時必須實用，能解決用戶的問題一樣，架構設計也必須實用，否則就會「高來高去」或「過度設計」。 3、滿足復用的要求，最大程度的提高開發人員的工作效率。 軟體架構設計的幾種視圖 我們常常在討論架構設計該做些什麼的時候，或是在架構設計評審的會議上，會提出各種各樣的問題，例如開發人員該如何記錄Log，事務如何控制？怎樣才能提高我們的開發人員的工作效率，即在單位時間內更有品質的完成更多的功能？怎樣滿足客戶的非功能性需求？怎樣讓生產環境的平台管理人員更好的維護系統？ 上面這些問題，實際上是軟體系統的不同的干係人站在不同的角度上提出的問題，要回答上面這些問題，我們就得從不同的視角來看待軟體架構設計這項工作。 1、邏輯架構視角，從系統用戶的角度考慮問題，設計出來的軟體架構能夠滿足業務邏輯的需求，能夠處理現在越來越復雜的業務邏輯需求。 2、開發架構視角，從系統開發人員的角度來考慮問題，設計的架構要易於理解，易於開發，易於單元測試，最好做到讓開發人員可以用最少的代碼行數完成功能的開發。 3、運行架構視角，從系統運行時的質量需求考慮問題，特別關注於系統的非功能需求，客戶常常都會要求我們系統的功能畫面的最長響應時間不超過4秒，能滿足2000個用戶同時在線使用，基於角色的系統資源的安全控制等。 4、物理架構視角，關注系統安裝和部署在什麼樣的環境上，例如現在最流行的企業應用服務解決方案IBM Http Server ＋ WebSphere Application Server ＋ DB2，WebLogic + Oracle等。 5、數據架構視角，如今我們開發的各類系統，如MIS，ERP，SAP，基本上都是對各類數據的操作，把一堆不太好懂的數據展現成用戶容易看懂的數據，自動處理各類數據的運算等，所以數據的持久化是十分重要的一件事情。1、分析需求和理解業務模型（或領域建模），並選定關鍵Use case。 軟體的需求，可以分為從用戶視角和開發人員視角來看，從用戶的角度看，又可以分為功能性和非功能性需求，我們必須從不同的視角和級別去全面的認識需求並分析需求，理解業務模型。實踐表明，常常被我們忽視的非功能性需求常常會導致整個項目失敗。 理解業務需求最好的方式莫過於進行領域建模，領域建模與需求分析往往是交替穿叉進行的，領域建模主要有以下三個方面的作用： ◆探索復雜問題，弄清領域知識。Martin Fowler曾經說過，他採用面向對象方法最大的好處就是它有助於解決更為復雜的問題。領域建模本身作為輔助思維的工具，幫助我們將注意力始終保持在最為重要的業務概念及其關繫上，使我們能夠不斷深入地，系統的對需求進行分析和認識。領域建模往往是一個從模糊到清晰，從零散到系統的過程。 ◆決定功能范圍，影響可擴展性。任何模型都是對現實世界某種程序的抽象，這種抽象就會忽略某一些東西，例如忽略對象的屬性和對象間的關系，而這些忽略往往都是帶有一定的目的性的，這種忽略就決定了功能的范圍。模型揭示了各種功能背後的結構，如果說定義功能相當於「拍照片」的話，那麼領域建模就相當於「做透視」，更加關注問題領域的內在結構，相當於對問題領域進行了一定的抽象，良好的領域模型不僅能很好的支持現有的功能，而且還可以在一定程度上支持未來可能出現的新需求，體現良好的可擴展性。 ◆提供交流基礎，促進有效溝通。領域建模通常會使用UML圖作為呈現的方式，這樣為我們的溝通提供了方便。當然，有時候文字在描述某些特定領域的問題時可能更適合，可以靈活運用。 在我們公司的實際軟體開發流程中，往往領域建模缺少這一環節，這可能是在以後的工作中需要進一步提高之處。 雖然我們總是期望架構設計師能全面掌握需求，但由於時間和精力的限制，擺在我們面前的現實就是架構設計師沒有時間對所有需求進行深入分析，所以我們的策略就是「把好鋼用在刀刃上」，即把大部分時間和精力花在對決定架構最重要的關鍵需求上。在選擇關鍵需求時要注意：高優先順序的需求往往是從用戶的角度來看的，可能並不是真正的關鍵需求。在《RUP實踐者指南》一書中向我們講述了如何確定關鍵功能需求？A.作為應用程序的核心或實現了系統的主要介面的功能，B.必須被實現的功能，即如果這些功能不被實現，則開發出來的軟體就失去了價值，C.覆蓋了系統架構的一些方面，但沒有被其他重要的Use case覆蓋到的功能。 2、分別從各個視角來考慮軟體架構的方方面面。 軟體的架構設計必須考慮到各方面，根據前期工作確立的領域模型，關鍵需求，系統約束等進行設計，必須從系統用戶，開發人員，系統管理員，部署管理員，數據管理員等人員的角度去分析並解決問題。比如說，如果我們的運行架構採用Cluster方式時，就必須小心Cache和Session等的使用；如果我們的業務邏輯要求我們要操作多個資料庫時，就要考慮採用支持二階段事務提交的方式。 只有將這些方方面面的問題都考慮到了，這樣的架構設計才是完整的。至於每一個視圖中，我們應該設計到什麼細節這一問題，實際上與整個項目的過程定義有關。例如，如果我們有專門安排資料庫概要設計的活動，那我們在架構設計的過程中就可以只需要關注更高層次的資料庫特性及資料庫之間的關系，而每一張表的數據字典可以在後續的相關活動中進行設計，但如果沒有這樣的活動，那我們就要細化到每一張表的每一個欄位，以及表之間的關系。 3、解決技術面的重點問題和難題 在軟體架構設計的過程中，我們往往會需要攻克一些技術面的重點問題和難題，這完全是一項極其需要扎實的理論知識和豐富的實踐經驗支撐的工作。例如，我們如何提高整個系統的性能？如何能很好的導出極其復雜的「中國式報表」（一般比西方國家產出的報表要復雜很多，而且很多開源的BI類的框架並不能完全解決問題）？ 當遇到確實是很困難的問題，可以去網路一下或Google一下，也可以去請教公司的資深技術人員或專家，或者召開小范圍的技術專題討論會議，採用腦力激盪的方法試著找找答案，這樣才能提高工作的效率。 4、召開架構設計評審會議進行同行評審。 架構設計評審是極其重要的一環，我曾將其形容為「七種武器」中的離別鉤，就是因為在會議上，同行們可能會提很多問題或意見，而且很多意見很尖銳，所以一定要虛心接受，並做好記錄，正所謂「良葯苦口利於病，忠言逆耳利於行」。 在評審會議之前，我們要完成很多准備工作，最好是能准備一份簡明扼要的電子簡報，把最重要的問題列出來，這樣在進行評審會議時，就不會漫無目的，在會議前就將這些資料發給與會人員，請他們抽空先了解一下，在會議進行時，要學會控制會議的進度，提高會議的效率。 5、針對關鍵Use case在設計的架構上實現功能來驗證架構。 對於架構設計的驗證也是一項十分重要的工作，其驗證技術有很多種，在我們公司通常會採用Sample的形式，即XP中所說的迭代0，RUP中所說的切片。這樣做的好處是既可以從實際的產品角度出發來有效的驗證架構是否滿足要求，又可以比拋棄型原型驗證技術節省成本。 這個Sample絕不是我們在解決架構設計中的問題時拿來做實驗的一些代碼的拼湊，而是完整的實現某一關鍵Use case的符合架構設計和一系列規范的可交付的代碼及相關文檔。同時，這個Sample可以作為你在給大家講解或培訓架構時的教材，也可以作為開發人員使用此架構進行開發的藍本，甚至是只需要復制粘貼，加上簡單的修改即可。 6、交付給客戶Review。 這一環節，在很多公司可能並不存在，因為他們的軟體架構並不一定需要客戶Review，但像我們這種做服務的公司，最重要的就是客尊，落實到軟體架構設計這一活動，就是讓客戶理解並接受你的架構設計方案，同時，客戶也會起到幫你驗證架構的作用。通常，我們的架構得到客戶的認可後，便可進入大規模的開發。 在交付給客戶Review時，通常可能會以會議的形式進行Review，所以我們可以參照評審會議時好的做法來召開會議，在這里就不再冗述。軟體架構設計的常見誤區及解決辦法 1、架構設計的常常會「高來高去」。所謂高來高去，實際上就是我們的架構設計僅停留在模型階段，但也絕不是產生第一支樣常式式。 2、架構設計時常常會在某些方面過度設計（Over engineering）。為了一些根本不會發生的變化而進行一系列復雜的設計，這樣的設計就叫過度設計，往往會帶來資源的浪費並且會增加開發的工作量或難度。雖然我們必須考慮到系統的擴展性，可維護性等，但切忌過度設計。有時候或許你並不能判斷出哪些設計是過度設計，此時你可以請教你的PM，讓他站在整個項目的高度來幫你決策一下。 3、架構（Architecture）不是框架(Framework)，也不是簡單的將幾種框架或技術的組合，框架本身也是有架構的。框架一般是針對於某一方面或領域的重用性和可擴展性非常好的半成品，我們可以用一句較為經典的話來總結：框架是軟體，架構不是軟體，框架是一種特殊的軟體。我們在工作中通過將許多方面的可重用的工具類，公共類，基礎類等抽象出來，即可形成一些可重用的框架。 4、架構設計絕不是新技術展示平台，合適的技術才是對於項目有利的技術，必須考慮到開發人員的能力和維護人員的能力。作為一名架構設計師應該更多的考慮如何平衡業務需求，織織運作（主要指團隊中的協作）和技術三者的關系，而不僅僅是去關注那些技術細節。 5、架構設計的成功與否決定著系統品質的好壞，因為架構設計不好而導致交付的系統Bug過多，無法滿足客戶非功能性需求等問題，從而導致項目取消的案例時有發生。架構設計不是架構設計師一個人的事情，也不是幾天就能完成的一項工作，必須是架構設計師付出大量辛勤勞動後的成果，其成敗往往與組織、主管、項目經理的支持有著密切的關系。 關於架構設計的一點通用技巧 1、分層（Layer）規則。這里的層是指邏輯上的層次（Layer），並非指物理上的層次（Tier）。目前的絕大多數的企業級應用系統中都分為三層，即表現層，領域層和數據層。在對各層次進行劃分時，主要可以從以下幾個方面來考慮：A、每一層是一個相對獨立的部分，可以作為一個整體，無需對其它層了解；B、將層次間的依賴性降到最低，即降低耦合；C、可以從某種程度上替換掉某一層，而對其它層不會產生過多的影響；D，層次並不能封閉所有的東西，假如用戶界面上增加了一個欄位，那麼領域層就要增加一個數據域，數據層就要增加一個相應的欄位。同時，過多的分層可能會對性能造成一定的影響。 2、包（package）之間不要產生循環依賴。通常包的劃分會先按不同的邏輯層來劃分，在層的包下面再按功能來劃分。避免包間的循環依賴是一個比較通用的規則，這樣的規則一定有其存在的價值和道理，之所以這樣主要是出於以下原因：A、循環依賴會使分層失去意義；B、循環依賴會帶來許多潛在的風險，如可能會產生嵌套事務（nested transaction，JavaEE標准中並不支持這種事務）的現象，我就曾遇到過這樣的問題，在一個項目中，事務放在業務邏輯層統一控制，但由於開發人員忽視了架構中這樣的原則，在持久層調用了展現層的公用類，形成了迴圈的現象，導致了嵌套事務的發生。 3、設計模式的應用。在很多人的觀念里，提供設計模式就等同於GOF的設計模式，其實設計模式是個廣泛的概念，比如需求模式、領域模式、反模式等都屬於設計模式。模式其實是一門工具，是人們對於過去解決某一類問題的經驗總結，所以我們可以在設計活動中應用各種設計模式，但是在應用這些模式之前一定要先分析清楚問題，否則就可能出現「牛頭不對馬嘴」的現象。 成功的項目總有相似之處，失敗的項目卻各有各的失敗之處。好的軟體架構設計必定是成功項目的相似之處，我們有什麼理由不把軟體架構設計做好了？

⑧ 反模式的設計反模式

反抽象：需要的功能並不暴露給用戶，導致用戶要在較高層次重新實現一些功能。
四不像：往往一個設計模型可以暴露不同的介面給用戶，不同的介面表現了模型的不同方面。然而把不同方面的功能混在一起是常見的不良設計。
亂麻球：系統沒有可辨認的結構，就像一團亂麻一樣。
萬應靈：一個對象了解的東西太多，或者要做太多的事情，就好像無所不能一樣。
屠龍術：沒有必要的復雜設計。
競爭危害(Race Hazard): 缺乏預見事件以不同順序發生的後果。
面向對象設計上的反模式
萬能類︰在一個類的設計中，聚集了太多的函數。
吵鬧鬼︰建立某對象的目的只是為了傳送訊息給其它的物件。
溜溜問題︰因結構（例如繼承）極度破碎冗長，而必須花費極大力氣來了解它。

⑨ 響應式用戶界面與設計模式 是什麼書

本書是Andriod UI設計領域的經典著作，Amazon五星級暢銷書。不僅從Android應用設計者的角度系統講解了要從事Android UI設計必須要掌握的Android平台的所有技術和特性，還從Android應用開發者的角度全面總結了Android UI設計的方法、技巧、模式、反模式，以及如何實現響應式用戶界面設計。本書共21章，分為四部分。第一部分（第1～4章）講述用戶界面設計、用戶界面設計的工具、移動設備和觸摸設備的設計，並探討Android平台；第二部分（第5～11章）介紹 Android的應用架構和在線指南、Android的意圖系統、Android應用的導航結構、主界面應用小部件、通知、物理按鍵、輸入法和感測器設計，以及平台用戶界面組件設計；第三部分（第12～16章）討論 Android資源的管理、Android應用的布局、可縮放的圖形、響應式設計，以及如何實現響應式用戶界面；第四部分（第17～21章）闡述用戶界面設計模式、用戶操作設計模式、導航和布局設計模式、數據設計模式以及用戶界面設計的反模式。

⑩ 軟體設計模式的相近術語

對某個問題經常出現的、在設計中應該盡量避免的、壞的設計方案被稱為反模式。 基礎模式
委託模式
介面模式
代理模式 抽象工廠模式(Abstract Factory) ,提供一個創建一系列相關或相互依賴對象的介面，而無需指定它們具體的類。
生成器模式 (Builder)，將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。
工廠方法模式(Factory Method) ，定義一個用於創建對象的介面，讓子類決定將哪一個類實例化。Factory Method使一個類的實例化延遲到其子類。
原型模式 (Prototype) ，用原型實例指定創建對象的種類，並且通過拷貝這個原型來創建新的對象。
單例模式(Singleton)，保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。 適配器模式 (Adapter) ，將一個類的介面轉換成客戶希望的另外一個介面。Adapter模式使得原本由於介面不兼容而不能一起工作的那些類可以一起工作。
橋接模式(Bridge) ，將抽象部分與它的實現部分分離，使它們都可以獨立地變化。
組合模式(Composite) ，將對象組合成樹形結構以表示「部分-整體」的層次結構。它使得客戶對單個對象和復合對象的使用具有一致性。
容器模式
修飾模式 (Decorator) ，動態地給一個對象添加一些額外的職責。就擴展功能而言， 它比生成子類方式更為靈活。
擴展性模式
外觀模式
享元模式
管道與過濾器模式
代理模式(Proxy) ，為其他對象提供一個代理以控制對這個對象的訪問。 責任鏈模式 (Chain of Responsibility) ，為解除請求的發送者和接收者之間耦合，而使多個對象都有機會處理這個請求。將這些對象連成一條鏈，並沿著這條鏈傳遞該請求，直到有一個對象處理它。
命令模式 (Command) ，將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日誌，以及支持可取消的操作。
柯里化模式
事件監聽器模式
解釋器模式
迭代器模式
中介者模式
備忘錄模式 (Memento) ，在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。這樣以後就可將該對象恢復到保存的狀態。
觀察者模式(Observer) ，定義對象間的一種一對多的依賴關系,以便當一個對象的狀態發生改變時,所有依賴於它的對象都得到通知並自動刷新。
狀態模式 (State) ，允許一個對象在其內部狀態改變時改變它的行為。對象看起來似乎修改了它所屬的類。
策略模式 (Strategy) ，定義一系列的演算法,把它們一個個封裝起來, 並且使它們可相互替換。本模式使得演算法的變化可獨立於使用它的客戶。
模板方法模式
訪問者模式 (Visitor)，表示一個作用於某對象結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。
層次訪問者模式 模式 Action at a distance
模式 Balking
模式 Guarded suspension
模式 Scheler
模式 Read write lock
模式 Double checked locking
模式 Disable job requests while running job 模式 Scheled task
模式 User interface
模式 Disable job requests while running job 此原則是由Bertrand Meyer提出的。原文是：Software entities should be open for extension,but closed for modification。就是說模塊應對擴展開放，而對修改關閉。模塊應盡量在不修改原(是原，指原來的代碼)代碼的情況下進行擴展。那麼怎麼擴展呢？我們看工廠模式factory pattern:假設中關村有一個賣盜版盤和毛片的小子，我們給他設計一光碟銷售管理軟體。我們應該先設計一光碟介面。如圖：【pre】______________|<>|| 光碟 ||_____________||+賣() || ||_____________|【/pre】而盜版盤和毛片是其子類。小子通過DiscFactory來管理這些光碟。代碼為： publicclassDiscFactory{publicstatic光碟getDisc(Stringname){return(光碟)Class.forName(name).getInstance();}}有人要買盜版盤，怎麼實現呢？
public class 小子{ public static void main(String【】 args){ 光碟 d=DiscFactory.getDisc(盜版盤); 光碟.賣(); } }
如果有一天，這小子良心發現了，開始賣正版軟體。沒關系，我們只要再創建一個光碟的子類正版軟體就可以了。不需要修改原結構和代碼。怎麼樣？對擴展開放，對修改關閉。開-閉原則 工廠模式是對具體產品進行擴展，有的項目可能需要更多的擴展性，要對這個工廠也進行擴展，那就成了抽象工廠模式。 就是說要少用繼承，多用合成關系來實現。我曾經這樣寫過程序：有幾個類要與資料庫打交道，就寫了一個資料庫操作的類，然後別的跟資料庫打交道的類都繼承這個。結果後來，我修改了資料庫操作類的一個方法，各個類都需要改動。牽一發而動全身!面向對象是要把波動限制在盡量小的范圍。
在Java中，應盡量針對Interface編程，而非實現類。這樣，更換子類不會影響調用它方法的代碼。要讓各個類盡可能少的跟別人聯系，不要與陌生人說話。這樣，城門失火，才不至於殃及池魚。擴展性和維護性才能提高
理解了這些原則，再看設計模式，只是在具體問題上怎麼實現這些原則而已。張無忌學太極拳，忘記了所有招式，打倒了玄冪二老，所謂心中無招。設計模式可謂招數，如果先學通了各種模式，又忘掉了所有模式而隨心所欲，可謂OO之最高境界。呵呵，搞笑，搞笑！（JR）
依賴倒轉原則抽象不應該依賴與細節，細節應當依 類為子類繼承，一般包含這個系的共同屬性和方法。注意：好的繼承關系中，只有葉節點是具體類，其他節點應該都是抽象類，也就是說具體類是不被繼承的。將盡可能多的共同代碼放到抽象類中。 7 迪米特法則最少知識原則。不要和陌生人說話。