Printable View
I know abstract classes are created when you don't know in advance how the method is going to be implemented or how the logic should work beforehand, but why would you create a method that you won't be using or won't be of use to your CURRENT program?
And interface has almost the same definition, but the question is why should a programmer create them in the first place if they don't perform anything? :confused:
Because it gives others the flexibility of implementing the methods of the interface in a manner they want, but because it's done as per the 'guidelines' of the interface, a calling class will know exactly what methods are available to use.
For example, in .NET, you can define an interface that defines what a 'database connection' class should look like. Now, once you do that, you can implement the interface and write a class that connect to SQL Server. Then you can write another class for MS Access. And another that connects to a robot on an airport runway in Lusaka that interacts with a human via semaphore.
When you need to use it, the calling class can declare an object of the SqlConnection class or SemaphoreRobotInLusakaConnection class, and then call the .Open method. Because they both implement a 'database connection' interface, the calling class knows that it will have an .Open method.
In addition to "don't know": "don't care". If you want an object to do something, you might not care how it does it; you just want it to happen and give the desired result. You might not even care what the object represents, as long as it can do what you want.
The difference betwen abstract classes and interfaces is one of semantics; it's the difference between the "is-a" and "has-a" relationships in OOD. You can have a car, but not a car that isn't any particular model of car; you might say that all car classes inherit from an abstract Car class. You can drive cars, but you can also drive trucks, buses, and other vehicles; you could say that they all implement a Driveable interface, or such.
Abstraction is a way to avoid details when they're not relevant.
Interfaces only expose definitions, or signatures which classes implementing the interface must adhere to/implement - they are entities themselves and not classes which can't have an implementation.
Abstract classes can further define scope and implementations of methods which can then be overridden or overloaded - i.e. in some cases you might want to display just a method signature in the same way, but you also have the option to write and expose methods containing logic which inheriting classes can then call.
This isn't quite true. You construct your project to include one or both types in order for conformity. You may know all the details you need for a car type at the project design stage, and you can write them into abstract classes or interfaces in order to define the known properties.Quote:
I know abstract classes are created when you don't know in advance how the method is going to be implemented or how the logic should work beforehand
Hence when you come back to look at your project, you can goto these and review what each of the inheriting/implementing classes of mini, porshe, ferrari and 100's of other car classes all have in them at a single glance. It also structures you program in a manner whereby additional items can be added easier.
hhmm, really appreciate all the explanation, thanks guys! I guess the only way i can really dig this is to see it in action, to perhaps support a medium size application or create one to fully understand the true purpose of this powerful facility.
:)
You could try it out on a small application at home to at least get an idea of it in motion.