Erm, how do you know when to make an interface? :-)

[Simon Harvey]

Festive greetings fellow programmers!

I've been programming now for about 4, maybe 5 years now. 4 of those years
were at university so and I havent had much work experience of making real
world applications (although I trying to make some now). There is still a
lot I don't know when it comes to making programs. I know all the theory,
but not how (and why) certain things are done in real world projects.

My current ponderings are about interfaces. I think I understand the
theory -

An interface is used to define a contract between two entities. One entity
implements an interface, and the other entity can program against that
interface and know that whatever object is there at runtime - as long as the
interface is implemented - everything will be fine.

Well, thats nice then. I can understand why that might be a good idea on
occasion (in theory). You being able to say - "Ok, I don't want to know what
the actual object is as such; I just want to know that it will fulfill its
obligations".

The thing I'm crap at is - knowing when to create an interface.

How do you know? What objects should have interfaces made for them? I havent
got a clue because I was never taught about it.

I'm currently trying to make an email application that will store received
messages on the file system. I'm trying to figure out if I should make any
interfaces - but I just don't know.

I could make an interface for loads of objects, but I'm not sure what the
point would be. I'm sure I should have at least some interfaces, but I don't
know where to make them and so on. It's really a problem of implementation.

Could anyone offer me some general advice on how you can spot potential
interfaces. I mean, there must be some approach to it; some sort of rules
that developers either conciously or subconsiously apply. If anyone could
offer any advice at all on how to spot/determine when an interface should be
employed, then that would be excellent.

Many thanks to anyone who can help.

Kind Regards

Simon

[Frank Oquendo]

Simon Harvey wrote:

The thing I'm crap at is - knowing when to create an interface.

The moment I come across something that I think might make a case for
inheritance, I immediately backtrack and see if an interface makes more
sense. And it usually does.

There's no hard and fast rule. It should just be the first thing on your
mind when you discover a need for uniform behavior from disparate
objects. For example, if your email app will support plugins, you'll
want to develop an interface so you can operate those plugins without
knowing anything about them.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

[Scott M.]

If you want to define a "look and feel" without actually determining what a
certain look means or what a certain feel does then use interfaces.
"Simon Harvey" <sh856531@micro softs_free_emai l_service.com> wrote in message
news:uN******** ******@tk2msftn gp13.phx.gbl...

Festive greetings fellow programmers!

I've been programming now for about 4, maybe 5 years now. 4 of those years
were at university so and I havent had much work experience of making real
world applications (although I trying to make some now). There is still a
lot I don't know when it comes to making programs. I know all the theory,
but not how (and why) certain things are done in real world projects.

My current ponderings are about interfaces. I think I understand the
theory -

An interface is used to define a contract between two entities. One entity
implements an interface, and the other entity can program against that
interface and know that whatever object is there at runtime - as long as the interface is implemented - everything will be fine.

Well, thats nice then. I can understand why that might be a good idea on
occasion (in theory). You being able to say - "Ok, I don't want to know what the actual object is as such; I just want to know that it will fulfill its
obligations".

The thing I'm crap at is - knowing when to create an interface.

How do you know? What objects should have interfaces made for them? I havent got a clue because I was never taught about it.

I'm currently trying to make an email application that will store received
messages on the file system. I'm trying to figure out if I should make any
interfaces - but I just don't know.

I could make an interface for loads of objects, but I'm not sure what the
point would be. I'm sure I should have at least some interfaces, but I don't know where to make them and so on. It's really a problem of implementation.
Could anyone offer me some general advice on how you can spot potential
interfaces. I mean, there must be some approach to it; some sort of rules
that developers either conciously or subconsiously apply. If anyone could
offer any advice at all on how to spot/determine when an interface should be employed, then that would be excellent.

Many thanks to anyone who can help.

Kind Regards

Simon

[Chris Capel]

As far as object-oriented programming can be seen as an attempt to make
analogies between programming languages and the real world, interfacing vs.
inheritance can be seen as the difference between an object _being_
something and an object _doing_ something. If a class, A, is able to do
*foo*, and another class, B, needs to use a number of different objects that
do *foo*, the behavior, foo, should be an interface, so that different
classes than A can implement the interface, and B will be able to use them
all. However, if class B needs not classes that *do* foo, but classes that
*are* bar, then inheritance is more appropriate for the situation. It's up
to you to decide where to draw the line between behavior and identity.

Chris C.

[Peter Rilling]

To expand on this, consider if there will need to be some logic higher in
the class structure that will need to be handled by all similar types.
Interfaces are great if your classes will have self-contained logic,
otherwise you might consider a class hierarchy.

Also, remember that C# does not support multiple inheritance, so you also
need to identify behaviors that may be independent but need to be
implemented on the same class.

"Frank Oquendo" <fr****@acadxpi n.com> wrote in message
news:ef******** ******@TK2MSFTN GP10.phx.gbl...

Simon Harvey wrote:

The thing I'm crap at is - knowing when to create an interface.

The moment I come across something that I think might make a case for
inheritance, I immediately backtrack and see if an interface makes more
sense. And it usually does.

There's no hard and fast rule. It should just be the first thing on your
mind when you discover a need for uniform behavior from disparate
objects. For example, if your email app will support plugins, you'll
want to develop an interface so you can operate those plugins without
knowing anything about them.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

[Jimmy [Used-Disks]]

> How do you know? What objects should have interfaces made for them? I
havent

got a clue because I was never taught about it.

Create an interface when you cannot (or do not want to) rely on a specific
object hierarchy.

For example, most of the applications I write are for use in both Windows
and the Web. In my Windows apps I store end-user settings on the local
machine, however in Web apps I store them in cookies.

This brings up a dilemma - how do I access end-user preferences uniformly?
In other words, I want a single code-base for Windows apps and Web apps. To
do this, I define an interface. Here's an example:

public interface IEndUser : object
{
string Name{
get;
set;
}

Color FavoriteColor{
get;
set;
}

// ... whatever ...
}

Now I can write two objects, both implementing IEndUser. One will be for
Windows and the other for the Web, and I can share any code which uses the
interface between applications.

Another use for interfaces is the ability to test for certian functionality.
For example, you have a method which works for any object, but if the object
implements IDoThisToo then you could use the IDoThisToo interface to
implement special features.

--
-Jimmy

[Simon Harvey]

Wow! I didnt expect that many replies. I only posted this an hour or so ago!

Thanks for that everyone. Two quick questions:

1. When should I use an abstract class instead of an interface
2. Given that I understand the theory, can anyone suggest some good books on
actual *implementation *. The theory behind these topics is all relatively
simple, but where I (and many others) fall down is actually knowing when,
where and why to apply the theory to actual real world problems.

I think what I would definately benefit from would be a book or tutorial
that discusses a real world application and where/why certain OO mechanisms
were employed. E.g. "We're going to define an Interface here because ....X
.....Y ..... Z. This will allow us to blahh blahh blah further down the
line".

I havent really ever found a book or online resource that discusses this
sort of stuff at the level I need. I mean there are reference applications
from MS and Sun, but they are all focused on showing off their fancier
features like RMI, web services, distributed programming/remoting and so on.
I just need something that talks about some everyday applications and how
they were built from an architectural point of view.

Thanks guys
Simon

[Chris Capel]

> 1. When should I use an abstract class instead of an interface

2. Given that I understand the theory, can anyone suggest some good books on actual *implementation *. The theory behind these topics is all relatively
simple, but where I (and many others) fall down is actually knowing when,
where and why to apply the theory to actual real world problems.

I think what I would definately benefit from would be a book or tutorial
that discusses a real world application and where/why certain OO mechanisms were employed. E.g. "We're going to define an Interface here because ....X
....Y ..... Z. This will allow us to blahh blahh blah further down the
line".

I havent really ever found a book or online resource that discusses this
sort of stuff at the level I need. I mean there are reference applications
from MS and Sun, but they are all focused on showing off their fancier
features like RMI, web services, distributed programming/remoting and so on. I just need something that talks about some everyday applications and how
they were built from an architectural point of view.

Thanks guys
Simon

[Chris Capel]

> 1. When should I use an abstract class instead of an interface

Use an abstract class when you need to provide actual class logic as well as
an interface. If you can make your abstract base class do most of what you
need your child classes to do, with slight modifications or additions, then
this is the way to go.

2. Given that I understand the theory, can anyone suggest some good books on actual *implementation *. The theory behind these topics is all relatively
simple, but where I (and many others) fall down is actually knowing when,
where and why to apply the theory to actual real world problems.

I'd say look at the .NET framework. Particularly the ICollection,
IDisposable, and other widely used interfaces.

As far as actual books go, I'm not a good resource. But search for "design
patterns" and "object oriented", and you're sure to find something good.

Chris C.

[Austin Ehlers]

On Mon, 22 Dec 2003 23:00:17 -0000, "Simon Harvey"
<sh856531@micro softs_free_emai l_service.com> wrote:
<snip>

I havent really ever found a book or online resource that discusses this
sort of stuff at the level I need. I mean there are reference applications
from MS and Sun, but they are all focused on showing off their fancier
features like RMI, web services, distributed programming/remoting and so on.
I just need something that talks about some everyday applications and how
they were built from an architectural point of view.

Thanks guys
Simon

Take a look at Applied Microsoft .NET Framework Programming, by
Jeffrey Richter, if you haven't already. Few books can measure up to
the quality of it.