destoon's design 一 oop pop and namspace

在这篇文章名字中使用优秀是经过我这两天研究后决定的。
原因是我在使用了这么多年的oop后再见到function的惊讶。

正如我在一开始入门编程时,仅会用 html 后来半推半就的了解了点 asp,第一次看到别人的 asp 代码用了函数定义一样。
我也不知道文章会如何分,在未完成之前就随手记吧。

通过对入口文件分析来说说 oop函数式 的不同

  1. 大部分的 oop 习惯于使用单入口,因为单入口更加方便处理,使用基类进行处理让系统更加完整,可以通过基类进行解耦,不用过多关注业务逻辑之外的架构。
  2. 在看到 destoon 后让我想到了 discuz!,当年在使用论坛程序的时候我们就在用了这样的方式。 总结特点如下:
    1. 很少使用类,后者仅有部分内容使用类(一般用类的也就是数据库,这也是比较先进的了,大部分仍然还是用函数 定一个全局变量)
    2. 函数思想,所有的方法封装成函数
    3. 变量,通用全局变量。通过将大部分的变量定义成全局变量来进行处理变量的变化。
    4. 目录结构,由于函数式维护的复杂性,更多的人在写此类框架的将结构定义的非常明确。这种方式其实与命名空间比较类似。定义公共的模块路径,入口文件通过条件判断来引入不同的模块下的相同定义名的文件。
  3. 暂且不说 discuz! 单入口解决方案。我这里研究了下 destoon 的分站解决方案。destoon的分站首页和主站首页用了相同的入口文件

    1. 入口文件引入的公共文件 common.inc.php 定义几个变量 $city_domain = $city_template = $city_sitename = '';
    2. 如果开启了分站 $DT['city'] 为0 未开启 为1 开启 这里使用了缓存 导致比较难以明确 $DT['city']的来源 具体可以通过查看 cache_module() 方法来确认。
    3. 如果开启分站则加载分站处理公共脚本city.inc.php;
    4. 通过匹配域名 getenv('http_host')来获取到网站访问域名,然后去 city表中查询域名对应的分站,如果存在则,将表查询的 id 赋给 cityid,来确定有分站。
    5. 通过 cityid 再次得到分站信息然后赋值

      1
      2
      3
      4
      $c = $db->get_one("SELECT * FROM {$DT_PRE}city WHERE areaid=$cityid");
      $city_name = $c['name'];
      $city_domain = $c['domain'];
      $city_template = $c['template'];
    6. 得到了城市分站相关信息模板设置,然后就是堵数据处理模板了。

  4. 通过3的分析,再次让我感受到了destoon作者设计的苦心。我们在用oop在基类中的构造方法中也是完成这一套逻辑。同样跟oop对比后,我们发现我们对于oop的认同感增强了,而对于函数式这种写法也更加排斥。 因为你不知道某个变量来自于哪里,尤其是我们用extract($array)后的崩溃感。

命名空间与函数和变量隔离

  1. 在函数式中我们没法定义两个相同名称的funciton
  2. oop中我们可以在不同的类中定义相同名称的 function,但是在公共函数文件中仍然跟函数式一样无法定义相同名称的function
  3. 命名空间的出现让我们避免了这个问题。当我们对一个 php 语言文件顶部增加namespace Foo;的时候,我们就将这个文件划分到了 Foo 空间下。如下面对的代码.

    1
    2
    3
    4
    5
    6
    namespace Foo;
    function base64_urlSafeEcode($data){
    $find = ['+', '/'];
    $replace = ['-', '_'];
    return str_replace($find, $replace, base64_encode($data));
    }

    这个时候我们调用 base64_urlSafeEcode()的时候需要使用 \Foo\base64_urlSafeEcode();当然可以将这个方法明明为base64_encode()。之所以定义不同名称是为了更好让人理解,这个 base64 编码方法是url 安全的。