[RESOLVED] [2005] Interfaces & OO Desgin

I need some clarification on when to use an interface and it's advantages. I believe the use of an interface is polymorphism, but what are the advantages of using an interface?

For example suppose you have an application that needs to connect to an Oracle and MSSQL Server database, so you create an interface that handles the basic interactions with a database.

VB Code:

Public Interface IDatabase
    Public Sub Connect()
    Public Sub Disconnect()
End Interface

Since both the MSSQL and Oracle databases may handle the connection, update, and delete processes differenlty you have to create two different classes one for each database system. Each class needs to implement all the methods in the interface.

This is where I am getting confused - what is the role of an interface? Is it just a model that they should follow? Or am I way off?

VB Code:

Public Class MSSQL Implements IDatabase
    Public Sub Connect()
      ' Some code here
    End Sub
    Public Sub Disconnect()
      ' Some code here
    End Sub
End Class
 
Public Class Oracle Implements IDatabase
    Public Sub Connect()
      ' Some code here
    End Sub
    Public Sub Disconnect()
      ' Some code here
    End Sub
End Class

Well you could actually use the OLEdb objects and create one class for both types Oracle and SQL (besides the BO's, business objects, are simply compiled dll's that may sit on an application server). However, this is not the ideal scenerio considering how awful and slow ODBC is, in fact, that is the primary reason why we have the SQLClient class, for performance reasons, not to mention how much simplier it is.

Ok as for your interface, first an interface is not really needed for what you are accomplishing. In your scenerio you need to come up with a tier for database transactions, which is simply a business object class. An interface is used after the fact that inheritance has been used on an original class. Remember you can only use inheritance once. Take an example of a class of Employees, one may use inheritance to specify a Programmer "is a" employee, therefore Programmer inherits from the employees class. Now all of a sudden your organization wants to handle "Lead Programmers" or the main developers in a specific way (maybe their pay increase and vacation time is a bit more than a programmer or a general employee). Well in this case you cannot inherit from the programmer class since it is a programmer object. What you can do is use interfaces to create an interface for these class of people.

Polymorphism is just a concept that states at any level of an object chain (parent-child) the compiler knows what methods to call to what objects irregardless how they are stored. For example if you have that same Employees class. You then inherit from this class of Employees to a class of Programmers. Both classes have a PayRaise method (in the parent class this method is OverRideable). If we did something to this effect:

Dim objE as Employee
Dim objP as Programmer

objE = new Employee("John")
objP = new Programmer("John")
objE = objP
objE.PayRaise(.10)

Polymorphism acts to call the PayRaise function of the Programmer class even though the object is of type Employee. Remember Programmer inherits from Employee and down casting is allowed. If we were to go the other way around the compiler would complain since all Programmers are Employees but not all Employees are programmers.

There is a difference from inheriting and using an interface. An interface is a binding contact stating that the implementing object WILL implement ALL of the defined interface elements. This means that if a class implements an interface, you HAVE to supply all of the code for all properties, methods and functions in the interface. Even if you don't use them, you still have to create the shells for them.

However, when you inherit, you only need to overwrite the portions that you want. Anything that is left unoverwritten, will default to the base class's version.

-tg

I think he meant binding contract, please keep in mind the interface just needs the "shell" or signature of the method, that is what makes it different then inheritance.
In your case I would not think you really needed an interface unless you have some sort of large BO modeling both databases.

You could get away with 2 BO's one for the oracle side and one for the SQL side...or better yet tell them to drop one of the RDBMS's ;).

another good point worth mentioning is that an object can only inherit from one parent object, but can implement multiple interfaces, even if it also inherits from a parent class.

Hmm did you read my post:

"Remember you can only use inheritance once. Take an example of a class of Employees, one may use inheritance to specify a Programmer "is a" employee, therefore Programmer inherits from the employees class. Now all of a sudden your organization wants to handle "Lead Programmers" or the main developers in a specific way (maybe their pay increase and vacation time is a bit more than a programmer or a general employee). "

;)

I have always focused on what TG was talking about. Implementing an interface is telling the compiler that there WILL exist a function with a certain prototype that will perform an action. In the case of IComparable, implementing the interface tells the compiler that there exists a way to compare an object of this type with any other object (you may not implement all the possible objects, but that's irrelevant). Therefore, when you try to sort an array, the compiler can generate code to call a function that is known to exist, and will behave in a predictable fashion. (Should you EVER throw an exception in the Compare function?).

I have never used an interface for anything other than a contract with the compiler. When used in that fashion, an interface works like an effective callback function, because it is telling the compiler "here is the function to call for a comparison". Of course, the function itself is not being supplied, just the promise that the function exists with a known prototype.

That doesn't seem to apply to your situation so well.

I'm not sure whether this will add value here or not but I like to think of things this way: a base class is something that a class IS, while an interface is something that a class DOES or CAN DO, i.e. an interface is role that a class can play. My favourite analogy is transportation. In the real world we have the Car class. The Car class inherits the Vehicle class because a car IS a vehicle. A Car is also a method of transportation, so the Car class implements the ITransport interface. The Bicycle, Horse, Aeroplane, Train and Skateboard classes also implement the ITransport interface because they can do what a mode of transportation does, but they are very varied types. That's the whole purpose of an interface: to provide a way that varied types can all be treated in the same way for a specific purpose. If I said that I needed to get from A to B, you could provide me with a car, a horse, a skateboard or any other object that was a mode of trasport and it would get me from A to B because all those objects can be used in that role.

I think I understand interfaces better now thanks alot all that have answered.

I was not planning on doing anything with interfaces I was just asking because I am meeting with a company that is really big on OO and they like to ask an the interface question alot.

Great, glad it made sense, here is a sample of interfacing http://www.vbforums.com/showthread.php?t=429002