在真正的Magento混乱中，有两组控制器类; Controller目录中的那些目录和controllers目录中的目录。前者的名称类似于Mage_Adminhtml_Controller_Action，后者的名称为Mage_Adminhtml_IndexController。后者通常是前者的后代。
由于后者没有将其名称干净地映射到PEAR naming convention中的位置，因此普通自动加载器无法自动加载，因此您无法从脚本include中找到它们，因为您无法确定他们所在的代码池，它可能会破坏编译功能。
我觉得因为扩展它们很难，所以应该正式final并完成它。这会破坏我没想到的任何东西吗？不知怎的，这是不好的做法？任何人都可以建议更好的术语来描述可扩展的类和该死的难以扩展的类吗？
答案 0 :(得分：4)
人们应该使用magento方法获取控制器类的路径，然后它不会破坏编译器，因为方法会返回正确的路径。
require_once Mage::getModuleDir('controllers', 'Mage_Checkout').DS.'OnepageController.php';
答案 1 :(得分：3)
那太糟糕了。
如果你及时回到也许，你可以提出一个案例，宣布那些控制器是最终的，以避免你所讨论的问题，但是引入这样的改变会显着破坏< / strong>大量的Magento装置在野外出现。在许多情况下，扩展基本控制器以实现新的商店功能（甚至覆盖/重写功能）是正确的举措。现在让它们成为最终意味着你不仅要打破应用程序，还要以一种无法从中恢复的方式打破它们。
即使你回到过去，我也不确定你的挫折（虽然可以理解）是否有原因
这听起来更像是修复和/或添加其他自动加载器的案例
我不确定我是否关注这里的问题。包括基本控制器就像
一样简单require_once('Mage/Catalog/controllers/CategoryController.php');
不，你不确定他们在哪个代码池......那没关系。代码池的重点是它们具有回退PHP包含路径，允许用户在不需要破坏核心的情况下使用自己特定类的版本。
我不熟悉这里描述的问题，但同样，听起来更像是扩展/修复编译器的功能
将控制器类作为final来解决这些问题，就像使用火箭筒来处理家用鼠标的问题一样。我们拥有控制器类的全部原因是我们的应用程序上的其他URL可以继承功能。即使你不相信那些你是建筑师的项目，在给予它之后取消它，充其量也是一个糟糕的举动。