被动观点是否违反了迪米特法则？

发布于 2024-07-22 05:42:27 字数 167 浏览 7 评论 0原文

我试图了解如何正确使用被动视图。在我看来，我在被动视图上看到的每个例子都违反了德米特定律：

//In the presenter code
myview.mytextfield.text = "whatever";

那么被动视图的更好实现是什么？

原文

I'm trying to understand how to use Passive View correctly. It seems to me that every examples I look at on Passive View breaks the Law of Demeter :

//In the presenter code
myview.mytextfield.text = "whatever";

So what's a better implementation of Passive View?

分享到QQ

分享到微博

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

发布评论

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

诗笺 2024-07-29 05:42:28

首先，与大多数编程规则一样，德墨忒尔定律更多的是一种原则或指导方针，有时该原则并不适用。话虽这么说，德米特定律并不真正适用于被动视图，因为在这种情况下，该定律的原因不是问题。

德米特法则试图阻止依赖链，例如：

objectA.objectB.objectC.DoSomething();

显然，如果 objectB 的实现更改为使用 objectD，那么它将破坏 objectA 的依赖关系并导致编译错误。如果采取极端的做法，每当链条因实施变更而受到干扰时，您都会进行猎枪手术。

在被动视图的情况下，

呈现器依赖于接口，因此只要接口保持不变，视图的实现就可以更改。
视图通常将属性公开为通用数据类型，例如系统类型和集合。这使您可以更改 UI，而不会影响演示者。
对于演示者来说，视图只不过是一个数据结构，一个检索和转储数据的地方。由于视图非常简单，演示者甚至不应该能够进行依赖链。

因此，您给出的示例通常会被实现：

//from presenter
view.MeaningfulName = "data";

而视图将类似于：

//from view
public string MeaninfulName
{
    get
    {
        return someControl.text;
    }
    set
    {
        someControl.text = value;
    }

希望这可以澄清一些事情。

First, the Law of Demeter, like most rules of programming, is more of a principle or guideline and there are occasions when the principle doesn't apply. That being said, the Law of Demeter doesn't really apply to Passive View because the reason for the law isn't a problem in this case.

The Law of Demeter is trying to prevent dependency chaining such as:

objectA.objectB.objectC.DoSomething();

Obviously if objectB's implementation changes to use objectD instead then it will break objectA's dependency and cause a compilation error. If taken to an extreme you wind up doing shotgun surgery any time the chain is disturbed by an implementation change.

In the case of Passive View

The presenter depends on an interface so the view's implementation can change as long as the interface remains the same.
The view usually exposes properties as generalized data types such as system types and collections. This allows you to make changes to the UI without affecting the presenter.
To the presenter the view appears as nothing more than a data structure, a place to retrieve and dump data. Since the view is pretty simple, the presenter shouldn't even be able to do dependency chaining.

So the example you gave would normally be implemented:

//from presenter
view.MeaningfulName = "data";

While the view would be something like:

//from view
public string MeaninfulName
{
    get
    {
        return someControl.text;
    }
    set
    {
        someControl.text = value;
    }

Hope this clarifies things a bit.

回复收藏 0 原文

不念旧人 2024-07-29 05:42:28

更好的实现是在 Presenter 和 View 之间使用 API。 Presenter 将通过单个方法（在 View 的接口中定义）将数据推送到其 View。视图将根据某些内部逻辑管理新输入。

因此，演示者不必了解有关视图的任何信息，并且德米特法则是安全的。

回复收藏 0 原文

岁月蹉跎了容颜 2024-07-29 05:42:28

好吧，是的，这确实违反了德米特定律，该定律基本上说对象的接口不应该揭示对象的实现。但是，第二个也为实现提供了很多提示。

我认为是时候问问你总体上是否有正确的界面了。这些文本字段是什么？？谁将它们设置在视图中？视图不应该向模型请求数据，而不是相反？

也许您需要观察者模式——模型保留感兴趣方的列表，并在其内部状态发生变化时通知他们。

啊，那个被动观点。好久没看过这个了。基本上，我看到两个部分：其中之一是通过使控制器（而不是模型）驱动所有更新，为了（我认为）效率，他公开了特定的字段方法来更新这些字段。这确实违反了德墨忒尔定律，毕竟它只是某种隐喻意义上的“定律”，就像墨菲定律一样。不过，这通常是个好主意。在这种情况下，我将重做视图并将其用作外观来包装对各个字段的更新。

不过，您不需要观察者模式，因为现在您已经让控制器进行了所有更新。它增加了整体代码的复杂性和易出错性，因为现在您必须编写控制器来进行并行更新。

回复收藏 0 原文

~没有更多了~