Basic Concept Question Why Interface?

[jm]

Consider:
http://msdn.microsoft.com/library/de...ycomponent.asp
// Code for the IAccount interface module.
public interface IAccount
{
void PostInterest();
void DeductFees(IFeeSchedule feeSchedule);
}
class BusinessAccount : IAccount
{
void IAccount.PostInterest()
{
// Code to post interest using the most favorable rate.
}

void IAccount.DeductFees(IFeeSchedule feeSchedule)
{
// Code to change a preferred rate for various services.
}
}
Note An interface is a contract. You must implement all of the
properties and methods in the interface.

I do not understand why Interface was necessary. Why not just have
the class BusinessAccount and two functions in it PostInterest() and
DeductFees()?

Thank you.

[John Baro]

There was a thread last week that dealt with this exact question. You can
google for it.
Basically, an interface tells a class that another class implements all the
methods contained in an interface, therefore, you do not have to know what
type of object it is, only that it implements the interface.

In the below example, if you did not implement the interface, if you had
another class with methods PostInterest and DeductFees, you would have to
check for type before converting them to their type and then calling their
methods.
With the Interface, you only need to cast it to the interface (if it is not
passed as the interface type) before calling the methods.

HTH
JB

"jm" <jo*************@yahoo.com> wrote in message
news:c6**************************@posting.google.c om...

Consider:
http://msdn.microsoft.com/library/de...ycomponent.asp

// Code for the IAccount interface module.
public interface IAccount
{
void PostInterest();
void DeductFees(IFeeSchedule feeSchedule);
}
class BusinessAccount : IAccount
{
void IAccount.PostInterest()
{
// Code to post interest using the most favorable rate.
}

void IAccount.DeductFees(IFeeSchedule feeSchedule)
{
// Code to change a preferred rate for various services.
}
}
Note An interface is a contract. You must implement all of the
properties and methods in the interface.

I do not understand why Interface was necessary. Why not just have
the class BusinessAccount and two functions in it PostInterest() and
DeductFees()?

Thank you.

[Jeff Louie]

JM... If BusinessAccount was the only class that supported the functions
PostInterest and DeductFees using an interface would be overkill. If you
have
a set of methods that will be implemented across many classes, a so
called
mixin class, then an interface is helpful. An example is loading a
plugin at
runtime. As long as the dynamically loaded class implements the
interface
you can load the class at runtime and call methods in the interface.

Regards,
Jeff

I do not understand why Interface was necessary. Why not just have

the class BusinessAccount and two functions in it PostInterest() and
DeductFees()?<
*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!

[Nick Malik]

The answer can be found by digging deeper into Design Patterns.

Consider: http://home.earthlink.net/~huston2/dp/patterns.html
(just one of thousands of links about design patterns, although Vince Huston
is a bit more "convinced" than most folks. I like the site for its
tutorials).

If you drill into each of the design patterns under the Gang-of-Four
section, you will begin to notice two things:

1) These are EXCELLENT solutions to some really common problems, (ranging
from simple to really difficult problems). If you really take the time to
learn these patterns, your programming will improve dramatically, and

2) Nearly every one of these design patterns REQUIRES the use of interface
definitions in order to create the concept of a contract where any object
that implements the contract can be substituted for any other object that
also implements the contract. (this ability to substitute forms the
implementation foundation of the Liskov Substitution Principle).

In other words, delve deeper. Keep asking questions. Pick up a copy of
"Design Patterns Explained" by Alan Shalloway and James Trott. Then read
it. Then read it again.

And enjoy this journey... it's a fun ride.
--- Nick

"jm" <jo*************@yahoo.com> wrote in message
news:c6**************************@posting.google.c om...

Consider:
http://msdn.microsoft.com/library/de...ycomponent.asp

// Code for the IAccount interface module.
public interface IAccount
{
void PostInterest();
void DeductFees(IFeeSchedule feeSchedule);
}
class BusinessAccount : IAccount
{
void IAccount.PostInterest()
{
// Code to post interest using the most favorable rate.
}

void IAccount.DeductFees(IFeeSchedule feeSchedule)
{
// Code to change a preferred rate for various services.
}
}
Note An interface is a contract. You must implement all of the
properties and methods in the interface.

I do not understand why Interface was necessary. Why not just have
the class BusinessAccount and two functions in it PostInterest() and
DeductFees()?

Thank you.

[Simon Smith]

On 15 Jun 2004 03:54, "Nick Malik" wrote:

The answer can be found by digging deeper into Design Patterns.

Consider: http://home.earthlink.net/~huston2/dp/patterns.html
(just one of thousands of links about design patterns, although Vince Huston
is a bit more "convinced" than most folks. I like the site for its
tutorials).
Very true. They are a great source.

If you drill into each of the design patterns under the Gang-of-Four
section, you will begin to notice two things:

1) These are EXCELLENT solutions to some really common problems, (ranging
from simple to really difficult problems). If you really take the time to
learn these patterns, your programming will improve dramatically, and
Very true again.
2) Nearly every one of these design patterns REQUIRES the use of interface
definitions in order to create the concept of a contract where any object
that implements the contract can be substituted for any other object that
also implements the contract. (this ability to substitute forms the
implementation foundation of the Liskov Substitution Principle).
Wrong. I can't think of one of the GoF patterns which is presented in
terms of an interface and not inheritance. And the LSP is specifically
talking about Inheritance although it applies to interfaces too. (It's
the Type/SubType phrasing I guess.)

In other words, delve deeper. Keep asking questions. Pick up a copy of
"Design Patterns Explained" by Alan Shalloway and James Trott. Then read
it. Then read it again.

Why not got for the source? Get the GoF book.


Simon Smith
simon dot s at ghytred dot com
http://www.ghytred.com/NewsLook - Usenet for Outlook