從耦合關系談起

　　去年我們組要開發一個新的產品，在討論產品架構路線的時候，美國的架構師向大家征集了架構設計思想（我推薦了SCSF），有一位工程師向他推薦了OSGi。以前我還沒有聽過OSGi這玩意，雖然我參加工作后，現學了Java和Flex，但非常菜。在工作之前我用了4年的.NET。接觸了OSGi后，發現它是一個面向Java的服務規范，還沒有一個像樣的面向.NET的框架（有個EgeyeAddIn，據說兼容OSGi，我看了源代碼了，覺得它離OSGi較遠http://www.codeplex.com/EgeyeAddIn）。隨著對其概念的模糊了解，我覺得這玩意不錯，于是我準備自己做個基于.NET的OSGi框架（因為我在業余的時候在設計一個UI框架，原先準備采用SCSF，接觸了OSGi后，我決定將二者合并，重新設計OSGi+CAB的框架）。于是，我在互聯網找了很多次關于OSGi的資料，但很失望，沒有得到多少需要的東西。因此，我只好自己翻譯了OSGi規范前6章，邊翻譯，邊理解（當我翻譯完第6章的時候，發現網上已經有OSGi規范中文版了，給自己省了點事），期間我翻譯了SCSF英文指南，看了EgeyeAddIn、SharpDeveloper Core和Eclipse OSGi的源代碼，最終設計了基于.NET的OSGi規范和OSGi.NET概要圖，目前OSGi.NET測試版已經完成，預計年底可以發布。因此，對OSGi和SOA有了更深一步的了解。

　　一、上篇回顧

　　通過上篇的簡單講解，我們知道了，組合模式意圖是通過整體與局部之間的關系，通過樹形結構的形式進行組織復雜對象，屏蔽對象內部的細節，對外展現統一的方式來操作對象，是我們處理更復雜對象的一個手段和方式。本文以查詢控件為例，說明了，查詢控件內部的組成元素，及如何操作內部的組成元素，包括添加元素，刪除和處理相應事件的Handler，當然組合模式的作用遠比這些強大，后面我們肯定會在一些實例代碼中運用到組合模式的。組合模式如果在條件允許的情況下，我們盡量使用組合模式來處理復雜對象，遠比通過繼承出來的對象來的有效。

　　使用面向對象語言進行過程式設計的例子，可謂俯拾皆是。看這段代碼：

　　.Net提供了接口，這個不同于Class或者Struct的類型定義。接口有些情況，看似和抽象類一樣，因此有些人認為在.Net可以完全用接口來替換抽象類。其實不然，接口和抽象類各有長處和缺陷，因此往往在應用當中，兩者要結合來使用，從而互補長短。

　　類層次結構的變化

 　　我在閱讀遺留代碼時，經常發現存在這樣一種情形。在一個類中存在兩個方法，它們做了相似的工作，區別僅在于方法內部某些對象的類型。例如：

　　英文原文：Patterns for Continuous Delivery

      我們談云計算SQL Azure本質，我們可以換一個角度先從設計模式上講起。設計模式(Design Pattern)的一項重要目的就是“溝通”當人們談到“歌德式”的設計模式時，腦海里浮現的應該都是一幅很類似的景致，例如：高聳的尖頂建筑、教堂式的外觀門庭……，這是建筑師的設計模式。當然它也成功的融入了大眾的生活層面，而這才可稱為“設計模式”。

　　耦合與變化

系列文章導航：

靜態成員和非靜態成員的區別？

1.    前言

　　1. 從依賴倒置說起

　　一、全文搜索

　　一、開篇

　　本文主要是講述設計模式中最經典的創建型模式-工廠模式，本文將會從以下幾點對工廠模式進行闡述。        　　本文將會從上面的四個方面進行詳細的講解和說明，當然會的朋友可以之處我的不足之處，不會的朋友也請我們能夠相互學習討論。