Good Magento的系统允许开发人员通过将重写引入模块的XML配置中来轻松覆盖核心类。这是通过使用字符串作为真实类名的抽象来实现的，该字符串传递给Mage::getModel($key)用于类实例化的方法，而不是传统的$object = new MyClassName();。
因此，我们可以轻松地生成将表键映射到类名的查找表，并返回相应的类。此查找表由Magento初始配置填充并修改，然后进行重写。
这很好吗？如果要向类的getProduct()方法中添加一些额外的功能，Mage_Product_Model_Product则只需创建自己的Nick_Rocks_Model_Product类并更改功能，然后添加重写即可。
Bad Bad 当我需要向该getProduct()方法添加一些额外的功能时，会发生什么？我决定没有足够的时间自己重写模块，因此我检查了Magento Connect并找到了最适合我当前需求的模块。我安装后，只有发现我的初始模块添加的额外功能已被删除，并且仅保留了额外功能。该死 坏菊菊
The F-ugly 我们该如何解决这个问题？我们有两种情况。
- 覆盖类以仅提供额外的方法
- 覆盖类以更改新方法的功能
在第一种情况下，我们可以通过实现多种继承来轻松解决问题。Josh Ribakoff提供了一个实现。这里引入了明显的性能开销–如果我们有一堆试图重写该类的类，该怎么办？我们必须调用这些类中的每一个，并检查对象是否存在该方法，或者使用一些巧妙的反射。坏菊菊
先前的解决方案不能解决覆盖特定方法的问题。考虑一下我们所有想要覆盖同一方法的长清单类吗？我们让哪一个去做？
解决方案
这很简单。使用事件侦听器，帮助器或扩展（而不是覆盖）核心类以形成您自己的核心类。
进行此类更改的唯一缺点是，当重写核心类不需要时，它们可能需要进行设计更改。大不了 认真对待其商店的任何人都会雇用某人来安装模块并自行进行设计更改。当涉及机密的用户信息时，不应有偷偷摸摸的消息。
好吧，这不是那么简单。有时，用于观察的挂钩根本不在代码中。其中部分取决于Magento的核心开发人员。我确信他们会同意他们并不总是在考虑模块开发人员的情况下进行编码。以“订单”屏幕的“群众活动”部分为例。在下拉菜单中添加另一个选项的唯一方法是扩展类并自己修改按钮。
这里有一些想法。
什么时候（理想情况下）使用事件监听器：
- 在管理区域添加按钮（Magento不支持）
- 向下拉菜单添加值
- 在重要系统事件之后/之前执行操作（添加/删除/更新订单/发票/产品/配置）
何时使用助手：
- 用例：显示通过完成此订单获得的奖励积分数（
Mage::helper('rewards')->getOrderRewardPoints($_order)，而不是$order->getRewardPoints()）
何时扩展核心类：
- 当您需要向内部类功能添加更多逻辑时
- 用例：
Mage::getModel('my/order')->load($_orderId)->sendSMS()
随着Magento的不断发展，我们需要将模块与Magento的内部组件松散耦合。老实说，即使需要对设计进行一些更改，模块也应该能够在不扩展单个核心类的情况下运行。
我认为这是这样做的方式。你怎么看？