摘要：一个外部具体对象的引入，必然会给一个模块带来与外部模块之间的依赖。而具体对象的创建始终是我们无法规避的。即使我们可以利用设计模式的工厂方法模式或抽象工厂封装具体对象创建的逻辑，但却又再次引入了具体工厂对象的创建依赖。虽然在设计上有所改进，但没有彻底解除具体依赖，仍让我心有戚戚焉。以一个电子商务网站的设计为例。在该项目中要求对客户的订单进行管理，例如插入订单。考虑到访问量的关系，系统为订单管理提供了... 阅读全文

摘要：前面的客户端程序中,遍历部门时,有个对部门还是人员的判断,然后按照不同的类型输出不同的结果,这样增加了客户端的复杂度,如果出现另一种情况,那么就要修改客户端,因为客户端程序大部分都不是出现在一个调用中,所以这样的修改十分可怕,如果输出有所变化,比如多加几个字,或者显示员工福利工资,那么就不得不修改客户代码所有出现的输出的地方.那么我们如何来封装这个变化呢? 1.分析: 我们的意图,我们要... 阅读全文

摘要：前面我们完成了复杂的Composite的创建的封装,但是那里面还有缺点:前面我们说了一个人可能身兼二职,尤其管理层的,更有这个可能,那么他就要出现在不同部门里,而我们现在的创建是一个节点一个对象,这样我们就要浪费内存了...怎么解决? 1.分析:看看我们的意图我们要让身兼数职的员工,共享一个对象.从而减少系统中的重复对象. Gof23中的FlyWeight(蝇量):运用共享技术有... 阅读全文

摘要：在前面的文章中,我们设计完成了员工工资,福利以及按照部门来区分员工,以及遍历统计部门人员成本等业务逻辑,这些设计基本上可以满足我们所设定的场景的变化,可是创建部门及人员树的时候太复杂了,而且这种创建很容易发生变化,比如加入分公司,或者部门层级变动添加了层级的时候,创建的代码一定就要修改.那么如何避免,封装这个创建时的变化呢? 1.分析:来看看我们的意图,我们要将复杂的部门创建过程封装,使... 阅读全文

摘要：前面我们设计完成了统计部门工资,这样的一个需求,但是在我们设计遍历员工信息的方法是固定不变的,也就是说是硬编码在PersonComposite类中的,由于Composite设计模式相当于一个树或者图的数据结构,那么他的遍历就会出现变化,比如在遍历部门和小组的时候采取不同的方法,以减少遍历的时间,那么如何去解决这个问题呢? 看看我们的意图:我们需要不同的遍历方式,来遍历Composite中... 阅读全文

摘要：前面我们设计了员工的工资，奖金，福利系统。今天客户又来增加需求了:"我们需要统计公司，部门，或者小组的薪资成本。"得到了需求，我们还是按照老套路来完成我们的设计。 1.分析 我们用"名词分析法"来分析需求里面的类(第一篇有讲解),薪资的部分我们已经有了，需求中包含公司，部门，小组这三个名词。好的我们来过滤它。 2.过滤 好,我们通过分析得到了公司，部门，小组。这里要考虑以后可能有的变... 阅读全文

摘要：在前三篇中我们设计了员工的工资,绩效将金,以及员工福利,使用了Bridge(员工和工资的组合),Stratege(工资和绩效将金的设计)以及(Singleton)单件了这些算法,然后用Decorator(装饰)将员工进行职位的装饰.这些设计在我们前面所说的场景下,是符合设计模式的意图的,但是它仍然有一些漏洞. 我们来看看我们的员工类的代码,注意注释的文字. Code Code ... 阅读全文

摘要：前面两篇中,完成了客户所提的"我们的系统要管理人员的工资.(为了模拟真实的开发场景,这里暂时先定义一个功能)人员分为实习员工和正式员工,他们的基本工资是不同的,工资包括基本工资和绩效工资."这样的一个系统需求.我们设计并完成了他,今天客户由于公司要给员工福利,而来追加需求"按照不同的职位,给与不同的福利,一个人可能身兼几个职位".OK,明确了需求,我们还是按照第一篇的方式来完成它. 1.分... 阅读全文

摘要：上一篇我们分析了员工，工资，以及绩效奖金三个类，并且使用了Bridge和Stratege两种模式，对他们之间的组合和行为进行了设计，但是我们的设计并不完善。我们知道员工的基本工资可能每年都不一样，甚至有可能随时地根据公司的制度发生变化，而设计的根本意图就是去封装变化，让我们的系统更加的长寿，不会因为变化而大量的重造，我们怎么去避免工资变化时，员工类不改变呢？？ 先看一下，上次设计的员工类的代码： ... 阅读全文

摘要：(声明:本系列所用的模式都来自GOF23中，本系列并不是讲23种经典设计模式，而是如何去使用这些模式) 一直很想写关于设计模式的具体使用的文章,可是一直没想好怎么去写,才可以通俗易懂,真正的让设计模式,应用到系统设计中.今天终于想到了,这个系列准备用实例去讲解如何使用(GOF)设计模式. 准备用公司的人员管理系统来做这个实例,为什么选他呢?我觉得大家基本上都是公司员工,对这... 阅读全文

摘要：概述 在软件系统中，有时候我们会使用继承来扩展对象的功能，但是由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响将为最低？这就是本文要讲的Decorator模式。 ... 阅读全文

摘要：概述 在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。 意图 将抽象部分与实现部分分离，使它们都可以独立的变化。[GOF 《设计模式》] 结构图 图1 Bridge模式结构图 生活中的例子 桥接模式将抽象部分与它的实现分离，使它... 阅读全文

摘要：前言 大家好！好久没有更新这个系列的文章了，这两个来月回家过了新年，公司搬了新家，就是这个系列的文章还没有更新，实在惭愧！同时再次真诚地感谢一直喜欢和支持这个系列文章的朋友们，因为你们的鼓励，我才有动力继续下去。可能因为这个系列每篇文章都比较长的原因，为了保证质量我总是字斟句酌，所以每次想动笔的时候都有点胆怯的感觉，但是还好每次只要写了开头我就会坚持把它写完的，还是万事开头难啊。 上篇【策略模... 阅读全文

摘要：前言 万事开头难，最近对这句话体会深刻！这篇文章是这个系列正式开始介绍设计模式的第一篇，所以肩负着确定这个系列风格的历史重任，它在我脑袋里默默地酝酿了好多天，却只搜刮出了一点儿不太清晰的轮廓，可是时间不等人，以后再多“迭代”几次吧！在前面的随笔里，我已经提到了，这个系列准备以《Head First Design Patterns》的结构为主线，所以每个模式的核心故事都是取材于此书，在此再次声明... 阅读全文

摘要：前言 正式接触使用设计模式近两年了，一直想写点东西来巩固所学，但是迟迟没有动作，总想时间和见识再多一些的时候再动笔，但是拖得越久越感觉合适的时机永远不会有，只有不断实践才能换来进步，也许再不写就永远也写不出来了，于是我终于开始了。 谈到设计模式，应该还没有人能超越GOF的开山之作，所以谈不上什么创新，归根结底还是重复前人的论述和思想，更多的只能是整理和个人的一些心得体会。因为从设计模式诞生以来，业... 阅读全文

摘要：Public interface IFruit { } public class Orange:IFruit { public Orange() { Console.WriteLine("An orange is got!"); } } public class Apple:IFruit { public Apple() { Consol... 阅读全文

摘要：通过前面两篇，我想各位朋友对“面向接口编程”的思想有了一定认识，并通过第二篇的例子，获得了一定的直观印象。但是，第二篇中的例子旨在展示面向接口编程的实现方法，比较简单，不能体现出面向接口编程的优势和这种思想的内涵。那么，这一篇作为本系列的终结篇，将通过分析几个比较有深度的模式或架构，解析隐藏其背后的面向接口思想。这篇我将要分析的分别是MVC模式和.NET平台的分层架构。 这篇的内容可能... 阅读全文

摘要：通过上一篇文章的讨论，我想各位朋友对“面接接口编程”有了一个大致的了解。那么在这一篇里，我们用一个例子，让各位对这个重要的编程思想有个直观的印象。为充分考虑到初学者，所以这个例子非常简单，望各位高手见谅。 问题的提出 定义：现在我们要开发一个应用，模拟移动存储设备的读写，即计算机与U盘、MP3、移动硬盘等设备进行数据交换。 上下文（环境）：已知要实现U盘、M... 阅读全文

摘要：我想，对于各位使用面向对象编程语言的程序员来说，“接口”这个名词一定不陌生，但是不知各位有没有这样的疑惑：接口有什么用途？它和抽象类有什么区别？能不能用抽象类代替接口呢？而且，作为程序员，一定经常听到“面向接口编程”这个短语，那么它是什么意思？有什么思想内涵？和面向对象编程是什么关系？本文将一一解答这些疑问。 1.面向接口编程和面向对象编程是什么关系 首先，面向接口编程和面向对象编程... 阅读全文