这是一种反模式吗?

发布于 2024-08-18 18:08:56 字数 413 浏览 5 评论 0原文

情况是这样的:您有两个类,它们都实现相同的接口,并且这两个类一起工作来完成某些业务流程。

例如,networkUserManagerlocalUserManager 实现 IUserManager,它有一个方法 getUser()networkUserManager.getUser() 在队列中发出获取 User 的请求并返回回复。 localUserManager.getUser() 从队列中获取请求,在某个数据库中查找用户信息,然后回复用户数据。

当我看到类似的事情正在发生时,我不禁想知道这是否是一个糟糕的设计。这是糟糕的设计吗?如果不是,有什么例子可以说明这样做是个好主意吗?

The situation is this: You have two classes that both implement the same interface and both classes work together to complete some business process.

For example networkUserManager and localUserManager implement IUserManager which has a method getUser(). networkUserManager.getUser() puts a request to get a User on the queue and returns the reply. localUserManager.getUser() gets a request off the queue, finds the user information in some database, and then replies with the user data.

When I saw something similar to this being done, I couldn't help but wonder if this was bad design. Is this bad design and if not what is an example where doing something like this would be a good idea?

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

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

发布评论

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

评论(6

舂唻埖巳落 2024-08-25 18:08:56

这对我来说很难闻。当然,不同的类可能具有相同名称的方法,但如果它们都实现相同的接口,则可以假设它们将执行相同的操作。他们在这里做着相反的事情!

也许是我缺乏想象力,但我无法理解为什么这会是一个好主意。

That smells pretty bad to me. Different classes may have methods with the same name, of course, but if they are both implementing the same interface, then there is an assumption that they will be doing the same thing. Here they are doing opposite things!

Perhaps it's a lack of imagination on my part, but I cannot fathom why that would ever be a good idea.

愿得七秒忆 2024-08-25 18:08:56

您似乎在描述 装饰器 模式。在这种情况下,NetworkUserManager 提供比 LocalUserManager 提供的附加功能。您没有说明您正在使用什么语言,但这种模式出现在整个 java.io 包中。

另一方面,您对 LocalUserManager.getUser() 从队列中提取消息的描述似乎是错误的 - 它与 NetWorkUserManager 的工作方式相反。如果 LocalUserManager 访问数据库,响应其他内容(可能是 NetworkUserManagerService)调用 ,我会认为这是一个合适的装饰器getUser()。

You seem to be describing the Decorator pattern. In this case, the NetworkUserManager provides additional functionality over that provided by the LocalUserManager. You don't say what language you're using, but this pattern appears throughout the java.io package.

On the other hand, your description of LocalUserManager.getUser() pulling a message off the queue seems wrong -- it's backward from the way NetWorkUserManager works. I would see this as being a proper decorator if LocalUserManager accessed the database, in response to something else (perhaps a NetworkUserManagerService) invoking getUser().

岁月蹉跎了容颜 2024-08-25 18:08:56

假设networkUserManager需要从网络获取数据。因此,它将请求放入具有该信息的网络服务器的请求队列中,并且位于服务器上的 localUserManager 实际上为该请求提供服务。当您编写软件的单机版本时,保持它几乎相同可能比花费开发人员时间无缘无故地重写该区域更好。

Suppose networkUserManager needs to get the data from across a network. So it puts a request on the request queue to the network server which has that information, and localUserManager sitting on the server actually services that request. When you write a single-machine version of the software, it's probably better to keep it pretty much the same than to spend developer time rewriting that area for no reason.

爱冒险 2024-08-25 18:08:56

在第一层,我认为它看起来像一个基本的生产-消费队列。

如果我理解正确的话,你需要排队。
进程 A,无论名称如何,都会将事物放入队列中。
进程 B,无论名称如何,都会从队列中取出数据并进行处理。

然后,您在进程 A 希望收到处理队列结果的通知中添加一个额外的次要复杂因素。没什么大不了的。

如果这里有一个不好的做法,我想说的是类的命名和公共接口的使用。他们看起来并不执行类似的任务。看起来它们可能都在同一个类/对象(这个队列)上操作。

At the first level, I think it looks like a basic produce-consume queue.

If I understand you correctly, you have a queue.
Process A, regardless of name, puts things on the queue.
Process B, regardless of name, takes things off the queue and processes them.

Then you add an additional minor complicating factor in that process A wants to be notified of the results of processing the queue. No big deal.

If there is a bad practice here, I would say it is the naming of the classes and the use of the a common interface. They don't seem like they perform similar tasks. It seems like maybe they both operate on the same class/object (this queue).

醉生梦死 2024-08-25 18:08:56

臭气。您的接口定义了实现类同意遵循的契约。在装饰器模式的情况下,您有多个类实现相同的约定,以便您可以将多个类组合在一起。目前还不清楚这里是否发生了类似的事情。

这里的问题是“getUser”是否是一个有意义的抽象,以及它是否封装了您的逻辑,在我看来,这就像分层访问。我认为它隐藏的东西比它照亮的东西多。例如,java.io 装饰器(大部分)可以按任何顺序组合在一起;考虑到您所描述的分层访问权限, LocalManager.getUser(NetworkManager.getUser()) 有意义,而 NetworkManager.getUser(LocalManager.getUser()) 则没有意义。

Bad smell. Your interface defines a contract that implementing classes agree to follow. In the case of a decorator pattern, you have multiple classes implementing the same contract so that you can snap multiple classes together. It's not clear that there's anything like that going on here.

The question here is whether "getUser" is a meaningful abstraction, and whether it encapsulates your logic, which looks to me like tiered access. I'd argue that it hides more than it illuminates. For example, java.io decorators can (mostly) be snapped together in any order; Given the tiered access you're describing, LocalManager.getUser(NetworkManager.getUser()) makes sense, while NetworkManager.getUser(LocalManager.getUser()) doesn't.

狼性发作 2024-08-25 18:08:56

我不会称其为反模式,但绝对是一个非常糟糕的接口实现。 (本帖中提到的“难闻的气味”?)

我什至认为这两个 getUser() 方法应该具有不同的名称,因为尽管它们具有相同的返回值并且没有参数,但它们的“语义”接口明显不同:

  • localUserManager.getUser() 期望队列中已有某些内容
  • networkUserManager.getUser() 没有。

I wouldn't go so far as calling this an antipattern, but definitely a very poor implementation of an interface. ("Bad smell" as mentioned in this thread?)

I would even argue that these two getUser() methods should have different names, since although they have the same return values and no arguments, their "semantic" interfaces are clearly different:

  • localUserManager.getUser() expects something to be already on the queue
  • networkUserManager.getUser() does not.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文