Why we need Abstract Class while we are having Class? - oop

Question

When we talk about conceptual level object oriented programming Concept,
Assume that we are going to create Car Object.therefore we need to Design parent class.Suppose if you are going to do the that part, how a would you do?
will you use Class or interface or abstract class ?
Then why would you use interface?
why can't we do the same thing with class/Abstract class?
what are advantages by using interface as a parent ?

Answer 1

You need abstract class, when you don't want to instantiate the super class, yet you want to implement some of the functionality.
Interface are needed when you have a single-parent inheritance, and you can't use abstract classes. If there was multi inheritance in Java, which I assume you are talking about according to the terms you use, Interfaces will be redundant.

Answer 2

Well, using your Car object, I'll try to explain the concept with a real world example.
Imagine, you're a little company (A) which makes car pieces, you make them for a bigger company (B) which is your client, that pieces will be used by other car constructors.
The company B must be sure that your pieces will follow a standard and will be compatible within all car constructors.
It is your interface.
Interfaces are used to define some standardized methods or attributes, taking our example, we can define that a piece has 4 holes in each corners to be fixed on another pieces made by another company.
An abstract is a little different, abstract are more concrete than interface (well I agree that's a kind of non-sense), but they are concret because they directly implements (for example an interface) a functionality whereas that Abstract class can never be instantiated.
Abstract class are mostly used to define some basic or shared functionality to make it DRY.
Therefore, you may create a Class which extends an Abstract class AND implements an interface.
Here is an example:
interface Vehicle {
protected $engine;
protected $wheels;
public function startUp();
public function stop();
}
Your Vehicle interface define a Vehicle which needs to have an engine and wheels (any number).
abstract class Car implements Vehicle {
protected $wheels = 4;
public function startUp() {
$this->engine->startUp();
}
public function stop() {
$this->engine->stop();
}
}
Because startUp() and stop() are just a proxy to the Engine object, we can put them in the abstract class to be reused in all the extended classes.
We set our Car class to have 4 wheels.
class Renault extends Car {
protected $color = 'yellow';
}
Here we just need to extend the Car abstract class, we add some color because it's cool.
Now, let's say that we want to bring our Renault to a car washing station, because we're implementing a known interface, the car washing station will be able to make its work without knowing that our Vehicle is Renault, but just knowing it is a Vehicle.
That's a really basic example, and it could be better designed but it should show you how it works.
Interfaces are not needed, at least PHP doesn't require any class to implements any Interface, however, you should use them, it is often a good practices and it helps you when writing API, Unit tests or sharing some code amongst other developers.

Answer 3

At the risk getting too deep and possibly too melodramatic, I will try to answer you questions to the best of my abilities.
Within the context of the example you presented, a 'Car' class with an abstract 'Vehicle' class would be the most appropriate solution. This is because a car can become a very complex object if you allow it. Instead of packing everything into a car class you may want to write a vehicle class to abstract away some of the arbitrary, higher-level data. This can be quite convenient if you plan on later implementing more capabilities or creating other types of vehicles like, for example: Planes. An abstract class allows your application more flexibility; if you felt need be, you could also abstract the vehicle class. Conceptually, OOP is about relating code to the way we were all hard-wired to think, in terms of abstraction and classification. However, if you are implementing simple sets of functionality, simple classes should suffice.
An interface is a totally different beast. An interface (in terms of computing) is a conceptual tool that allows the programmer to create a separation layer between the implementation and the application. For example, if you wanted to create some program to communicate with a sound card, you should create an interface class. In fact, that is essentially what a device driver is. Some languages, like Java, have a built-in interface construct to represent the same concept. You could theoretically create an interface within any language, however.
You could use a simple class, for simple features. Just keep in mind that: a class is used for the instantiation of objects; An abstract (or base) class is for abstracting away data from classes to create base functionality. In both cases, they each handle the code that does not tie directly with the applications implementation. However, These conceptual tools are not to be used interchangeably. This is the difference between software engineers and programmers; knowing when to use the right tools versus knowing how you use them, respectively.
An interface, as I addressed earlier, should be use to separate the implementation from the application. If your communicating with a device driver you don't want to mix in the code for the GUI. An interface acts like a liaison between the two. Technically, an interface is 'implemented' not inherited from; however, in languages with no clear interface construct, a class is used to simulate the concept and thus would be inherit from.

Answer 4

Abstract classes.
Abstract class is useful when you have some concept that generalizes other entities but does not have 'real-world' incarnation.
Suppose you have Car class in your program and you're going to have HummerH2, ToyotaCamry and DaewooMatiz classes derived from Car. Car is Some-Abstract-Car, any car belongs to Car class but Car class itself does not denote any real car.
So you can define Car class as follows:
abstract class Car
{
public abstract void Move();
public abstract void Stop();
public abstract int GetMaximumSpeed();
public int GetVehicleID()
{
return vehicleID;
}
protected int vehicleID;
}
And then derive you HummerH2, ToyotaCamry and DaewooMatiz from Car and implement Move(), Stop() and GetMaximumSpeed() there. Note that Car class will enforce it's subclasses to have vehicleID field.
Interfaces
Interfaces are like abstract classes except that you cannot declare fields in interface. Interfaces are used to declare some public functionality that class must implement.
In our case, we could declare interface IMovable:
interface IMovable
{
void Move();
void Stop();
abstract int GetMaximumSpeed();
}
and then inherit Car class from IMovable:
abstract class Car: IMovable
{
public int GetVehicleID()
{
return vehicleID;
}
protected int vehicleID;
}
Note that now subclasses of Car must implement Move() and Stop() methods.
And than we can define some Ship class that will implement IMovable interface. In this case, both Ship and Car can be moved as IMovable object without any regardless of whether it is a car or ship or whatever implementing IMovable interface.
P.S.: Of course, when you write some simple game with only one type of cars in it you can define non-abstract class Car and use it.

Answer 5

I have a simple explanation ,Suppose u have a class B which extends A.
Now U want to do cloning in B class Or U want to do sorting.So now what will u do?
IF u have made a Clonable class/Comparable class how can u use it in B coz B already extends A .So the solution u have is make another class D which extends clonable class.make another class E which extends D( to use cloning methods) and then.... means because java does not support multiple inheritance u have to make no of classes to do dis..
But when U have defined the Clonable as an interface u dont what u will have to do just implements it in Ur B class.i.e no excess coding required.
This was an explanation from me why we make interfaces.
Please correct me if I am wrong somewhere.
thanks.