4

Let's say I have a TextBox in my View (in a Passive-View approach). Should it expose the TextBox object itself to the Presenter, or should it expose only the Text property of this object? Furthermore, what about a case when the presenter needs not only the Text property but also some other properties?

For me, it seems like both approaches have pros and cons. If we expose only specific TextBox properties, we give the Presenter control over the precise properties we want it to control. On the other hand, that is a lot of code if we have lots of TextBox properties we want to expose.

If we expose the control itself, we are saving a lot of code, but we do give the presenter the power to change properties we did not intend it to change.

What is the common way to approach this issue?

Improve this question

1 Answer 1

Reset to default
4
+50

Creating automated tests for your components will be much easier if you code to interfaces (instead of concrete classes) of the model and the view. Now rethink your question: do you want to expose the choices of concrete view control classes in such interfaces? - probably not.

From this perspective the answer is clear: expose the properties and methods you need and not more.

Improve this answer
4
  • 1
    Thanks! Why not have the interface with a TextBox property?
    – Michael Haddad
    Sep 19, 2018 at 19:24
  • 1
    In your hypothetical test you would have to create real TextBox instances although you might want to verify only specific behavior of the presenter. Also your interface would be something that is called a leaky abstraction.
    – Hero Wanders
    Sep 19, 2018 at 19:48
  • Thanks! Why not wrap the TextBox with a class that implements an ITextBox interface? And why would it leak the abstraction?
    – Michael Haddad
    Sep 20, 2018 at 15:16
  • Exposing the TextBox in an interface ITextBox is fine as long as that interface really contains what you want your presenter to control/present. Using TextBox directly will couple your presenter to that particular class - it won't be trivial to replace it with other functionally equivalent implementations (for example from a UI library). Such an interface would reveal implementation choices which are (or should be) irrelevant to the presenter, that's why it would be called a leaky abstraction; it's an abstraction which leaks unnecessarily concrete details.
    – Hero Wanders
    Sep 20, 2018 at 19:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.