minimalistic real-world sample

[=?Utf-8?B?cm9kY2hhcg==?=]

hey all,
can someone please explain the advantages of interface-based programming?
And then tell me what this is opposed to?

thanks,
rodchar

[gary]

On 12 Jun, 14:31, rodchar <[e-mail]:

hey all,
can someone please explain the advantages of interface-based programming?
And then tell me what this is opposed to?

thanks,
rodchar

Hi,

Interface based programming is a concept where by the interactions
between components are defined by interfaces or "standards"; a bit
like a part of your code saying "if you want to talk to me then you
have to format the conversation in such and such a way". It's a bit
like the software equivalent of a hardware standard. Bluetooth, for
example, is a well defined standard, any component adhering to the
standard can communicate with any other component adhering to the
standard.

This type of programming is opposed to Object-Orientated Programming
or Aspect-Orientated Programming.

HTH,
Gary
http://www.garyshort.org

[Nicholas Paldino [.NET/C# MVP]]

You would use interfaces when you want to abstract out a contract, as
opposed to using a concrete implementation of something.

A good example is the Stream class. Now, this isn't an interface, but
rather, an abstract class. For the most part, these things are the same in
concept, that they define a contract which must be implemented (in the case
of an abstract class, you have to derive from the class, burning your base
class).

With a Stream class, you have the concept of a stream, of reading bytes
in a forward manner, moving a pointer in the stream further along as you
read (this is in the case of reading, not in writing, but a similar concept
applies).

Now, with the Stream class being abstract, you could have any underlying
implementation, and there are, from compression streams, to file streams,
network streams, and the like. All of them do different things, but they
adhere to the model laid out by the abstract class.

The same thing applies for interfaces. IDisposable is a good example,
in that most classes have specific ways of disposing of resources, but they
all adhere to the model of how to dispose of those resources (through the
IDisposable interface).
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"rodchar" <ro*****@discussions.microsoft.comwrote in message
news:27**********************************@microsof t.com...

hey all,
can someone please explain the advantages of interface-based programming?
And then tell me what this is opposed to?

thanks,
rodchar

[=?Utf-8?B?cm9kY2hhcg==?=]

Thank you all for the information, this helps.

"rodchar" wrote:

hey all,
can someone please explain the advantages of interface-based programming?
And then tell me what this is opposed to?

thanks,
rodchar

[=?Utf-8?B?cm9kY2hhcg==?=]

still there?

hey all,
after a few more attempts I'm still having trouble diluting the concepts of
interfaces ( my apologies for the delay ).

My latest read is the following
http://www.samspublishing.com/articl...25857&seqNum=6

The article uses IEmployee as an example and after reading I still don't see
the reason or benefit. Could someone expand on the article just a little
more, please forgive my inexperience with this concept.

"rodchar" wrote:

hey all,
can someone please explain the advantages of interface-based programming?
And then tell me what this is opposed to?

thanks,
rodchar

[Tom Leylan]

I'll take this one :-)

Excluding spaghetti code there is procedural programming and OOP
programming. Procedural programming is a matter of calling "functionality"
passing along data needed by a function and typically getting back a
response from that function. The term OOP is often interpreted as
programming "to the class" i.e. if you need an Employee you instantiate an
employee object and then call methods Load, Save, etc. of that class. That
works better than procedural programming in a number of ways (perhaps)
primarily due to encapsulation which combines the data and the actions on
that data into one package.

It turns out however that it isn't the class or the object that is important
but rather what that object can do, i.e. the messages an object can respond
to. And that leads us to "program to the interface not to the class". Say
you need a collection of things that can sort. One thing you can do is add
a Sort method to a collection of Employees and then you can instantiate an
object of type Employees and tell it to Sort. The trouble is if you need to
pass this object to some other object that needed to display something as it
sorted (and I'm making up the example) it would have to take a parameter of
EmployeeCollection which is a pretty unique class. If instead this other
object was designed to accept classes that implement ISortable it could
accept a collection of Employees but also any collection which is capable of
responding to ISortable messages. ISortable.Key for instance might return a
sort key. That your employees collection implemented the ISortable
interface would be all that is needed to know for a fact that ISortable Key
would return the proper sort key. There is no need to create a special
class to recognize Employees.

Imagine now you want to create a whole bunch of classes that can "draw". If
you create an IDrawable interface you can pass "any" object to a rendering
object and that object could check if the object passed implements
IDrawable. If it does then it can safely call the .Draw() method, if it
doesn't it will not try to draw it. An Employee object (for instance)
wouldn't likely implement IDrawable so while it is silly to send it to the
renderer nothing bad happens if you do.

Did that help?

Tom
"rodchar" <ro*****@discussions.microsoft.comwrote...

still there?

hey all,
after a few more attempts I'm still having trouble diluting the concepts
of
interfaces ( my apologies for the delay ).

My latest read is the following
http://www.samspublishing.com/articl...25857&seqNum=6

The article uses IEmployee as an example and after reading I still don't
see
the reason or benefit. Could someone expand on the article just a little
more, please forgive my inexperience with this concept.

"rodchar" wrote:

>hey all,
can someone please explain the advantages of interface-based programming?
And then tell me what this is opposed to?

thanks,
rodchar

[=?Utf-8?B?cm9kY2hhcg==?=]

Thanks for your thoroughness, may i please ask these follow-up questions...

object of type Employees and tell it to Sort. The trouble is if you need to
pass this object to some other object that needed to display something as it
sorted (and I'm making up the example) it would have to take a parameter of

I'm not sure I understand what the trouble is yet... when you said "to
display something as it sorted..", is this a multi-thread issue?

EmployeeCollection which is a pretty unique class. If instead this other
object was designed to accept classes that implement ISortable it could
accept a collection of Employees but also any collection which is capable of
responding to ISortable messages.

"Tom Leylan" wrote:

I'll take this one :-)

Excluding spaghetti code there is procedural programming and OOP
programming. Procedural programming is a matter of calling "functionality"
passing along data needed by a function and typically getting back a
response from that function. The term OOP is often interpreted as
programming "to the class" i.e. if you need an Employee you instantiate an
employee object and then call methods Load, Save, etc. of that class. That
works better than procedural programming in a number of ways (perhaps)
primarily due to encapsulation which combines the data and the actions on
that data into one package.

It turns out however that it isn't the class or the object that is important
but rather what that object can do, i.e. the messages an object can respond
to. And that leads us to "program to the interface not to the class". Say
you need a collection of things that can sort. One thing you can do is add
a Sort method to a collection of Employees and then you can instantiate an
object of type Employees and tell it to Sort. The trouble is if you need to
pass this object to some other object that needed to display something as it
sorted (and I'm making up the example) it would have to take a parameter of
EmployeeCollection which is a pretty unique class. If instead this other
object was designed to accept classes that implement ISortable it could
accept a collection of Employees but also any collection which is capable of
responding to ISortable messages. ISortable.Key for instance might return a
sort key. That your employees collection implemented the ISortable
interface would be all that is needed to know for a fact that ISortable Key
would return the proper sort key. There is no need to create a special
class to recognize Employees.

Imagine now you want to create a whole bunch of classes that can "draw". If
you create an IDrawable interface you can pass "any" object to a rendering
object and that object could check if the object passed implements
IDrawable. If it does then it can safely call the .Draw() method, if it
doesn't it will not try to draw it. An Employee object (for instance)
wouldn't likely implement IDrawable so while it is silly to send it to the
renderer nothing bad happens if you do.

Did that help?

Tom
"rodchar" <ro*****@discussions.microsoft.comwrote...

still there?

hey all,
after a few more attempts I'm still having trouble diluting the concepts
of
interfaces ( my apologies for the delay ).

My latest read is the following
http://www.samspublishing.com/articl...25857&seqNum=6

The article uses IEmployee as an example and after reading I still don't
see
the reason or benefit. Could someone expand on the article just a little
more, please forgive my inexperience with this concept.

"rodchar" wrote:

hey all,
can someone please explain the advantages of interface-based programming?
And then tell me what this is opposed to?

thanks,
rodchar