Question

我有一个扩展Pimple \ Container的自定义类。这个想法是为了我的眼睛包含访问定义服务的丑陋方法（见下文）：

offsetGet($key)       -> get($key)
offsetSet($key, $val) -> set($key, $val)
offsetExists($key)    -> has($key)

这个想法适用于我想要做的事情。然后，我继续创建一个Application类，我选择 INHERITANCE 而不是 AGGREGATION ，不是出于任何特殊原因，而不是看似逻辑。

现在的问题是我有一个ServiceProvider接受一个应用程序实例而不是Pimple \ Container，因为我创建了我自己的ServiceProviderInterface来定义这个合同。

我现在意识到假设Application是并且仍然是一种Container并且让它使用来自父类的不同类型的合同并不是一个好主意。但是，从概念上讲，在我看来，应用程序实例是某种容器，因为在其中我有一些键=＆gt;值存储数据。

我以为Interface Segration原则可以节省我的一天，但我不确定。

我是否可以违反Liskorv替换原则，我对应用程序的假设扩展了Pimple \ Container关系？
有没有什么方法可以使用我自己的界面来注册我的服务提供商，因为我传递的任何服务都不符合pimple \ ServiceProvider合同的错误磕磕绊绊？

简单来说，是否有可能扩展Pimple的容器并忽略库的服务提供者并使用你定义相同合约但具有不同参数的那个？

Answer 1

首先，

我的想法是将用于访问已定义服务的丑陋方法包装在我眼中

丑陋的方法来自ArrayAcess接口，它允许您以类似数组的形式访问属性：

$container = new Pimple();
$container['session_storage'] = function ($c) {
    return new SessionStorage('SESSION_ID');
};

$container['session'] = function ($c) {
    return new Session($c['session_storage']);
};

然后我继续创建一个Application类，我选择INERGITANCE over AGGREGATION而不是出于任何特殊原因而不是看似逻辑

这是错的。在可能的情况下，您应该始终选择Aggregation over Inheritance。

继承是一种静态的紧密耦合关系，它仅限于PHP中的一种。您无法在运行时更改继承。

另一方面，组合是动态的，如果按照SOLID原则实施，则可能会失去耦合。使用合成时，您可以在运行时完美地切换关系。

现在的问题是我有一个接受的ServiceProvider 自从我创建以来，应用程序实例而不是Pimple \ Container 我自己的ServiceProviderInterface定义了这个合同。

这没有意义！为什么服务提供商会依赖您的申请？不应该反过来吗？提供者是一个独立的模块。您的应用程序有多个依赖项。

关于您的问题，

了解您是否违反LSP的最佳方法是问自己：
我是否可以将Container对象替换为Application对象而不会丢失任何功能？
NOP。接口是合同，合同应该受到尊重。

接口与PHP Pimple冲突

1 个答案: