PHP类层次结构的最佳组织方式

Question

我有一个比较原始的框架，我一直在大多数项目中使用它，但是我想到了一个普遍的设计问题，我还没有解决。对于给定的应用程序，我应该将特定于应用程序的类结构与框架的结构分离，还是在框架上构建不是那么糟糕的事情？

例如，假设我有一个基本控制器类的框架，并为我的应用程序的某个部分扩展了它。哪种安排最合理，为什么？

A类结构： - 直观，调试时易于找到源文件。 - 文件命名/目录结构反映类继承关系。

Framework_Control "Framework\Control.php" - Framework_Control_Index "Framework\Control\Index.php" - Framework_Control_Home "Framework\Control\Home.php" - Framework_Control_Contact "Framework\Control\Contact.php" - Framework_Control_About "Framework\Control\About.php"

B类结构： - 使框架模块化且易于替换/更新。 - 在目录结构上增加了一些复杂性，目录/文件命名不再始终遵循类继承关系。

Framework_Control "Framework\Control.php" - Application_Control_Index "Application\Control\Index.php" - Application_Control_Home "Application\Control\Home.php" - Application_Control_Contact "Application\Control\Contact.php" - Application_Control_About "Application\Control\About.php"

我知道总体上这将取决于个人喜好，但在决定哪种方式要走之前，我想确保权衡所有利弊。实际上，这归结为类命名和目录结构，因为实际层次结构在任一情况下都将保持不变。

- Wilco

Answer 1

我建议你将源代码分为两个不同的类别进行查看：外部依赖项或跨多个站点使用且不属于任何一个单独站点的代码，以及本地依赖项或适用于你正在工作的特定站点的代码。

听起来Framework/Control.php是更大的外部依赖项的一部分，应该按照此方式进行管理，而Application/Control文件都是本地的特定网站。

在我们的代码结构中使用这种区分使得我们可以非常容易地在多个站点之间重复使用我们的内部框架。

最后，你可以考虑查看一下主要框架（如Zend Framework、Symfony等）正在做什么。即使整个框架可能超出了你想要的范围，但框架的结构可以提供许多见解，这些见解是PHP开发人员在各个地方使用的常见和良好实践。

- gabriel1836

Answer 2

实际上，问题的关键在于当你更新应用程序 XYZ 中的 Framework\Control.php 文件时，你会采取什么措施。你会回到应用程序 ABC 并进行同样的更改吗？如果这是一个重要的 bug 呢？

为了维护所有项目的可维护性，我建议选择第二个选项。

- Rob Booth