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
3
+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? Commented 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. Commented 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? Commented 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. Commented Sep 20, 2018 at 19:54

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.