标签归档:OOP

面向对象的S.O.L.I.D 原则

面向对象的S.O.L.I.D 原则

一般来说这是面向对象的五大设计原则,但是,我觉得这些原则可适用于所有的软件开发。

Single Responsibility Principle (SRP) – 职责单一原则

关于单一职责原则,其核心的思想是:一个类,只做一件事,并把这件事做好,其只有一个引起它变化的原因。单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申,将职责定义为引起变化的原因,以提高内聚性来减少引起变化的原因。职责过多,可能引起它变化的原因就越多,这将导致职责依赖,相互之间就产生影响,从而极大的损伤其内聚性和耦合度。单一职责,通常意味着单一的功能,因此不要为一个模块实现过多的功能点,以保证实体只有一个引起它变化的原因。

Unix/Linux是这一原则的完美体现者。各个程序都独立负责一个单一的事。
Windows是这一原则的反面示例。几乎所有的程序都交织耦合在一起。

Open/Closed Principle (OCP) – 开闭原则

关于开发封闭原则,其核心的思想是:模块是可扩展的,而不可修改的。也就是说,对扩展是开放的,而对修改是封闭的。

对扩展开放,意味着有新的需求或变化时,可以对现有代码进行扩展,以适应新的情况。
对修改封闭,意味着类一旦设计完成,就可以独立完成其工作,而不要对类进行任何修改。

对于面向对象来说,需要你依赖抽象,而不是实现,23个经典设计模式中的“策略模式”就是这个实现。对于非面向对象编程,一些API需要你传入一个你可以扩展的函数,比如我们的C 语言的qsort()允许你提供一个“比较器”,STL中的容器类的内存分配,ACE中的多线程的各种锁。对于软件方面,浏览器的各种插件属于这个原则的实践。

Liskov substitution principle (LSP) – 里氏代换原则

软件工程大师Robert C. Martin把里氏代换原则最终简化为一句话:“Subtypes must be substitutable for their base types”。也就是,子类必须能够替换成它们的基类。即:子类应该可以替换任何基类能够出现的地方,并且经过替换以后,代码还能正常工作。另外,不应该在代码中出现if/else之类对子类类型进行判断的条件。里氏替换原则LSP是使代码符合开闭原则的一个重要保证。正是由于子类型的可替换性才使得父类型的模块在无需修改的情况下就可以扩展。

这么说来,似乎有点教条化,我非常建议大家看看这个原则个两个最经典的案例——“正方形不是长方形”和“鸵鸟不是鸟”。通过这两个案例,你会明白《墨子 小取》中说的 ——“娣,美人也,爱娣,非爱美人也….盗,人也;恶盗,非恶人也。”——妹妹虽然是美人,但喜欢妹妹并不代表喜欢美人。盗贼是人,但讨厌盗贼也并不代表就讨厌人类。这个原则让你考虑的不是语义上对象的间的关系,而是实际需求的环境。

在很多情况下,在设计初期我们类之间的关系不是很明确,LSP则给了我们一个判断和设计类之间关系的基准:需不需要继承,以及怎样设计继承关系。

Interface Segregation Principle (ISP) – 接口隔离原则

接口隔离原则意思是把功能实现在接口中,而不是类中,使用多个专门的接口比使用单一的总接口要好。

举个例子,我们对电脑有不同的使用方式,比如:写作,通讯,看电影,打游戏,上网,编程,计算,数据等,如果我们把这些功能都声明在电脑的抽类里面,那么,我们的上网本,PC机,服务器,笔记本的实现类都要实现所有的这些接口,这就显得太复杂了。所以,我们可以把其这些功能接口隔离开来,比如:工作学习接口,编程开发接口,上网娱乐接口,计算和数据服务接口,这样,我们的不同功能的电脑就可以有所选择地继承这些接口。

这个原则可以提升我们“搭积木式”的软件开发。对于设计来说,Java中的各种Event Listener和Adapter,对于软件开发来说,不同的用户权限有不同的功能,不同的版本有不同的功能,都是这个原则的应用。

Dependency Inversion Principle (DIP) – 依赖倒置原则

高层模块不应该依赖于低层模块的实现,而是依赖于高层抽象

举个例子,墙面的开关不应该依赖于电灯的开关实现,而是应该依赖于一个抽象的开关的标准接口,这样,当我们扩展程序的时候,我们的开关同样可以控制其它不同的灯,甚至不同的电器。也就是说,电灯和其它电器继承并实现我们的标准开关接口,而我们的开关产商就可不需要关于其要控制什么样的设备,只需要关心那个标准的开关标准。这就是依赖倒置原则。

这就好像浏览器并不依赖于后面的web服务器,其只依赖于HTTP协议。这个原则实在是太重要了,社会的分工化,标准化都是这个设计原则的体现。

参考:http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

PHP设计模式之代理模式

代理模式:在客户端和实体之间建立一个代理对象(Proxy),客户端对实体的操作全部委派给代理对象,隐藏实体的具体实现细节
Proxy还可以与业务代码分离,部署到另外的服务器。业务代码通过RPC来委派任务

代理模式proxy.php

当要执行一个读操作时,在从库执行,当要执行写操作时连接主库,这样就实现了读写分离,连接数据库的操作交给代理类来执行。

PHP设计模式之装饰器模式

装饰器模式可以动态的添加修改类的功能
一个类提供了一项功能,如果要在修改并添加额外的功能,传统编程,需要写一个字类继承它,并重新实现类的方法
使用装饰器模式,只需在运行时添加一个装饰器对象,可以实现最大的灵活性

 

PHP设计模式之原型模式

原型模式与工厂模式作用相似,都是用来创建对象的;

与工厂模式的实现不同,原型模式是先创建一个对象,然后通过clone原型对象来创建新的对象,这样就免去了类创建时的重复初始化操作;

原型模式适合于大对象的创建,创建一个对象需要很大的开销,如果每次new就会消耗很大,原型模式仅需内存拷贝即可;

 

PHP设计模式之观察者模式

当一个对象发生改变时,依赖它的对象全部收到通知,并自动更新
场景:一个事件发生后,要执行一连串更新操作。传统的编程方法就是在事件的代码之后直接加入处理逻辑。当更新的逻辑增多之后,代码变得难以维护。这种方式是耦合的,侵入式的,增加新的逻辑要修改事件主体代码
观察者模式实现了低耦合,非侵入式的通知与更新机制

 

 

PHP设计模式之策略模式

策略模式是将一组特定的行为和算法封装成类,以适应某些特定的上下文环境
实际应用举例,假如有一个电商网站系统,针对男性女性用户要跳转到不同的赠品类目,并且所有广告位展示不同的广告

 

PHP设计模式之工厂模式、单例模式和注册模式

所有面向对象中最常见的三种设计模式分别是:工厂模式,单例模式,注册(器)模式

  1. 工厂模式,工厂方法或者类产生对象,百不是在代码中直接new
  2. 单例模式,使某个类的对象仅允许创建一个
  3. 注册模式,全局共享和交换对象

工厂模式factory.php

单例模式singleton.php

 

 工厂模式和单例结合使用

 

注册器类register.php