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@microsofts_free_email_service.com> wrote in message
news:uN**************@tk2msftngp13.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****@acadxpin.com> wrote in message
news:ef**************@TK2MSFTNGP10.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@microsofts_free_email_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.

[Mick Doherty]

After reading all these replies I still don't see the advantage of writing
an Interface.
As far as I can tell, an Interface defines a set of properties, procedures
and events but does not do anything, that is left for your Class to do. When
you write your Class and implement the Interface, the properties, methods
and events are outlined for you, but you must still write the code for them.

So how does Example2 below benefit over Example1?
(As you can see I am a VB.Net programmer).

**** Example1 ***************

Class MyClass
Inherits Object

Public Event Event1()

Public Sub Method1(ByVal X As Integer)
'Some Code
End Sub

Private _Property1 As Integer

Public Property Property1() As Integer
Get
Return _Property1
End Get
Set (ByVal Value as Integer)
_Property1 = Value
End Set
End Property

End Class

**** End Example1 ************

**** Example2 ***************

Class MyClass
Inherits Object
Implements IFoo

Public Event Event1() Implements IFoo.Event1

Public Sub Method1(ByVal X As Integer) Implements IFoo.Method1
'Some Code
End Sub

Private _Property1 As Integer

Public Property Property1() As Integer Implements IFoo.Property1
Get
Return _Property1
End Get
Set (ByVal Value as Integer)
_Property1 = Value
End Set
End Property

End Class

InterFace IFoo
Property Prop1() As Integer
Sub Method1(ByVal X As Integer)
Event Event1()
End Interface

**** End Example2 ************
"Simon Harvey" <sh856531@microsofts_free_email_service.com> wrote in message
news:Ol**************@TK2MSFTNGP11.phx.gbl...

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

[Jimmy [Used-Disks]]

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

When you want to *enforce* a class heararchy.

Think of a Furnature abstract class, from which you derive other classes
such as Chair and Table. Now imagine an interface, IHasLegs. Now imagine one
final class: Person.

Now lets say you have a measuring service that measures the length of legs.
Does that service care if the leg is a Person leg or a Chair leg? No -
because both are measurable. However, lets say you have another service
which deletes Furnature from inventory - you don't want a Person getting in
there and getting tossed! <g>

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.

Check out Design Patterns by the Gang-of-Four (Erich Gamma, Richard Helm,
Ralph Johnson, and John Vlissides).

Also, the .NET framework its self makes very good use of interfaces. You may
just want to read the help on interfaces such as ICollection, IAdapter, and
others.

--
-Jimmy

[Frank Oquendo]

Mick Doherty wrote:

So how does Example2 below benefit over Example1?

So long as an object implements an interface, it may be passed to and
accepted by methods expecting a particular kind of object (just like
objects deriving from a common ancestor).

The same is not true of your first example. Even if another class has
the same methods, properties and events, it will still be a distinct and
separate type. This means lots of runtime type checking and casting
where as using an interface grants us type safety at compile time.

--
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]]

> As far as I can tell, an Interface defines a set of properties, procedures

and events but does not do anything, that is left for your Class to do.
That's exactly it.
When
you write your Class and implement the Interface, the properties, methods
and events are outlined for you, but you must still write the code for them.

Yes.
So how does Example2 below benefit over Example1?

It doesn't.

Think of interfaces as *pure* abstraction. It defines essential
characteristics. Think of nature - many animals can jump, climb, crawl,
swim, fly... but they don't all "inherit" from the same base animal. Thus
jumping, climbing, crawling, swimming, and flying are all abstract
behaviors. Take swimming as an example - a shark swims one way, but a human
swims a completly different way, but they both still swim. If sharks and
humans inherited from the same animal, this would be very difficult to
define.

--
-Jimmy

[Mick Doherty]

Sorry, but that sounds like an explanation for Inheritance.

If I Inherit from a base class then my new class will have the same
properties, methods and events as those in the base class, plus any others
that I add. I can pass the inherited class to a method as the base class
type and that method will be able to access the standard properties etc..
although they may have been Overridden and so TypeCasting is necessary.

If I Implement an Interface then my class will have have all the same
properties, methods and events, but I cannot assume that the class is a
specific baseclass type and so cannot pass it as a type other than that from
which it Inherits, unless I TypeCast.

From what I do understand, if I Implement an Interface then the properties
and functions will be guaranteed to have the same return type, and so this
is where the Type Safety, that you mentioned, would come in. This then must
be the benefit.
"Frank Oquendo" <fr****@acadxpin.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

Mick Doherty wrote:

So how does Example2 below benefit over Example1?

So long as an object implements an interface, it may be passed to and
accepted by methods expecting a particular kind of object (just like
objects deriving from a common ancestor).

The same is not true of your first example. Even if another class has
the same methods, properties and events, it will still be a distinct and
separate type. This means lots of runtime type checking and casting
where as using an interface grants us type safety at compile time.

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

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

[Frank Oquendo]

Mick Doherty wrote:

Sorry, but that sounds like an explanation for Inheritance.
However, most cases for inheritance simply are not.
If I Inherit from a base class then my new class will have the same
properties, methods and events as those in the base class, plus any
others that I add.
So what happens when you come across a need for those same methods in a
totally unrelated class?
If I Implement an Interface then my class will have have all the same
properties, methods and events, but I cannot assume that the class is
a specific baseclass type and so cannot pass it as a type other than
that from which it Inherits, unless I TypeCast.
That's the whole point of an interface: there is no need to assume
anything about an object's type. If it implements the desired interface,
those methods are available to you; period:

void DoSomething(IMyInterface someObject)
{
someObject.Foo;
}

With the code above, the compiler will prevent you from passing in any
object which does not implement IMyInterface, regardless of that
object's base type. Any attempt to do so at runtime will throw an
exception. And all with no extra effort on your part (i.e. type checking
in code). Not to mention that I completely avoid the need to develop a
class hierarchy.
From what I do understand, if I Implement an Interface then the
properties and functions will be guaranteed to have the same return
type, and so this is where the Type Safety, that you mentioned, would
come in. This then must be the benefit.

See above.

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

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

[Mick Doherty]

Now that makes sense. I didn't even think about passing an Interface as an
object.
I think it's time I started using them now that I understand.

Thank you for your patience,
Mick Doherty

"Frank Oquendo" <fr****@acadxpin.com> wrote in message
news:e%****************@TK2MSFTNGP09.phx.gbl...

Mick Doherty wrote:

Sorry, but that sounds like an explanation for Inheritance.

However, most cases for inheritance simply are not.

If I Inherit from a base class then my new class will have the same
properties, methods and events as those in the base class, plus any
others that I add.

So what happens when you come across a need for those same methods in a
totally unrelated class?

If I Implement an Interface then my class will have have all the same
properties, methods and events, but I cannot assume that the class is
a specific baseclass type and so cannot pass it as a type other than
that from which it Inherits, unless I TypeCast.

That's the whole point of an interface: there is no need to assume
anything about an object's type. If it implements the desired interface,
those methods are available to you; period:

void DoSomething(IMyInterface someObject)
{
someObject.Foo;
}

With the code above, the compiler will prevent you from passing in any
object which does not implement IMyInterface, regardless of that
object's base type. Any attempt to do so at runtime will throw an
exception. And all with no extra effort on your part (i.e. type checking
in code). Not to mention that I completely avoid the need to develop a
class hierarchy.

From what I do understand, if I Implement an Interface then the
properties and functions will be guaranteed to have the same return
type, and so this is where the Type Safety, that you mentioned, would
come in. This then must be the benefit.

See above.

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

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

[Heinz Kiosk]

An example of this kind of application is where you want to have an app that
can run in two modes, single-tier or client-server. The interface between
the two levels can be defined as.... an interface. So then the
implementation of the interface classes can be on a completely different
hierarchy.

Tom

Now that makes sense. I didn't even think about passing an Interface as an
object.
I think it's time I started using them now that I understand.

Thank you for your patience,
Mick Doherty

"Frank Oquendo" <fr****@acadxpin.com> wrote in message
news:e%****************@TK2MSFTNGP09.phx.gbl...

Mick Doherty wrote:

Sorry, but that sounds like an explanation for Inheritance.

However, most cases for inheritance simply are not.

If I Inherit from a base class then my new class will have the same
properties, methods and events as those in the base class, plus any
others that I add.

So what happens when you come across a need for those same methods in a
totally unrelated class?

If I Implement an Interface then my class will have have all the same
properties, methods and events, but I cannot assume that the class is
a specific baseclass type and so cannot pass it as a type other than
that from which it Inherits, unless I TypeCast.

That's the whole point of an interface: there is no need to assume
anything about an object's type. If it implements the desired interface,
those methods are available to you; period:

void DoSomething(IMyInterface someObject)
{
someObject.Foo;
}

With the code above, the compiler will prevent you from passing in any
object which does not implement IMyInterface, regardless of that
object's base type. Any attempt to do so at runtime will throw an
exception. And all with no extra effort on your part (i.e. type checking
in code). Not to mention that I completely avoid the need to develop a
class hierarchy.

From what I do understand, if I Implement an Interface then the
properties and functions will be guaranteed to have the same return
type, and so this is where the Type Safety, that you mentioned, would
come in. This then must be the benefit.

See above.

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

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

[Cindy M -WordMVP-]

Hi Simon,

I havent really ever found a book or online resource that discusses this
sort of stuff at the level I need.

I'm working through this particular chapter in Dan Appleman's book on
migrating from VB6 to .NET, and he goes into a lot of discussion about
what inheritance is, what interfaces are, and when you'd use the one and
not the other; with pseudo-examples (i.e. aren't actually part of a
real-world application, but certainly could be).

I don't know if this discussion, alone, would be worth buying the book.
But maybe you can turn it up in a library or find a quiet corner for an
hour or two in a book store :-)

-- Cindy

[Simon Harvey]

Thanks everyone,

Turned into quite a good discussion there!

Simon

[Carlos Kirkconnell]

You where asking about rules that help you choose when to use interfaces
Here are some:

1- If you're going to work with lots of objects that have the same behavior
an will share some implementation use Inheritance. Example: drawing
applications, all the objects in a canvas need behavior for moving,
resizing, etc...

2- If working with lots of objects, and all objects may be very diferent in
implementation and may be internally composed of many other objects but all
define a custom behavior use an interface. Example: Plugins for an
application.

3- If some of the classes that you'll use are already inherited from other
classes; then use interfaces, multiple inheritance is not possible in C# at
least. Example: Creating a group of custom controls (some controls derived
from UserControl, other's from a TextBox maybe).

4- Don't Create an interface if there is no reason to do it. Objects that
will be useful to implement an interface are the ones that will be stored on
Collections ( which will be later enumerated to work with the elements) or
the ones that will be produced or used by another class that only need to
know the behavior of different types of objects.
"Simon Harvey" <sh856531@microsofts_free_email_service.com> wrote in message
news:uN**************@tk2msftngp13.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