Interface vs Abstract vs Class in OOP

[ehx6]

Hi, I am new to OOP , I got confused b/w the following:
Interface vs Abstract vs Class . When Do I use them and does any one know of a good book that provide a thourgh examples of the 3 types (Interface vs Abstract vs Class)

Thanks
Ehx

 

[theThirdElement]

Hi Ehx,

Let me try to explain.

Class is just the term for a collection of objects. It has attributes and methods that describe its properties and behaviours. Objects are instantiated based on the class definition, i.e. the blue print.

Interface in OOP terms is the API that the classes agree to, and the classes would expose certain methods as the interface. Other classes will call the methods in the interface to interact with each other.

Abstract class is a class that has its attributes and method signatures defined, but yet to be fleshed out. That is, an abstract class must be sub-classed to become a concrete class, where the actual implementation is carried out, before it can be used.

Experts please correct me if I am wrong.

You should be able to find definitions easily on google. You can also check out some lecture notes on a course I took; I think they are quite succinct and useful.

http://thylacine.cse.unsw.edu.au:20...ecture.phtml?tid=&cid=791&color=#E6E6FA&mode=

Cheers,

Ed

 

[ehx6]

Thanks cheers for your reply. I understand class, but I am still not sure about Interface and Abstract yet.
Interface:
-------------
Do you mean that API contains(attributes & methods) . So API is a class?(not sure) Or, API is a public attributes & methods in which any other class can call it.

Abstract:
----------
When you say attributes & method signatures defined, do you mean that they are generic and are inherited?

I am still struggling in understanding those concepts. mmm, I am wondering what is the best way to know this stuff in and out ?

thanks for your help

Ehx

 

[ehx6]

Hello again,
here a definition of interface from C# Programmer's Reference

interface:
An interface defines a contract. A class or struct that implements an interface must adhere to its contract. The declaration takes the following form::

They are talking about contract, What do they mean by a contract?
The word implement interface? what does that mean?

Sorry if those are primitive silly question. Any advice?
thanks
Ehx

 

[stevexff]

ehx

You already know about classes, and inheritance. Suppose you had two completely separate classes, in different inheritance hierarchies. Let's call them Customer and CreditCard. Both of these have addresses. Some customers may have multiple credit cards, some of which may have different billing addresses - guys don't want the bills for their mistress's credit cards sent to their home address, for example.

C#, VB.NET, and Java only allow single inheritance, and Customer and CreditCard are quite different objects, so we don't want to have them both inheriting from the same superclass just so that we can capitalise on the shared behaviour in address handling.

By using an interface, we can specify a contract that describes the name and signature of one or more methods, with the expected results. In our case, we can create an interface IAddress with a method getAddress() that always returns an address.

We then make both classes implement IAddress. They both have a method getAddress() that returns an address object. But they might implement this in completely different ways. The underlying data may even be on different machines around the globe. The Customer object might simply return the address, but the CreditCard may check to see if it has a billing address. If so, it returns it, but if not, it could ask the associated Customer object for its address, and return that instead.

What does this buy us? Well, any object that implements IAddress can be treated as an IAddress object. So we could put a number of Customer and CreditCard objects into a collection, and iterate over them as if they were all IAddress objects, as long as we only want to ask them for their addresses. This allows us to treat objects from different parts of the hierarchy as if they were the same, without having to have a really deep and complex hierarchy which is difficult to extend and maintain. We can loosen up our hierarchy, as the interface allows use to specify what needs to be done, without having to specify which objects will actually be doing it at run time. As long as they keep to the contract, everything is fine.

If you subsequently need to branch out into InsurancePolicy, you can add a new class for it, implement IAddress, and any existing code that uses IAddress objects can work with your insurance policies too.

Because a class can implement a number of interfaces, this gives you the possibility to simulate multiple inheritance a la C++ without all the problems that go with it.

Sorry about the length of the post...

HTH

 

[theThirdElement]

Hi Ehx,

I figure it's probably easier to learn OO concepts first WITHOUT referring to a partcular language. Specific language may have subtle different definition to a particular OOP term. e.g. a lot of people got confused of the difference between "Interface" and "Inheritance" in Java. Language syntax could also confuse and blur things a bit more.

Once you have a good idea of what OO is in theory, then refer to a language. You should then see all the relationships and OO structure in that language.

Just my learning experience,

Ed

 

[EdwardJS024]

In theory no class should be a base class. All base classes should be implement as abstract classes.

Second, Interfaces are contracts that abstract class provide a generic implementation off.

Now concrete classes inherit from abstract and override any of the generic implementations of the abstract class.


Interfaces - Specifies a contract, that classes implement.

Abstract classes - Implements a generic implementation of the interface

A derived class extends the abstract and provides more detailed specifi implementations of the abstract implementation.


Example:


ISavable {
Save();
}

public abstract Document extends ISavable {
abstract Save() {
//generic saving...
}
}

public class BitMapDocument extends Document {
public override Save() {
//saving specific to documents
}
}

 

[ehx6]

Thanks all for your info. I will keep reading about OOP and hope things will clear out for me.
stevexff, your sample really made things more obvious for me.So basically when I have a common method , I can create an interface and put all common methods with no code inside each methods.( this fullfill what needs to be done )

Then any class that need to implement the interface, can reference to the I interface and put some code inside the methods needed.

This mean that I am going to create same method and this time I will be putting some code to fullfill ( how the methods are done)..... so far so good. HOWEVER

Here what confused me, lets say I will create a class that has all methods and then create other classess that reference to the first method and override the common methods. For example, in our first senario. a Customer class contain a method GetAddress() which contain some code. so I can reference Customer method inside Credit Card and override the getAddress() method..... I guess my thinking is wrong.

What I ment when learing those : Instantiating a class, Inheritance, Abstracts, Interface and implementing interface. The question that is in my mind is What to use and When. What makes me think to use Inheritance vs Abstract classes vs Interface etc.... I think I am still in the confusion state where I start reading about OOP and do not actually know how to Utilize them effectivly.

If anyone knows a way where the learning curve is easy, please say so.
thanks
Ehx