Interface question

  • Thread starter Thread starter Meya-awe
  • Start date Start date
M

Meya-awe

I am puzzled, what is the purpose of an interface? How does it work,
what i mean is how does the compiler treats this? Why when we talk
about separating user interface from business logic, an interface is
declared, what is it's purpose?
thanks,
BRAMOIN
 
In the simplest terms, an interface defines _what_ something in your
system does without defining _how_ it does it.

For example, if you define an interface in your business layer that
defines the operations of a data layer, what your business layer is
saying is, "I will work with any data layer that provides the following
properties, events, and methods." The business layer doesn't care which
data layer it's talking to: it may be an object that stores information
in a database, a different object that stores information in a
collection of XML files, or something else.

You could even define a "pluggable" data layer, in which you could
build your application with multiple data layers and then switch
between them at run time depending upon your needs.

Since all the business layer cares about is that the object it's
calling implements the interface defined by the business layer, it
doesn't matter which object it is, exactly.

Interfaces come in very handy in large organizations: the developer who
builds the business layer can also build the data layer interface and
hand it to the data layer developer, saying, "Build this!" If the
interface is clear enough, the data layer developer can "build to
contract". Meanwhile, the business layer developer can use a quickie,
"fake" data layer to develop and start testing his business layer
before the data layer is even finished. So long as the "fake" data
layer and the real data layer implement the same interface, all is
well. (Of course, it's not quite that simple, but you get the idea.)
 
Bruce,
Can you give me an example of this? Looking for a simple,simple class in
the bussiness layer and an another one in the data layer with code that
uses these. I believe you, but i am having problem invisioning this.
thanks,
BRAMOIN
 
Can you give me an example of this? Looking for a simple,simple class in
the bussiness layer and an another one in the data layer with code that
uses these. I believe you, but i am having problem invisioning this.
thanks,
Click to expand...

I have a framework that allows me to store objects in a database, but I
don't want the people who develop the business objects to have to know
anything about SQL or any other database stuff.

So I declare an interface or "contract" that I can talk to in a totally
database independent way.

Here is a simplified example :

public interface IObjectSpace
{
bool StoreObject(object obj);
bool DeleteObject(object obj);
object RetrieveObject(int id);
IList RetrieveCollection(Type objectType);
...
}

Now I can call this code like this :

{
IObjectSpace os = new SQLServerObjectSpace();
IList list = os.RetrieveCollection(typeof(Customer));
int custId = ((Customer) list[0]).Id;
Customer cust = (Customer) os.RetrieveObject(custId);
cust.Address = "123 This Street";
os.StoreObject(cust);
}

This code assumes that we are creating an instance of a class that knows how
to manage converting objects to/from SQLServer tables.

However, by just changing the first line of that code example, and assuming
I have another class that represents a mechanism for converting objects
t/from XML, I can work with a test "database" which is a simple XML storage
mechanism.

{
IObjectSpace os = new TestXMLObjectSpace();
IList list = os.RetrieveCollection(typeof(Customer));
int custId = ((Customer) list[0]).Id;
Customer cust = (Customer) os.RetrieveObject(custId);
cust.Address = "123 This Street";
os.StoreObject(cust);
}

Notice that it is only the first line of the example that has changed; all
the rest of the code remains identical. This is because I have defined a
contract that I expect any class that implements IObjectSpace to fulfil.

Now I can design my business classes and test them against my own XML test
object space, whilst someone else goes off and writes the SQLServer version.
When they have finished all I have to change is that one line of code that
creates the actual object space instance.

Does that help ?

Joanna
 
Joanna,
Yes, that helped a lot to understand it. Since the methods in an
interface have to be defined by the class(es) implementing the
interface, there would be two implementations one for SQL and one for
XML. So, an interface forces the higher level logic using an object,
implementing the interface to adhere to a contract defined by the
interface.
Ever since i posted this, i have been reading about this subject. And
now the question is, when would i use "Interface Polymorphism" or
"Inheritance polymorphism" or "Polymorphism through abstract classes"?
thanks,
BRAMOIN
 
Ever since i posted this, i have been reading about this subject. And
now the question is, when would i use "Interface Polymorphism" or
"Inheritance polymorphism" or "Polymorphism through abstract classes"?
Click to expand...

If I remember correctly, interface polymorphism relies on the implementing
class to execute code that may vary depending on the class used to implement
the interface, this kind of polymorphism can cross class hierarchy
boundaries; inheritance polymorphism is simply using virtual/overridden
methods within a single class hierarchy; polymorhism through abstract
classes also can only occur within a single hierarchy, but a pure abstract
class is the equivalent of an interface.

Does that help or hinder ? :-)

Joanna

--
Joanna Carter (TeamB)

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
 
Notice that it is only the first line of the example that has changed; all
the rest of the code remains identical.
Click to expand...
I am newbie too. You don`t convince me of use interfaces yet .
I think, we obtain the same results using simply Polimorphism and
we can do without interfaces.
 
Slawek Weclewski said:
I am newbie too. You don`t convince me of use interfaces yet .
I think, we obtain the same results using simply Polimorphism and
we can do without interfaces.
Click to expand...

No, you can't. Without interfaces or multiple inheritance, how would
write the equivalent of a class which implements (say) IDisposable and
IComparable?

Interfaces are incredibly useful at completely separating interface
from implementation. Why should two classes have to have anything in
common in terms of an inheritance hierarchy just to expose the same
interface?
 
The classic example of interfaces comes from Java, which has, I
believe, IPrintable, or something like that.

This clearly indicates the division between interfaces and the class
hierarchy: two objects that have nothing to do with each other might
both want to be Printable. So, they both implement IPrintable, and you
can write other code that does things with "Printable" objects with no
regard as to where in the class hierarchy they might fall.

For example, both a Document and an Image might be Printable. Do you
really want to _have_ to inherit both of them from a Printable parent
class?

You can argue that a language with multiple inheritance has no need for
interfaces, but single-inheritance languages like Java and C#
definitely need them, otherwise you end up with a tortured class
hierarchy just to get completely dissimilar things to "look the same"
for certain purposes.
 
The choice between interfaces (which automatically imply
polymorphism... if you aren't using them in only one class then they
aren't terribly useful), inheritance polymorphism, and abstract classes
really has to do with the design of your class hierarchy.

This is the beauty of interfaces: you don't inherit from something
because "I need that functionality in my derived class". Well,
sometimes you do, just to be lazy (guilty). What you're supposed to do,
however, is inherit from a parent class because, in real-world terms,
what you're making "is a" specialized case of the parent class.

So, a Dog class would inherit from the Mammal class, because a Dog "is
a" Mammal. Or, you might have two types of PurchaseOrder: an
InternalPurchaseOrder and an ExternalPurchaseOrder. You arrange these
in an inheritance hierarchy because they are logically related.

So, in the case of the purchase orders, you can write code that deals
with PurchaseOrder in general, without worrying about whether it is an
InternalPurchaseOrder or an ExternalPurchaseOrder. Some of your code
will be that way: it won't matter which one you're dealing with. That's
inheritance polymorphism.

However, when you design these three classes, you have to ask yourself
if a PurchaseOrder is a "real" thing in your business: can you make
one, without it being internal or external? In some businesses, there
may be a third type of purchase order that is sort of a basic purchase
order, but in most businesses, the answer will be "no". So, you make
PurchaseOrder abstract: it's an artifact of your class hierarchy... it
doesn't represent a real business object. You need it, because an
InternalPurchaseOrder "is _not_ a" ExternalPurchaseOrder, and an
ExternalPurchaseOrder "is _not_ a" InternalPurchaseOrder, but you still
want them to be related, so you make this fake ("abstract") class that
is the "parent" of them both, so you can, in some of your code, treat
them as equivalent. That's polymorphism through abstract classes.

So, the difference between those two is whether the parent class is
something that logically exists in its own right, or is just a
side-effect of the way you want to arrange your class hierarchy.

Interfaces come into play when the classes you want to treat as
equivalent for some purposes have _nothing_ in common as far as the
class hierarchy is concerned. The only thing they have in common is
that they all offer the same functionality. So, rather than building a
tortured class hierarchy to try to make all of these classes have a
common parent where you can put the functionality, you declare an
interface, and make all of the classes implement it. Then you can write
code that treats the classes as equivalent.

For example, I just built a special kind of ListView, and a special
kind of Panel in WinForms. They are both backed by something called a
ListViewModel, which is the brains behind managing item selection,
sorting, etc. However, I can't have both of these classes inherit from
a common ancestor: they have to inherit from ListView and Panel,
respectively.

That wasn't a problem up until this week, when I decided that I wanted
to make another control that could interact with any control that was
backed by a ListViewModel. Now, suddenly, I have a class that wants to
treat these other two classes (and any others I may build) as
equivalent, but they have no common ancestor (that I can modify). So, I
created an interface called IHasListViewModel, with one property:
Model. Now I can write my new control to search for and interact with
any control that implements the IHasListViewModel interface, and it
will know that it can get the model and talk to it, because any control
implementing that interface has to have a ListViewModel behind it.

Notice that, in a single-inheritance language like C#, that was the
_only_ way to solve the problem, other than the totally gross solution
of having my new control know, explicitly, about every class I make
that has ListViewModel, like this:

if (aControl is ListViewForSelfKeyedCollection)
{
ListViewForSelfKeyedCollection lv =
(ListViewForSelfKeyedCollection)aControl;
}
if (aControl is ProfileImageGallery)
{
ProfileImageGallery pig = (ProfileImageGallery)aControl;
}
if (aControl is LabelForSelfKeyedCollection)
{
... etc.

Ewwww... yuck. Now I have to modify my little helper control every time
I add a new one of these. Gross. With the interface, I just say:

if (aControl is IHasListViewModel)
{
IHasListViewModel lvm = (IHasListViewModel)aControl;
ListViewModel model = lvm.Model;
... off to the races ...
}

Much better, no?
 
Slawek Weclewski said:
I am newbie too. You don`t convince me of use interfaces yet .
I think, we obtain the same results using simply Polimorphism and
we can do without interfaces.
Click to expand...

Another function of an interface is as a "contract". Interfaces fix the
means by which software components interact. As long as an interface is not
changed modifications of one software module will not require changing the
software that interacts with it.
 
Bruce said:
You can argue that a language with multiple inheritance has no need for
interfaces, but single-inheritance languages like Java and C#
definitely need them, otherwise you end up with a tortured class
hierarchy just to get completely dissimilar things to "look the same"
for certain purposes.
Click to expand...

I wonder whether so many people would have shot themselves in the foot
using MI badly in C++ had the notion of pure abstract classes as
interfaces been formalised in the language rather than just a design
pattern.

In http://www.artima.com/intv/modern.html Stroustrup seems to be saying
that he recognised the value of the pattern a long time ago.
 
Thanks for taking the time to explain this in a little bit more detail.

With respect to the polymorphism, inheretence, abstract classes, and
interfaces, i now have a better understanding of these.
BRAMOIN
 
Back
Top