设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样。
Pages: 1/1 First page 1 Final page [ View by Articles | List ]
May 19

/**
* 观察者模式应用场景实例
*
* 免责声明:本文只是以哈票网举例,示例中并未涉及哈票网任何业务代码,全部原创,如有雷同,纯属巧合。
*
* 场景描述:
* 哈票以购票为核心业务(此模式不限于该业务),但围绕购票会产生不同的其他逻辑,如:
* 1、购票后记录文本日志
* 2、购票后记录数据库日志
* 3、购票后发送短信
* 4、购票送抵扣卷、兑换卷、积分
* 5、其他各类活动等
*
* 传统解决方案:
* 在购票逻辑等类内部增加相关代码,完成各种逻辑。
*
* 存在问题:
* 1、一旦某个业务逻辑发生改变,如购票业务中增加其他业务逻辑,需要修改购票核心文件、甚至购票流程。
* 2、日积月累后,文件冗长,导致后续维护困难。
*
* 存在问题原因主要是程序的"紧密耦合",使用观察模式将目前的业务逻辑优化成"松耦合",达到易维护、易修改的目的,
* 同时也符合面向接口编程的思想。
*
* 观察者模式典型实现方式:
* 1、定义2个接口:观察者(通知)接口、被观察者(主题)接口
* 2、定义2个类,观察者对象实现观察者接口、主题类实现被观者接口
* 3、主题类注册自己需要通知的观察者
* 4、主题类某个业务逻辑发生时通知观察者对象,每个观察者执行自己的业务逻辑。
*
* 示例:如以下代码
*
*/
#===================定义观察者、被观察者接口============
/**
*
* 观察者接口(通知接口)
*
*/
interface ITicketObserver //观察者接口
{
    function onBuyTicketOver($sender, $args); //得到通知后调用的方法
}

/**
*
* 主题接口
*
*/
interface ITicketObservable //被观察对象接口
{
    function addObserver($observer); //提供注册观察者方法
}
#====================主题类实现========================
/**
*
* 主题类(购票)
*
*/
class HipiaoBuy implements ITicketObservable { //实现主题接口(被观察者)
    private $_observers = array (); //通知数组(观察者)
  

    public function buyTicket($ticket) //购票核心类,处理购票流程
{
       // TODO 购票逻辑
      

       //循环通知,调用其onBuyTicketOver实现不同业务逻辑
       foreach ( $this->_observers as $obs )
           $obs->onBuyTicketOver ( $this, $ticket ); //$this 可用来获取主题类句柄,在通知中使用
    }
  
    //添加通知
    public function addObserver($observer) //添加N个通知
{
       $this->_observers [] = $observer;
    }
}

#=========================定义多个通知====================
//短信日志通知
class HipiaoMSM implements ITicketObserver {
    public function onBuyTicketOver($sender, $ticket) {
       echo (date ( 'Y-m-d H:i:s' ) . " 短信日志记录:购票成功:$ticket
");
    }
}
//文本日志通知
class HipiaoTxt implements ITicketObserver {
    public function onBuyTicketOver($sender, $ticket) {
       echo (date ( 'Y-m-d H:i:s' ) . " 文本日志记录:购票成功:$ticket
");
    }
}
//抵扣卷赠送通知
class HipiaoDiKou implements ITicketObserver {
    public function onBuyTicketOver($sender, $ticket) {
       echo (date ( 'Y-m-d H:i:s' ) . " 赠送抵扣卷:购票成功:$ticket 赠送10元抵扣卷1张。
");
    }
}
#============================用户购票====================
$buy = new HipiaoBuy ();
$buy->addObserver ( new HipiaoMSM () ); //根据不同业务逻辑加入各种通知
$buy->addObserver ( new HipiaoTxt () );
$buy->addObserver ( new HipiaoDiKou () );
//购票
$buy->buyTicket ( "一排一号" );

?>
May 28

Download ( 344 downloads)

Christopher Alexander 说过:“每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心。这样,你就能一次又一次地使用该方案而不必做重复劳动”

模式描述为:在一定环境中解决某一问题的方案,包括三个基本元素--问题,解决方案和环境。
阅读类图和对象图请先学习UML
创建模式 结构模式 行为模式
创建模式:对类的实例化过程的抽象。一些系统在创建对象时,需要动态地决定怎样创建对象,创建哪些对象,以及如何组合和表示这些对象。创建模式描述了怎样构造和封装这些动态的决定。包含类的创建模式和对象的创建模式。
结构模式:描述如何将类或对象结合在一起形成更大的结构。分为类的结构模式和对象的结构模式。类的结构模式使用继承把类,接口等组合在一起,以形成更大的结构。类的结构模式是静态的。对象的结构模式描述怎样把各种不同类型的对象组合在一起,以实现新的功能的方法。对象的结构模式是动态的。
行为模式:对在不同的对象之间划分责任和算法的抽象化。不仅仅是关于类和对象的,并是关于他们之间的相互作用。类的行为模式使用继承关系在几个类之间分配行为。对象的行为模式则使用对象的聚合来分配行为。
May 13
       这几天分析一个我接手的系统,是一个典型的分布式系统。其中有特色的技术就是采用了webservice,
webservice从字面上分解就是web service----一个提供web服务的系统,可以通过web方式访问这些服务。
而从现实中,webservice可以说是一套标准:分布式,跨平台,跨语言等; 标准实现采用SOAP协议,SOAP
协议是基于流行的XML表达的,具有一个套封envlope, envlope里包含一个必须的body和一个可选的head;
就是在这个body里,我们声明了访问的方法、方法的参数或返回值。
        webservice实现, C++系统上采用开源的gSoap,而java采用apache的Axis。这两个框架都提供工具来
生成C++代码或Java代码,不管是gSoap或者Axis,他们生成的最终代码,客户端只需要调用简单的对象就
可以访问服务器,而服务器生成一样的接口,开发者实现这些接口就行,中间的通讯过程全部由框架解决了。
         其实这种技术架构并不新颖,早期的CORBA和DCOM, 后来java的RMI, 这些基本上都是RPC技术,大同
小异而已。而它们的背后设计模式,可以说就是23种模式之一的代理模式Proxy。简言之就是,一个客户不想
或者不能直接引用一个对象(接口),而代理对象(接口)可以在客户端和目标对象之间起到中介作用。
        按目的划分代理模式有8种:
        1、远程代理:为位于不同的地址空间的对象提供一个局域代表对象
        2、虚拟代理:根据需要创建一个资源消耗较大的对象,使得此对象只在需要时才会被真正创建
        3、Copy-on-Write代理:把复制拖延到只有在客户需要时才真正采取行动
        4、保护代理:控制对象的访问,提供使用权限检查
        5、Cache代理:为某个目标操作的结果提供临时的存储空间,以便多客户共享
        6、防火墙代理:保护目标,防止恶意用户
        7、同步化代理:能同时访问对象而没有冲突
        8、智能引用代理:提供一些额外操作,如访问次数统计
        显然RPC方式属于第1种远程代理模式。
        可以看出,在面对一种技术时,我们从它的定义、实现、引入目的、类似相关技术、背后理论基础来
细细分析,就比较容易掌握了。
Mar 22
1.单例模式(Singleton模式)
概念:单例模式的意思就是只有一个实例。单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例。这个类称为单例类。
应用:
一些资源管理器常常设计成单例模式。
需要管理的软件内部资源也包括譬如负责记录网站来访人数的部件,记录软件系统内部事件、出错信息的部件,或是对系统的表现进行检查的部件等。这些部件都必须集中管理,不可政出多头。  
 这些资源管理器构件必须只有一个实例,这是其一;它们必须自行初始化,这是其二;允许整个系统访问自己这是其三。因此,它们都满足单例模式的条件,是单例模式的应用。
参考:i.简单实用
http://www.cnblogs.com/procoder/archive/2010/02/25/Singleton-NET.html
ii.深入详细
http://www.cnblogs.com/BoyXiao/archive/2010/05/07/1729376.html
2.观察者模式
概念:Observer:定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。
Jan 30
Highslide JS
Quotation
依赖注入(或称“控制反转”Inversion-of-Control,英文缩写为IoC)  什么是依赖注入   什么是控制反转,下面一起来理解下:
控制反转是一个重要的面向对象编程的法则来削减计算机程序的耦合问题。 控制反转还有一个名字叫做依赖注入(Dependency Injection)。简称DI。
IoC 亦称为 “依赖倒置原理”("Dependency Inversion Principle")。差不多所有框架都使用了“倒置注入(Fowler 2004)技巧,这可说是IoC原理的一项应用。SmallTalk,C++, Java 或各种.NET 语言等面向对象程序语言的程序员已使用了这些原理。
  控制反转是Spring框架的核心。
  应用控制反转,对象在被创建的时候,由一个调控系统内所有对象的外界实体,将其所依赖的对象的引用,传递给它。也可以说,依赖被注入到对象中。所以,控制反转是,关于一个对象如何获取他所依赖的对象的引用,这个责任的反转。
      IoC就是IoC,不是什么技术,与GoF一样,是一种设计模式。
“控制反转百度百科:http://baike.baidu.com/view/1800021.htm

通俗的理解:
Quotation
依赖注入是spring框架中的解耦的一种策略,称为DI或IOC(控制反转),主要有set方式(提供set和get方法)和constractor(构造方法)方式,它使得类与类之间以配置文件的形式组织在一起,而不是硬编码的方式,例如classA 中用到了classB如果写代码的话是new 一个classB,而用依赖注入的方式则是在applicationContext.xml里面写两个
,就是在类A里原来需要new 的地方就不需要写了,




msdn中关于依赖注入的描述:http://msdn.microsoft.com/zh-cn/magazine/cc163739(en-us).aspx#contents(下面是译文)
今天比以往更加注重对现有组件的重用和把异构组件联结成一种粘合框架。但是这种联结很快就成了一项让人畏缩的任务,因为这个时候程序的尺寸和复杂度都在增加,依赖性也是。减少这种依赖性扩展的一个方法就是使用依赖注入(Dependency Injection),它允许你把对象注入一个类,这胜于依赖这个类来建立自己的对象。
Dec 5
设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样。
百度百科:http://baike.baidu.com/view/66964.htm
  可复用面向对象软件系统现在一般划分为两大类:应用程序工具箱和框架(Framework),我们平时开发的具体软件都是应用程序,Java的API属于工具箱;而框架是构成一类特定软件可复用设计的一组相互协作的类,EJB(EnterpriseJavaBeans)是Java应用于企业计算的框架。
  框架通常定义了应用体系的整体结构类和对象的关系等等设计参数,以便于具体应用实现者能集中精力于应用本身的特定细节。框架主要记录软件应用中共同的设计决策,框架强调设计复用,因此框架设计中必然要使用设计模式。
  另外,设计模式有助于对框架结构的理解,成熟的框架通常使用了多种设计模式,如果你熟悉这些设计模式,毫无疑问,你将迅速掌握框架的结构,我们一般开发者如果突然接触EJBJ2EE等框架,会觉得特别难学,难掌握,那么转而先掌握设计模式,无疑是给了你剖析EJB或J2EE系统的一把利器。
基于C#的23种设计模式http://wenku.baidu.com/view/29c5d41fb7360b4c2e3f6435.html

一个23设计模式的搞笑解释
1、FACTORY —追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory

工厂模式:客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂类也要做相应的修改。如:如何创建及如何向客户端提供。

2、BUILDER  — MM最爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到 MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。(这一定比美军在伊拉克用的翻译机好卖)
Pages: 1/1 First page 1 Final page [ View by Articles | List ]