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

[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@micro softs_free_emai l_service.com> wrote in message
news:Ol******** ******@TK2MSFTN GP11.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****@acadxpi n.com> wrote in message
news:%2******** ********@TK2MSF TNGP09.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(IMy Interface 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****@acadxpi n.com> wrote in message
news:e%******** ********@TK2MSF TNGP09.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(IMy Interface 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****@acadxpi n.com> wrote in message
news:e%******** ********@TK2MSF TNGP09.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(IMy Interface 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