Heim  >  Artikel  >  Backend-Entwicklung  >  redis - php两种封装类的优缺点?

redis - php两种封装类的优缺点?

WBOY
WBOYOriginal
2016-06-06 20:38:141101Durchsuche

php很多内置的类或扩展类比较粗糙,需要人为的封装一遍,于是有了两种封装方式,
1直接继承
2内部实例化

如redis类,
可以

<code>namespace lib
class redis extends \Redis {}
</code>

也可以

<code>namespace lib
class redis {
    private $_redis = null;
    public function __construct() {
        $this->_redis = new \Redis()
    }
}
</code>

第一种方法的优点是方便,无须把所有的方法重写一遍,但是不太好统一捕捉异常,
第二种就是麻烦些,需要重写一遍所有的方法,(虽然可以用魔术方法),捕捉异常方便些。
大家用的哪种?为什么呢?

回复内容:

php很多内置的类或扩展类比较粗糙,需要人为的封装一遍,于是有了两种封装方式,
1直接继承
2内部实例化

如redis类,
可以

<code>namespace lib
class redis extends \Redis {}
</code>

也可以

<code>namespace lib
class redis {
    private $_redis = null;
    public function __construct() {
        $this->_redis = new \Redis()
    }
}
</code>

第一种方法的优点是方便,无须把所有的方法重写一遍,但是不太好统一捕捉异常,
第二种就是麻烦些,需要重写一遍所有的方法,(虽然可以用魔术方法),捕捉异常方便些。
大家用的哪种?为什么呢?

继承

继承的特点有

  • ✔实现成本低
  • ✔调用者可以沿用原有的接口使用,学习成本低
  • ✔原有的功能无需任何代码如常工作
  • ✘无法隐藏或改变原有的功能

    • 其实你可以这么做,就好像你确实可以用铁丝去捅插座眼一样
    • 改变输入、改变输出、改变行为都属于改变功能,比如原来抛的异常现在不抛了,原来return false现在变异常了,原来输入的是青椒现在变牛肉了等等
  • ✘正交性弱,没有做到屏蔽父类的依赖,需要更换父类的时候显得脆弱

常见的合适的应用有

  • 增加日志记录等不影响原有逻辑的“旁路逻辑”
  • 增加一些方法,比如原有的某一些方法a()b()c()总是连续一起调用,增加一个doABC()方法

    • 仅限简单的少量的方法,如果要加复杂的功能或者大量的方法,还是建议用组合
  • 增加一些静态/工厂方法,比如new Redis(ip, port) => OurRedis::getInstance()

一句话说就是原有行为不变,is-a的场景用继承。

组合

组合的特点有

  • ✘实现成本略高,创建对象的过程可能会变复杂
  • ✘调用者需要理解新的接口
  • ✘需要转发才能让原有的功能工作
  • ✔很容易隐藏/屏蔽原有的部分功能
  • ✔正交性强,可以通过更换内部的对象适配不同的情况而保持外部接口不变

常见的合适的应用有

  • 一切涉及改变行为的需求
  • 未来依赖会变的场景,比如redis会变成memcache,或者mysql会变mariadb之类
  • 需要屏蔽细节的场景,比如Session Cache等需求确实用到redis,但对外肯定要屏蔽“这是个redis实现的session”。否则恐龙会出现在你背后把你脑袋咬掉

一句话就是某个功能依赖另一个功能,use-ahas-a的场景用组合


偏题,predis用起来还不错,可以一试

如果你看过任何一本设计模式的书,肯定都是推荐你使用第二种。

它们奉行的原则是:组合优于继承

不过,还得看自己需求。如果系统的接口和你的类提供的一致,可以试试第一种。如果不一致,选择第二种。

如果你正在为系统设计 DB 中间层,需要适配不同的数据库,选择第二种。

楼主你干脆用Java吧,别用PHP了。用好一门语言就要掌握这门语言的特性和风格,按照这门语言的风格去行事。

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn