最近换了一份新工作,全新的开始,一切还在奋斗的道路上,自己给自己打个气!
设计模式系列很久没有更新了,废话不多说,开始今天的桥接模式。
定义:
何为Bridge模式?我们知道,实现与抽象之间总是存在着强依赖,Bridge模式的意义就是解耦实现与抽象,这意味着实现与抽象不再有着静态的依赖关系,它们彼此可以拥有独立的变化,从而互不影响。
Nothing happened !
最近换了一份新工作,全新的开始,一切还在奋斗的道路上,自己给自己打个气!
设计模式系列很久没有更新了,废话不多说,开始今天的桥接模式。
何为Bridge模式?我们知道,实现与抽象之间总是存在着强依赖,Bridge模式的意义就是解耦实现与抽象,这意味着实现与抽象不再有着静态的依赖关系,它们彼此可以拥有独立的变化,从而互不影响。
老骥伏枥,志在千里;烈士暮年,壮心不已。
起伏间,已然离开软件行业八月有余,斯余生不知是否仍有机遇重返程序员行列,遂作《设计模式》系列以祭之。
在上世纪的经典设计模式著作《设计模式 可复用面向对象软件的基础》中将设计模式进行了3个层面的划分,它们分别是创建型设计模式(Creational patterns)、结构型设计模式(Structural patterns)和行为型设计模式(Behavioral patterns),在本系列中我也将按照这种方式去划分。至于为什么选择设计模式去纪念过去十年的编程岁月,下面是鄙人一些心得体会,与大家分享:
下面来列一下本系列的文章大纲,总计约23篇设计模式文章,我应当每月会更新一篇,也就总计需要两年时间,希望在那最终完成时,自己还能保持着这份程序员的热情。
创建型模式,共有五篇。
结构型模式,共有七篇。
行为型模式,共有十一篇。
MVVM是Model-View-ViewModel的简写。
微软的WPF带来了新的技术体验,如Sliverlight、音频、视频、3D、动画……,这导致了软件UI层更加细节化、可定制化。同时,在技术层面,WPF也带来了 诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM(Model-View-ViewModel)框架的由来便是MVP(Model-View-Presenter)模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性揉合进去,以应对客户日益复杂的需求变化。
WPF的数据绑定与Presentation Model相结合是非常好的做法,使得开发人员可以将View和逻辑分离出来,但这种数据绑定技术非常简单实用,也是WPF所特有的,所以我们又称之为Model-View-ViewModel(MVVM)。这种模式跟经典的MVP(Model-View-Presenter)模式很相似,除了你需要一个为View量身定制的model,这个model就是ViewModel。ViewModel包含所有由UI特定的接口和属性,并由一个 ViewModel 的视图的绑定属性,并可获得二者之间的松散耦合,所以需要在ViewModel 直接更新视图中编写相应代码。数据绑定系统还支持提供了标准化的方式传输到视图的验证错误的输入的验证。
在视图(View)部分,通常也就是一个Aspx页面。在以前设计模式中由于没有清晰的职责划分,UI 层经常成为逻辑层的全能代理,而后者实际上属于应用程序的其他层。MVP 里的M 其实和MVC里的M是一个,都是封装了核心数据、逻辑和功能的计算关系的模型,而V是视图(窗体),P就是封装了窗体中的所有操作、响应用户的输入输出、事件等,与MVC里的C差不多,区别是MVC是系统级架构的,而MVP是用在某个特定页面上的,也就是说MVP的灵活性要远远大于MVC,实现起来也极为简单。
我们再从IView这个interface层来解析,它可以帮助我们把各类UI与逻辑层解耦,同时可以从UI层进入自动化测试(Unit/Automatic Test)并提供了入口,在以前可以由WinForm/Web Form/MFC等编写的UI是通过事件Windows消息与IView层沟通的。WPF与IView层的沟通,最佳的手段是使用Binding,当然,也可以使用事件;Presenter层要实现IView,多态机制可以保证运行时UI层显示恰当的数据。比如Binding,在程序中,你可能看到Binding的Source是某个interface类型的变量,实际上,这个interface变量引用着的对象才是真正的数据源。
MVC模式大家都已经非常熟悉了,在这里我就不赘述,这些模式也是依次进化而形成MVC—>MVP—>MVVM。有一句话说的好:当物体受到接力的时候,凡是有界面的地方就是最容易被撕下来的地方。因此,IView作为公共视图接口约束(契约)的一层意思;View则能传达解耦的一层意思。
因为WPF技术出现,从而使MVP设计模式有所改进,MVVM 模式便是使用的是数据绑定基础架构。它们可以轻松构建UI的必要元素。
可以参考The Composite Application Guidance for WPF(prism)
View绑定到ViewModel,然后执行一些命令在向它请求一个动作。而反过来,ViewModel跟Model通讯,告诉它更新来响应UI。这样便使得为应用构建UI非常的容易。往一个应用程序上贴一个界面越容易,外观设计师就越容易使用Blend来创建一个漂亮的界面。同时,当UI和功能越来越松耦合的时候,功能的可测试性就越来越强。
在MVP模式中,为了让UI层能够从逻辑层上分离下来,设计师们在UI层与逻辑层之间加了一层interface。无论是UI开发人员还是数据开发人员,都要尊重这个契约、按照它进行设计和开发。这样,理想状态下无论是Web UI还是Window UI就都可以使用同一套数据逻辑了。借鉴MVP的IView层,养成习惯。View Model听起来比Presenter要贴切得多;会把一些跟事件、命令相关的东西放在MVC的’C’,或者是MVVM的’Vm’
MVVM模式和MVC模式一样,主要目的是分离视图(View)和模型(Model),有几大有点:
使用MVVM来开发用户控件[1]。由于用户控件在大部分情况下不涉及到数据的持久化,所以如果将M纯粹理解为DomainModel的话,使用MVVM模式来进行自定义控件开发实际上可以省略掉M,变成了VVM。
我一直很难理解Javascript语言的继承机制。
它没有”子类”和”父类”的概念,也没有”类”(class)和”实例”(instance)的区分,全靠一种很奇特的”原型链”(prototype chain)模式,来实现继承。
我花了很多时间,学习这个部分,还做了很多笔记。但是都属于强行记忆,无法从根本上理解。
直到昨天,我读到法国程序员Vjeux的解释,才恍然大悟,完全明白了Javascript为什么这样设计。
下面,我尝试用自己的语言,来解释它的设计思想。彻底说明白prototype对象到底是怎么回事。其实根本就没那么复杂,真相非常简单。
在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作;同时由于需求的变化,往往存在着更多系列对象的创建工作。如何应对这种变化?如何绕过常规的对象的创建方法(new),提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合?这就是我们要说的抽象工厂模式。
提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。
逻辑模型:
概述
Singleton模式要求一个类有且仅有一个实例,并且提供了一个全局的访问点。这就提出了一个问题:如何绕过常规的构造器,提供一种机制来保证一个类只有一个实例?客户程序在调用某一个类时,它是不会考虑这个类是否只能有一个实例等问题的,所以,这应该是类设计者的责任,而不是类使用者的责任。
从另一个角度来说,Singleton模式其实也是一种职责型模式。因为我们创建了一个对象,这个对象扮演了独一无二的角色,在这个单独的对象实例中,它集中了它所属类的所有权力,同时它也肩负了行使这种权力的职责!
意图
保证一个类仅有一个实例,并提供一个访问它的全局访问点。
模型图
逻辑模型图:
物理模型图:
生活中的例子
美国总统的职位是Singleton,美国宪法规定了总统的选举,任期以及继任的顺序。这样,在任何时刻只能由一个现任的总统。无论现任总统的身份为何,其头衔”美利坚合众国总统”是访问这个职位的人的一个全局的访问点。
五种实现
1.简单实现
public sealed class Singleton { static Singleton instance=null; Singleton() { } public static Singleton Instance { get { if (instance==null) { instance = new Singleton(); } return instance; } } }
这种方式的实现对于线程来说并不是安全的,因为在多线程的环境下有可能得到Singleton类的多个实例。如果同时有两个线程去判断(instance == null),并且得到的结果为真,这时两个线程都会创建类Singleton的实例,这样就违背了Singleton模式的原则。实际上在上述代码中,有可能在计算出表达式的值之前,对象实例已经被创建,但是内存模型并不能保证对象实例在第二个线程创建之前被发现。
该实现方式主要有两个优点:
2.安全的线程
public sealed class Singleton { static Singleton instance=null; static readonly object padlock = new object(); Singleton() { } public static Singleton Instance { get { lock (padlock) { if (instance==null) { instance = new Singleton(); } return instance; } } } }
3.双重锁定
public sealed class Singleton { static Singleton instance=null; static readonly object padlock = new object(); Singleton() { } public static Singleton Instance { get { if (instance==null) { lock (padlock) { if (instance==null) { instance = new Singleton(); } } } return instance; } } }
这种实现方式对多线程来说是安全的,同时线程不是每次都加锁,只有判断对象实例没有被创建时它才加锁,有了我们上面第一部分的里面的分析,我们知道,加锁后还得再进行对象是否已被创建的判断。它解决了线程并发问题,同时避免在每个 Instance 属性方法的调用中都出现独占锁定。它还允许您将实例化延迟到第一次访问对象时发生。实际上,应用程序很少需要这种类型的实现。大多数情况下我们会用静态初始化。这种方式仍然有很多缺点:无法实现延迟初始化。
4.静态初始化
public sealed class Singleton { static readonly Singleton instance=new Singleton(); static Singleton() { } Singleton() { } public static Singleton Instance { get { return instance; } } }
看到上面这段富有戏剧性的代码,我们可能会产生怀疑,这还是Singleton模式吗?在此实现中,将在第一次引用类的任何成员时创建实例。公共语言运行库负责处理变量初始化。该类标记为sealed 以阻止发生派生,而派生可能会增加实例。此外,变量标记为 readonly,这意味着只能在静态初始化期间(此处显示的示例)或在类构造函数中分配变量。
该实现与前面的示例类似,不同之处在于它依赖公共语言运行库来初始化变量。它仍然可以用来解决 Singleton 模式试图解决的两个基本问题:全局访问和实例化控制。公共静态属性为访问实例提供了一个全局访问点。此外,由于构造函数是私有的,因此不能在类本身以外实例化 Singleton 类;因此,变量引用的是可以在系统中存在的唯一的实例。
由于 Singleton 实例被私有静态成员变量引用,因此在类首次被对 Instance 属性的调用所引用之前,不会发生实例化。
这种方法唯一的潜在缺点是,您对实例化机制的控制权较少。在 Design Patterns 形式中,您能够在实例化之前使用非默认的构造函数或执行其他任务。由于在此解决方案中由 .NET Framework 负责执行初始化,因此您没有这些选项。在大多数情况下,静态初始化是在 .NET 中实现 Singleton 的首选方法。
5.延迟初始化
public sealed class Singleton { Singleton() { } public static Singleton Instance { get { return Nested.instance; } } class Nested { static Nested() { } internal static readonly Singleton instance = new Singleton(); } }
这里,初始化工作有Nested类的一个静态成员来完成,这样就实现了延迟初始化,并具有很多的优势,是值得推荐的一种实现方式。
实现要点
优点
缺点
适用性
应用场景
完整示例
这是一个简单的计数器例子,四个线程同时进行计数。
using System; using System.Threading; namespace SigletonPattern.SigletonCounter { /// <summary> /// 功能:简单计数器的单件模式 /// 编写:Terrylee /// 日期:2005年12月06日 /// </summary> public class CountSigleton { ///存储唯一的实例 static CountSigleton uniCounter = new CountSigleton(); ///存储计数值 private int totNum = 0; private CountSigleton() { ///线程延迟2000毫秒 Thread.Sleep(2000); } static public CountSigleton Instance() { return uniCounter; } ///计数加1 public void Add() { totNum ++; } ///获得当前计数值 public int GetCounter() { return totNum; } } }
using System; using System.Threading; using System.Text; namespace SigletonPattern.SigletonCounter { /// <summary> /// 功能:创建一个多线程计数的类 /// 编写:Terrylee /// 日期:2005年12月06日 /// </summary> public class CountMutilThread { public CountMutilThread() { } /// <summary> /// 线程工作 /// </summary> public static void DoSomeWork() { ///构造显示字符串 string results = ""; ///创建一个Sigleton实例 CountSigleton MyCounter = CountSigleton.Instance(); ///循环调用四次 for(int i=1;i<5;i++) { ///开始计数 MyCounter.Add(); results +="线程"; results += Thread.CurrentThread.Name.ToString() + "——〉"; results += "当前的计数:"; results += MyCounter.GetCounter().ToString(); results += "\n"; Console.WriteLine(results); ///清空显示字符串 results = ""; } } public void StartMain() { Thread thread0 = Thread.CurrentThread; thread0.Name = "Thread 0"; Thread thread1 =new Thread(new ThreadStart(DoSomeWork)); thread1.Name = "Thread 1"; Thread thread2 =new Thread(new ThreadStart(DoSomeWork)); thread2.Name = "Thread 2"; Thread thread3 =new Thread(new ThreadStart(DoSomeWork)); thread3.Name = "Thread 3"; thread1.Start(); thread2.Start(); thread3.Start(); ///线程0也只执行和其他线程相同的工作 DoSomeWork(); } } }
using System; using System.Text; using System.Threading; namespace SigletonPattern.SigletonCounter { /// <summary> /// 功能:实现多线程计数器的客户端 /// 编写:Terrylee /// 日期:2005年12月06日 /// </summary> public class CountClient { public static void Main(string[] args) { CountMutilThread cmt = new CountMutilThread(); cmt.StartMain(); Console.ReadLine(); } } }
总结
Singleton设计模式是一个非常有用的机制,可用于在面向对象的应用程序中提供单个访问点。文中通过五种实现方式的比较和一个完整的示例,完成了对Singleton模式的一个总结和探索。用一句广告词来概括Singleton模式就是“简约而不简单”。