痛苦的抉择:DevWorks v1 延期

本来, 我已经完成了 DevWorks 的内核和大多数周边模块, 仅剩后台没有完成. 我以为, DevWorks v1.0 近在咫尺.

可是, 我在写后台和完善内核的时候, 发现了一系列的问题. 问题的矛头直指 DevWorks 的根基 - DevWorks 内核类 (DevWorks Core Class)

具体的问题说大也不大, 说小也不小.(没有兴趣可以略过)

根据现代面向对象编程的原则, DevWorks 没有使用任何全局变量. 因此, 您在代码中找不到 global 关键字.

因此, 我将 DevWorks 的全部原本应直接写出的代码放进了 DevWorks 内核类. 我想, DevWorks 作为一个对象, 应该是一个类.

但我发现我错了. 因为前面提到的原因, 我无法在对象中引用 DevWorks 类的成员 - 例如数据库连接.

我采用了类似于 IPB 的解决方案, 为每一个类安排一个特殊的属性devworks,作为主对象的一个指针(准确地说是引用).

于是一个愚蠢的事情发生了: 无论是什么类(library里的类除外),都清一色地拥有一个叫做 devworks 的属性

我们不禁要问, 这难道就符合面向对象编程的原则吗?

PHP 已经提供了解决之道 - 静态类.静态类就是为只存在一个副本的对象而设计的. 这不正是 DevWorks 内核类需要的吗?

但毕竟木已成舟, DevWorks 已经写好了几百 KB 的代码,如果要修改实在很麻烦.

我辗转反侧, 计划在 DevWorks v2 改写架构

但 DevWorks 的性质决定了, 这样做良心上说不通. 这样为 DevWorks v1 所付出的不就白费了吗?

因此, 我决定, 改写内核的架构 - 将 DevWorks 内核类换成静态类.

牵一发而动全身, 这样一个行为导致的后果非常严重. 大部分代码需要修改.

不过不用太担心, 上面说的虽然有些严重, 但那是对我而言. DevWorks 的设计理念和基本架构没有变, 变化的仅仅是内核的架构.

从此可以告别愚蠢的 public $devworks; 了!

因此, DevWorks 预计发布时间延期到四月份.

另: 如果可能, 我希望 DevWorks 能够参加 2009 或 2010 年的 Google Summer of Code.

DevWorks 开发人员: HeavenFox

1 Response to “痛苦的抉择:DevWorks v1 延期”


  1. 1 ultraman mebius

    thanks!!!

Leave a Reply