没有单例的 PHP 前端控制器实现:概念问题

发布于 2024-10-31 02:14:01 字数 658 浏览 1 评论 0原文

我有一个关于 php 中前端控制器实现的“概念”问题。

我见过的大多数前端控制器都是用单例实现的,我不是单例模式的忠实粉丝,我创建了一个容器,它有一个静态属性,用于存储前端控制器的唯一实例。

对于单例,我必须将初始化代码放入构造函数(或构造函数调用的方法)中:

$fc = FrontController::getInstance();

使用容器,我可以将配置放在 FrontController 之外,这是我的目标,而且我仍然有一种简单的方法来检索 FrontController。

$fc = Container->getFrontController();

这段代码对我来说看起来更干净,我可以得到干净的子类化而无需关心父构造函数。

在“引导”时这是完全相同的事情,但实际上与我之前的实现的区别在于,现在我可以在应用程序中的任何位置(在 DAO 内或在 Action 内)创建 FrontController,因为构造函数不再是私有/受保护的。

我的问题是: 为我的类的用户提供在应用程序中的任何位置创建 FrontController 实例的可能性是一种“不好的做法”吗?我会编写文档并与其他类一起交付容器,但我仍然想知道是否应该防止奇怪的使用。

i have a "conceptual" question about Front controller implementation in php.

Most of the Front Controllers i have seen around are implemented with Singleton, i am not a big fan of singleton pattern and i created a Container which has a static property that will store a unic instance of Front Controller.

With singleton, i had to put initialization code inside the constructor (or a method called by the constructor):

$fc = FrontController::getInstance();

With the container i could put configuration outside the FrontController, that was my goal and i still have a simple way to retrieve the FrontController.

$fc = Container->getFrontController();

This code looks much cleaner to me and i can get clean subclassing without caring about parent constructors.

That's quite the same thing at 'bootstrap' time, but in practice the difference from my previous implementation is that now i can create FrontControllers anywhere in the application (inside a DAO or inside a Action), because the constructor is no longer private/protected.

My question is:
Is it a 'bad practice' to give to the user of my classes the possibility to create FrontController instances anywhere in the app? I would write documentation and deliver the container with other classes, but i still wonder if i should prevent strange uses.

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

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

发布评论

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

评论(2

甜宝宝 2024-11-07 02:14:01

是否有真正的理由在应用程序内创建 FrontController 实例?如果有那就继续吧。否则我对此有点怀疑,因为它可能会让以后的事情变得复杂。我担心的是有人在有更简单的方法时使用新的 FrontController 实例,要么是出于懒惰,要么是因为他们不知道更好的方法。一旦发现一些可行的方法,有些人就会倾向于继续这样做,即使有更好的方法。永远不要忘记,您可能必须与不如您的人一起工作。

就我个人而言,我会隐藏这一点或完全不允许它。不过,我会在以后的版本中记住这一点。如果您偶然发现它是最佳选择的情况,请将其添加到您的“官方”界面。

不要忘记,一旦你将一个函数释放到野外,就很难将其杀死。

Is there any real reason to create FrontController instances inside the app? If there is then go ahead. Otherwise I am a bit skeptical about this as it may complicate things later on. What I'm afraid of is someone using new FrontController instances when there is a much simpler way, either out of laziness or because they don't know any better. Once they find something that works, some people tend to keep doing it even if there's a better way. Never forget that you may have to work with people that are not as good as you.

Personally I would hide this or not allow it altogether. However I would keep it in mind for later releases. If you ever stumble on a case where it's the best option by all means add it to your "official" interface.

Don't forget that once you release a function into the wild, it's excruciatingly difficult to kill it off.

扬花落满肩 2024-11-07 02:14:01
$fc = Container::getFrontController();

对我来说听起来不错。

我不认为允许开发人员在任何地方检索 Front Controller 实例是一个坏习惯,如果您正确控制开发人员可以使用它做什么(例如,不要覆盖某些属性或以错误的顺序执行其方法而不显示向用户发出错误/警告)。

$fc = Container::getFrontController();

sounds Ok for me.

I don't think it would be a bad practice to allow developers to retrieve the Front Controller instance anywhere, if you control correctly what developers can do with it (e.g. do not overwrite some property or execute its methods in a wrong order without showing an error/warning to the user).

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