函数式、oop 和命名空间--对于 destoon 代码优秀设计的思考 一
在这篇文章名字中使用优秀是经过我这两天研究后决定的。
原因是我在使用了这么多年的`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` 再次得到分站信息然后赋值
```php
$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` 空间下。如下面对的代码.
```php
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 安全`的。
