动机 :
Plugin是在软件系统内增加功能的功能。
如果在软件系统加入Plugin功能，能提高软件系统的重用性。
加入Plugin功能的软件系统在开发完成之后。
如果需要额外加入功能，不用变更已完成的软件系统就能加入新功能。
并且因为不用变更已完成的软件系统，也就避免了修改软件系统会产生的风险。
另外在系统里加入Plugin功能，其实会遇到一个问题。
当有多个Plugin内容加入系统的时候，该如何去识别与取得加入的Plugin内容。
本文介绍一个『Service Plugin 模式』，
定义对象之间的职责跟互动，用来实现Plugin提供的功能，并且封装Plugin内容识别与取得的职责。
为自己做个纪录，也希望能帮助到有需要的开发人员。
结构 :
下图是这个模式的示意图，整个看起来有点复杂。
我们将图拆解开来说明，会比较方便了解。
ServiceLIfetime相关对象
首先是ServiceLIfetime相关对象。
这组对象主要功能是，封装Plugin内容的生命周期启动与结束。
至于该启动哪些Plugin内容，则是由外部设定数据来Reflection生成。
主要的参与者有：
ServiceLifetimeContext
-管理所有Plugin内容生命周期的对象。
-使用ServiceLifetimeControlRepository，取得所有提供操作的IServiceLifetimeControl实做。
-操作IServiceLifetimeControl来管理Plugin内容的生命周期。
IServiceLifetimeControl
-提供用来管理Plugin内容的生命周期的操作的接口。
-实做IServiceLifetimeControl接口的对象，用来管理Plugin内容的生命周期。
ServiceLifetimeControlRepository
-取得所有提供操作的IServiceLifetimeControl实做。
-使用外部设定数据来Reflection生成IServiceLifetimeControl实做。
透过下面的图片说明，可以了解ServiceLIfetime相关对象之间的互动流程。
Meteorology Service相关对象
再来是Meteorology Service相关对象
这组对象是封装Plugin内容，并且提供管理Plugin内容生命周期的功能，也实做了Plugin内容识别与取得。
这边使用一个，仿真一个气象数据查询Plugin内容来做说明。
主要的参与者有：
WeatherService
-模拟的Plugin内容，提供询问天气的服务接口。
WeatherServiceHost
-Plugin内容的Singleton实做对象。
-存放WeatherService对象的参考，用来提供类似 Service locator的功能，实做Plugin内容的识别与取得功能。
WeatherServiceLifetimeControl
-实做IServiceLifetimeControl接口的对象。
-提供管理Plugin内容生命周期的功能。
-在建立WeatherService时，将WeatherService对象的参考存放到WeatherServiceHost。
-在释放WeatherService时，将WeatherService对象的参考从WeatherServiceHost移除。
透过下面的图片说明，可以了解Meteorology Service相关对象之间的互动流程。
Meteorology GUI相关对象
最后是Meteorology GUI相关对象
这组对象主要是封装，使用Plugin内容的用户界面。
这个用户接口使用模式中Plugin内容识别与取得功能，取得Plugin内容来使用。
基本上用户界面，要使用一个UI层级Plugin模式来做挂载。
这个部分超过本篇的范围，有兴趣的开发人员可以参考 : [WPF] MVVM Plugin
这边使用一个，仿真一个气象数据查询Plugin内容的用户接口来做说明。
主要的参与者有：
DisplayWeatherPage
-仿真的UI层级Plugin内容，提供显示天气的用户接口。
-使用WeatherService取得天气数据。
DisplayWeatherPageFactory
-建立DisplayWeatherPage的工厂对象。
-透过WeatherServiceHost取得WeatherService，用来建立DisplayWeatherPage。
-这个对象存在的理由，是为了让DisplayWeatherPage移除对于WeatherServiceHost的相依。
透过下面的图片说明，可以了解Meteorology GUI相关对象之间的互动流程。
分析整个模式结构可以发现，
属于UI层级Plugin内容的DisplayWeatherPage，最终只相依属于Service层级Plugin内容WeatherService。
这两个Plugin内容不相依于，模式里实现Plugin职责的对象。
也就是Plugin内容可以独立于整个模式之外，这极大的提高了重用性。
实做 :
范列下载 :
范例的程序代码较多，实做说明请参照范例程序内容。
ServicePluginSample点此下载
范列实做 :
范例内容，实做一个简易的Shell用来提供UI层级Plugin功能。
另外它也套用了『Service Plugin 模式』，让它可以依照配置文件，加入对应的Service提供Plugin UI使用。
透过这个范例，可以清楚的了解如何实做以及执行效果。
实做内容的说明，因为大多已在结构流程图做了说明，这边就不再花费篇幅做介绍。
后记 :
在系统里加入Plugin功能，其实也就是半强迫的将整个系统拆解为片段来做思考设计。
这让开发人员在开发时，缩小了思考范围，隐性的就能提升软件的质量。
并且当开发一个销售周期较长的软件产品时，良好的Plugin功能也提供了后续增加客制化功能的空间。
大量累积一些开发上的优点，能让开发人员准时回家吃晚餐 :D。