扩展核心 PHP 类而不是依赖注入?

发布于 2024-10-16 11:36:13 字数 304 浏览 2 评论 0原文

我正在开发一个应用程序,该应用程序将有一个“库”文件夹,其中包含一个自制框架/库(会话、数据库、缓存、配置类型类),然后是一个“模块”文件夹,其中包含我的应用程序各部分的文件夹(即;博客/、论坛/、帐户/等)

在我的大多数模块(博客、论坛等)中,我需要多个对象,如缓存、数据库、记录器、配置对象。我本来打算为此使用依赖注入,但我很好奇,我难道不能有一个核心类/对象来执行诸如数据库、缓存、记录器、时间、方法之类的操作,然后将此核心类扩展到我的其他类中吗?模块类并可以访问所有这些东西而不需要注入它们?

我对使用类/对象还很陌生,所以我可能离这里很远,请解释一下。

I am working on an application that will have a "library" folder which will contain a homemade framework/library (session, DB, cache,config type classes) and then a "modules" folder which will contain folders for the sections of my app (ie; blogs/, forums/, account/, etc,etc)

In most of my modules (blogs, forums, etc), I will need multiple objects like cache, database, logger, config objects. I was planning on using dependency injection for this but I am curious, couldn't I just have a Core class/object that could do stuff like my database, cache, logger, time, methods and then just extend this core class into my other module classes and have access to all these things without needing to inject them?

I am pretty new to using classes/object so I may be way off here, please explain.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

是你 2024-10-23 11:36:13

类应该具有单一职责。执行缓存、数据库访问、日志记录和时间等功能的核心类实际上是一个God Object 又名 The Blob。这是一个AntiPattern。不要那样做。使它们SOLID

Classes should have a single responsibility. A Core class doing caching, db access, logging and time, etc is effectively a God Object aka The Blob. It's an AntiPattern. Don't do that. Make them SOLID.

万人眼中万个我 2024-10-23 11:36:13

如果您专门化类,或者扩展它们,那么扩展类就有意义。
如果扩展与基类的原始目的无关,那么它就没有意义,并且通常会变得混乱。

例如,您可以使用 DbMySql 类(专业化)扩展 DbBase 类,或者使用 Html5Helper 扩展 HtmlHelper 。 >(扩展名)。

您不应将 DbClass 扩展为 ProductsModule。两者没有任何关系。 ProductsModule 本身并不绑定到数据库,因此您混合了彼此无关的职责。

Extending classes makes sense if you specialize classes or, well, extend them.
It doesn't make sense and usually becomes messy if the extension has nothing to do with the original purpose of the base class.

For example, you may extend a DbBase class with a DbMySql class (specialization), or an HtmlHelper with an Html5Helper (extension).

You should not extend your DbClass into a ProductsModule. Both have nothing to do with each other. The ProductsModule is not inherently bound to a database, so you're mixing responsibilities that have nothing to do with each other.

心病无药医 2024-10-23 11:36:13

我也同意戈登的观点。

我个人避免使用工厂静态方法方法。本质上,它相当于使用全局变量。这是服务定位器反模式。

除了建议的 DI 容器之外,我发现手动依赖项注入(即使用 DI 容器)也是一种很有价值的方法。没有任何工具(即容器)可以将您的类设计为松散耦合,我发现使用手动 DI 有助于专注于这一点。

[PS 我本来想将此添加为评论,但我是新人,无法发表评论]

I also agree with Gordon.

Personally I avoid the Factory static method approach. In essence, it's equivalent to using a global variable. It's the Service Locator anti-pattern.

In addition to the suggested DI container, I find manual dependency injection (i.e. with using a DI container) to be a valuable approach. There's no tool (i.e. container) that can design your classes to be loosely coupled, and I find that using manual DI is helpful for focusing on that.

[P.S. I would have added this as a comment, but I'm new and am unable to comment]

美人如玉 2024-10-23 11:36:13

可以做的是创建一个工厂类来实例化并提供您需要的单个对象。诸如此类:

$db = myFactory::getDBO();
$conf = myFactory::getConfig();
$session = myFactory::getSession();

等等。

What you CAN do, is creating a Factory class that instantiates and provides the single objects you need. Somthing like:

$db = myFactory::getDBO();
$conf = myFactory::getConfig();
$session = myFactory::getSession();

and so on.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文