标签归档：设计模式

简单工厂模式和策略模式区别

发表于 2011 年 03 月 23 日 由 崔玉松

这两种模式的作用就是拥抱变化，减少耦合。在变化来临时争取做最小的改动来适应变化。这就要求我们把那些“善变”的功能从客户端分离出来，形成一个个的功能类，然后根据多态特性，使得功能类变化的同时，客户端代码不发生变化。 简单工厂模式 简单工厂模式：有一个父类需要做一个运算（其中包含了不同种类的几种运算），将父类涉及此运算的方法都设成虚方法，然后父类派生一些子类，使得每一种不同的运算都对应一个子类。另外有一个工厂类，这个类一般只有一个方法（工厂的生成方法），这个方法的返回值是一个超类，在方法的内部，根据传入参数的不同，分别构造各个不同的子类的对象，并返回。客户端并不认识子类，客户端只认识超类和工厂类。每次客户端需要一中运算时，就把相应的参数传给工厂类，让工厂类构造出相应的子类，然后在客户端用父类接收（这里有一个多态的运用）。客户端很顺理成章地用父类的计算方法（其实这是一个虚方法，并且已经被子类特化过了，其实是调用子类的方法）计算出来结果。如果要增加功能时，你只要再从父类中派生相应功能的子类，然后修改下工厂类就OK了，对于客户端是透明的。 策略模式 策略模式：策略模式更直接了一点，没有用工厂类，而是直接把工厂类的生成方法的代码写到了客户端。客户端自己构造出了具有不同功能的子类（而且是用父类接收的，多态），省掉了工厂类。策略模式定义了算法家族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。这里的算法家族和简单工厂模式里的父类是同一个概念。当不同的行为堆砌在一个类中时，就很难避免使用条件语句来选择合适的行为，将这些行为封装在一个个独立的策略子类中，可以在客户端中消除条件语句。 简单工厂模式+策略模式：为了将工厂方法的代码从客户端移出来，我们把这些代码搬到了父类的构造函数中，让父类在构造的时候，根据参数，自己实现工厂类的作用。这样做的好处就是，在客户端不用再认识工厂类了，客户端只要知道父类一个就OK，进一步隔离了变化，降低了耦合。 在基本的策略模式中，选择所用具体实现的职责由客户端对象成端，并转给客户端。这本身并没有减除客户端需要选择判断的压力，而策略模式与简单工厂模式结合后，选择具体实现的职责也可以由父类承担，这就最大化地减轻了客户端的职责。

发表在 Excellence Article | 标签为 | 留下评论

《企业应用架构模式》笔记一

发表于 2009 年 10 月 09 日 由 崔玉松

企业应用 定义：  企业应用一般都涉及到持久化数据。 企业应用一般都涉及大量数据 企业应用还涉及很多人同时访问 企业应用还涉及大量操作数据的用户界面屏幕。 企业应用很少独立存在，通常需要与散布在企业周围的其他企业应用集成。（技术多样化，协议多样化） 可伸缩性： 响应时间 响应性 等待时间 吞吐率 负载 负载敏度 效率 领域逻辑组织方式： 1.事务脚本 2.领域模型 3.表模块 服务层： 表现逻辑和领域逻辑之间的交互完全通过服务层，就像应用程序API一样。 如果确实需要，使用最小化的服务层 映射到关系数据库： 1. 为查询语句返回的每一行产生一个它的实例，种种行数据入口就行是面向对象方式来看待数据。 2.许多环境提供记录集，这种表和数据行的一种通用数据结构，用来模拟数据库的表格属性。 如果使用记录集，对于数据库的每个表只需要一个对象来管理。 并发： 解决方案有两个，一个是隔离，一个是不变性 隔离是学习操作系统分配内存的方式，让一个单元只允许一个进程访问 只有共享数据可以被修改的情况下并发问题才会出现。 事务属性： 1.原子性  在事务里面所有的动作要么全部完成，要么全部回滚 2.一致性  在事务开始和结束的时候，所有的资源要保持一致 3.隔离性  在事务完成之后，他的结果对于其他事务才是可见的 4.持久性  已提交的事务必须是可持久性的，即任何崩溃都是可以保存下来的 … 继续阅读 →

发表在 Study & Reading | 标签为 , | 留下评论

PHP设计模式–单列模式

发表于 2008 年 12 月 08 日 由 崔玉松

关于单列模式： BookSingleton.php 单列模式可以将其本身的实例分配到其他的类中。 //copyright Lawrence Truett and FluffyCat.com 2005, all rights reserved   class BookSingleton {   private $author = ‘Gamma, Helm, Johnson, and Vlissides’; private $title = ‘Design Patterns’; private static $book = NULL; private static $isLoanedOut = FALSE; … 继续阅读 →

发表在 Programming | 标签为 , | 一条评论

什么样的水平应该去研究一下“设计模式”

发表于 2008 年 04 月 29 日 由 崔玉松

   先说一下我为什么学习《设计模式》吧。  之所以看一下设计模式是因为我发现半年前我写的代码就算旁边有注释，我也要思考一下才能接受，甚至佩服当初自己怎么这么聪明，想到用这种方式去处理。如果把注释去掉，估计看一遍比重新写一遍的时间还长。           看了网上流传的电子书《大话设计模式》之后开始在自己的代码中运用“工厂模式”，等看完了《设计模式》之后，再看看以前写的代码，简直就是垃圾，一点艺术性都没有，纯粹是为了实现某一个功能而临时拼凑起来的代码块，没有任何模块的概念. 所以想通过进一步研究一下设计模式，提高代码质量，但是事与愿违，读了两遍，隐隐约约好像明白了点，事实上写代码仍然是在凑，把功能凑出来，看着别人的代码都很清晰，自己的却那么乱，很郁闷。 关于学习设计模式的时机问题，仁者见仁，智者见智，很多人都觉得学完面向对象之后就应该学习。而我更倾向于M6里babaru同学的看法,以下是他的回答： 从我自身的经验来讲，开始的时候一定会看了就忘了，我觉得这是一个循序渐进的过程，你有在项目中使用设计模式的主动性是最关键的，忘了不要紧，《设计模式》这本书本身就是写成可以放在你手边随时速查的手册。 在最开始学习编程的时候，有设计模式这个概念我觉得就可以了，因为很多的模式，你没有遇到过那些问题，就不会有切身的理解，反而会造成为模式而模式，过度设计。 随着项目的积累，你可能会开始思考，如何让你的模块更健壮，或者遇到了复用的问题，那么你会自然地去设计模式里面找答案，那样的过程我觉得就是很好的学习过程了。 软件的设计模式是从建筑学里面的模式借鉴过来的，它应该是你从入门快速到达中等合格水平软件工程师的良好阶梯。 我还推荐一种方法，就是你遇到某种模块的开发的时候，不妨去设计模式的各种应用场景里面找找看，应该会有契合的场景，可以在自己的设计里面尝试一下，不断的的使用，尝试，然后总结，思考，慢慢地积累设计模式的应用经验。 我觉得他说得非常好，不能因为模式而模式，那样不但没有达到目的，反而损失原有的健壮性。

发表在 Study & Reading | 标签为 | 留下评论