Search code examples
law-of-demeterpassive-view

Does Passive View breaks the Law of Demeter?


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?


Solution

  • 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.