本文摘自: http://danielzzu.blog.163.com/blog/static/11851530420112311303240/
一、架構是什麼 簡單點說:架構就是能完成一定功能的半成品軟體。 就其本質而言,架構是一個軟體,而且是一個半成品的軟體。所謂半成品,就是還不能完全實現使用者需要的功能,架構只是實現使用者需要的功能的一部分,還需要進一步加工,才能成為一個滿足使用者需要的、完整的軟體。因此架構級的軟體,它的主要客戶是開發人員,而不是終端使用者。 有些朋友會想,既然架構只是個半成品,那何必要去學習和使用架構呢?學習成本也不算小,那就是因為架構能完成一定的功能,也就是這“架構已經完成的一定的功能”在吸引著開發人員,讓大家投入去學習和使用架構。二、架構能幹什麼 架構能完成一定功能,加快應用開發進度 由於架構完成了一定的功能,而且通常是一些基礎的、有難度的、通用的功能,這就避免我們在應用開發的時候完全從頭開始,而是在架構已有的功能之上繼續開發,也就是說會複用架構的功能,從而加快應用的開發進度。 架構給我們一個精良的程式架構 架構定義了應用的整體結構,包括類和對象的分割,各部分的主要責任,類和對象怎麼協作,以及控制流程程等等。現在Java界大多數流行的架構,大都出自大師手筆,設計都很精良。基於這樣的架構來開發,一般會遵循架構已經規劃好的結構來進行開發,從而讓我們開發的應用程式的結構也相對變得精良了。三、對架構的理解 基於架構來開發,事情還是那些事情,只是看誰做的問題 對於應用程式和架構的關係,可以用一個圖來簡單描述一下,如圖1所示:
圖1 應用程式和架構的簡單關係 如果沒有架構,那麼客戶要求的所有功能都由開發人員自己來開發,沒問題,同樣可以實現使用者要求的功能,只是開發人員的工作多點。 如果有了架構,架構本身完成了一定的功能,那麼架構已有的功能,開發人員就可以不做了,開發人員只需要完成架構沒有的功能,最後同樣是完成客戶要求的所有功能,但是開發人員的工作就減少了。 也就是說,基於架構來開發,軟體要完成的功能並沒有變化,還是客戶要求的所有功能,也就是“事情還是那些事情”的意思。但是有了架構過後,架構完成了一部分功能,然後開發人員再完成一部分功能,最後由架構和開發人員合起來完成了整個軟體的功能,也就是看這些功能“由誰做”的問題。 基於架構開發,可以不去做架構所做的事情,但是應該明白架構在幹什麼,以及架構是如何?相應功能的 事實上,在實際開發中,應用程式和架構的關係,通常都不會如上面講述的那樣,分得那麼清楚,更為普遍的是相互互動的,也就是應用程式做一部分工作,然後架構做一部分工作,然後應用程式再做一部分工作,然後架構再做一部分工作,如此交錯,最後由應用程式和架構組合起來完成使用者的功能要求。 也用個圖來說明,如圖2所示:
圖2 應用程式和架構的關係 如果把這個由應用程式和架構組合在一起構成的矩形,當作最後完成的軟體。試想一下,如果你不懂架構在幹什麼的話,相當於架構對你來講是個黑盒,也就是相當於在上面圖2中,去掉架構的兩塊,會發現什嗎?沒錯,剩下的應用程式是支離破碎的,是相互分隔開來的。 這會導致一個非常致命的問題,整個應用是如何運轉起來的,你是不清楚的,也就是說對你而言,項目已經失控了,從專案管理的角度來講,這是很危險的。 因此,在基於架構開發的時候,雖然我們可以不去做架構所做的事情,但是應該搞明白架構在幹什麼,如果條件許可的話,還應該搞清楚架構是如何?相應功能的,至少應該把大致的實現思路和實現步驟搞清楚,這樣我們才能整體的掌控整個項目,才能盡量減少出現項目失控的情況。四、架構和設計模式的關係 設計模式比架構更抽象 架構已經是實現出來的軟體了,雖然只是個半成品的軟體,但畢竟是已經實現出來的了。而設計模式的重心還在於問題的解決方案上,也就是還停留在思想的層面。因此設計模式比架構更為抽象。 設計模式是比架構更小的體繫結構元素 如上所述,架構是已經實現出來的軟體,並實現了一系列的功能,因此一個架構,通常會包含多個設計模式的應用。 架構比設計模式更加特例化 架構是完成一定功能的半成品軟體,也就是說,架構的目的很明確,就是要解決某一個領域的某些問題,那是很具體的功能,不同的領域實現出來的架構是不一樣的。 而設計模式還停留在思想的層面,在不同的領域都可以應用,只要相應的問題適合用某個設計模式來解決。因此架構總是針對特定領域的,而設計模式更加註重從思想上,從方法上來解決問題,更加通用化。