How Do Interfaces Reduce Dependencies

[Jeff S]

How do interfaces help us achieve separation or reduce dependencies between
classes?

Suppose I have a "PersonPresenter" class and want to enable its data to be
editable in a Form. I have read that, in order to separate the UI from the
data, we can implement a view (e.g., IPersonView) in the form (e.g., class
PersonForm : Form, IPersonView) as part of the solution. I just don't see
how implementing an interface causes us to separate anything - especially in
this example - because the PersonForm class would have to implement the view
(i.e, it would have all the code that implements the IPersonView methods and
properties). I see no separation given that the form module physically
contains all the code that implements the view. I don't see that the form is
a black box in this situation.

Am I missing something?

Thanks!

[Scott C]

Jeff S wrote:

How do interfaces help us achieve separation or reduce dependencies between
classes?

Suppose I have a "PersonPresenter" class and want to enable its data to be
editable in a Form. I have read that, in order to separate the UI from the
data, we can implement a view (e.g., IPersonView) in the form (e.g., class
PersonForm : Form, IPersonView) as part of the solution. I just don't see
how implementing an interface causes us to separate anything - especially in
this example - because the PersonForm class would have to implement the view
(i.e, it would have all the code that implements the IPersonView methods and
properties). I see no separation given that the form module physically
contains all the code that implements the view. I don't see that the form is
a black box in this situation.

Am I missing something?

Thanks!

Maybe I'm being a bit rash, but I think (if I read correctly) it's the
other way around. It is the *Person* class that is the black box. So
to take your example one step further, say you wanted to use one form
(for some reason) as an interface for a class Car and also a class
Bicycle. In order for the Form to not know what object it really has,
both Bicycle and Car could implement an interface IVehicleView.

Others may have better or different ways of doing this, but in my form I
have a field holding the object:

class MyView : Form {
// all the other stuff
private IVehicleView vehicle;
}

Then, depending on what the interface definition is, you could
read/write to the actual object without knowing what it is. The trick
is that the form knows how to "edit" the object, but the object itself
(Car or Bicycle) doesn't have any idea it is being displayed (otherwise
it would have put on make-up).

(Rereading the OP): In your words, the "black box" is not the form but
the object implementing IVehicleView. The Form and (Car or Bicycle) are
completely separated from each other except for the "link" through the
interface.

Scott

[Lasse Vågsæther Karlsen]

Jeff S wrote:

How do interfaces help us achieve separation or reduce dependencies between
classes?

Suppose I have a "PersonPresenter" class and want to enable its data to be
editable in a Form. I have read that, in order to separate the UI from the
data, we can implement a view (e.g., IPersonView) in the form (e.g., class
PersonForm : Form, IPersonView) as part of the solution. I just don't see
how implementing an interface causes us to separate anything - especially in

In this example you could give an instance of your form to your Person
object (via an interface reference) and all the Person object would know
is that it deals with something that can view a person.

Exactly what object it deals with is unknown and unnecessary to know and
thus you gain separation.

The alternative would be for you to write code in your Person object to
handle that specific Form object and thus you have coupled that Person
object to that particular class, and thus no separation.

--
Lasse Vågsæther Karlsen
http://usinglvkblog.blogspot.com/
mailto:la***@vkarlsen.no
PGP KeyID: 0x2A42A1C2

[Jeff S]

"Scott C" <sdcoonce@g_m_a_i_l.com> wrote in message
news:OH**************@TK2MSFTNGP10.phx.gbl...

Jeff S wrote:

How do interfaces help us achieve separation or reduce dependencies
between classes?

Suppose I have a "PersonPresenter" class and want to enable its data to
be editable in a Form. I have read that, in order to separate the UI from
the data, we can implement a view (e.g., IPersonView) in the form (e.g.,
class PersonForm : Form, IPersonView) as part of the solution. I just
don't see how implementing an interface causes us to separate anything -
especially in this example - because the PersonForm class would have to
implement the view (i.e, it would have all the code that implements the
IPersonView methods and properties). I see no separation given that the
form module physically contains all the code that implements the view. I
don't see that the form is a black box in this situation.

Am I missing something?

Thanks!

Maybe I'm being a bit rash, but I think (if I read correctly) it's the
other way around. It is the *Person* class that is the black box. So to
take your example one step further, say you wanted to use one form (for
some reason) as an interface for a class Car and also a class Bicycle. In
order for the Form to not know what object it really has, both Bicycle and
Car could implement an interface IVehicleView.

Others may have better or different ways of doing this, but in my form I
have a field holding the object:

class MyView : Form {
// all the other stuff
private IVehicleView vehicle;
}

Then, depending on what the interface definition is, you could read/write
to the actual object without knowing what it is. The trick is that the
form knows how to "edit" the object, but the object itself (Car or
Bicycle) doesn't have any idea it is being displayed (otherwise it would
have put on make-up).

(Rereading the OP): In your words, the "black box" is not the form but the
object implementing IVehicleView. The Form and (Car or Bicycle) are
completely separated from each other except for the "link" through the
interface.

Scott

Thanks Scott,

Perhaps that's why things didn't make sense to me. Maybe I just got it
backwards, but I'm not sure yet. I was reading an article whose whole point
was to demonstrate how to pull out all data and associated logic from the
view (form). Part of the solution was to implement an interface in the form
(FWIW; here's what I was reading:
http://www.martinfowler.com/eaaDev/M...resenter.html). It just seems
like a whole lot of work and you don't really have the claimed independence
at the end of the day because the form has to "know about" the underlying
data/class at least to the extent that the form must implement an interface.

-J

[Jon Skeet [C# MVP]]

Jeff S wrote:

How do interfaces help us achieve separation or reduce dependencies between
classes?

By specifying that the only things needed by (and available to) one
object are the members of the interface. Anything else which may happen
to be available in the implementing class is effectively invisible.
There may be many implementations of the interface - for instance, one
web UI and one Windows Forms UI - but so long as they both implement
the interface, then whatever is using that interface needn't know what
it's actually using behind the scenes.

(As an aside, using interfaces makes life a lot simpler at the unit
test level, as mocking frameworks generally work much better with
interfaces than classes - you can "expect" certain calls and respond to
them in appropriate ways.)

Jon

[Nick Hounsome]

I have edited this quite a bit in view of your reference to teh fowler
article:

"Jeff S" <[e-mail]> wrote in message
news:eq**************@TK2MSFTNGP15.phx.gbl...

"Scott C" <sdcoonce@g_m_a_i_l.com> wrote in message
news:OH**************@TK2MSFTNGP10.phx.gbl...

Jeff S wrote:

How do interfaces help us achieve separation or reduce dependencies
between classes?

Suppose I have a "PersonPresenter" class and want to enable its data to
be editable in a Form. I have read that, in order to separate the UI
You haven't read the article properly - The PersonPresenter has no data - It
is an intermediary between the Person(data) and PersonForm(view).
the data, we can implement a view (e.g., IPersonView) in the form (e.g.,
class PersonForm : Form, IPersonView) as part of the solution. I just
don't see how implementing an interface causes us to separate anything -
especially in this example - because the PersonForm class would have to
implement the view (i.e, it would have all the code that implements the
IPersonView methods and properties). I see no separation given that the
form module physically contains all the code that implements the view. I
don't see that the form is a black box in this situation.

Am I missing something?

Consider:

class PersonForm : Form, IPersonView.....

class PersonFormForTheVisualyImpaired : Form, IPersonView....

Switching to the new form (possibly by config file) Requires no code change
other than passing a PersonFormForTheVisualyImpaired rather than a
PersonForm to the PersonPresenter in its constructor

PersonPresenter(IPersonView view,Person person)....
Thanks!

Maybe I'm being a bit rash, but I think (if I read correctly) it's the
other way around. It is the *Person* class that is the black box. So to
take your example one step further, say you wanted to use one form (for
some reason) as an interface for a class Car and also a class Bicycle.
In order for the Form to not know what object it really has, both Bicycle
and Car could implement an interface IVehicleView.
This is a completely different problem:

Your "solution" is reasonable but the interface would be called IVehicle and
not IVehicleView. Furthermore it would be better and simpler to simply move
the common vehicle stuff into a common base class Vehicle of both Car and
Bicycle firstly because it is less code a secondly because base classes are
more robust under versioning than interfaces (Clearly this is not an option
with the views). The form would also necessarily be called VehicleForm.

Others may have better or different ways of doing this, but in my form I
have a field holding the object:

class MyView : Form {
// all the other stuff
private IVehicleView vehicle;
}

Then, depending on what the interface definition is, you could read/write
to the actual object without knowing what it is. The trick is that the
form knows how to "edit" the object, but the object itself (Car or
Bicycle) doesn't have any idea it is being displayed (otherwise it would
have put on make-up).

(Rereading the OP): In your words, the "black box" is not the form but
the object implementing IVehicleView. The Form and (Car or Bicycle) are
completely separated from each other except for the "link" through the
interface.

Scott

As I said this is a different problem entirely.

Thanks Scott,

Perhaps that's why things didn't make sense to me. Maybe I just got it
backwards, but I'm not sure yet. I was reading an article whose whole
point was to demonstrate how to pull out all data and associated logic
from the view (form). Part of the solution was to implement an interface
in the form (FWIW; here's what I was reading:
http://www.martinfowler.com/eaaDev/M...resenter.html). It just seems
like a whole lot of work and you don't really have the claimed
independence at the end of the day because the form has to "know about"
the underlying data/class at least to the extent that the form must
implement an interface.

-J

It's a good article - Read it again whilst thinking about my earlier
example.

[Jeff S]

Thank you very much Nick (and all others).

-Jeff