Skip to main content

Explain the difference between an interface and an abstract class in objectoriented programming

Explain the difference between an interface and an abstract class in object oriented
programming.

Answer:

The specific answer to this depends on which language you’re developing with.

An interface declares a set of related methods, outside of any class.
An abstract class is an incomplete class definition that declares but does not define all of its methods.

An interface defines an application programming interface (API) that is independent of
any class hierarchy. In fact, interfaces can be used in non-OO programming models, such as
component based models like COM and CORBA. However, you’re focusing on the use of interfaces in an object-oriented context, where they are useful in their own right. Interfaces are the ultimate encapsulators, because they hide all the details of the classes that implement their methods from the user of the interface. They’re particularly important - almost necessary, in fact - in languages that only support single inheritance (classes can only inherit from one base class). A class that exposes its members via an interface is said to implement the interface.

Unlike an interface, an abstract class is a proper class: It can have data members and can be a subclass of other classes. Unlike a concrete (nonabstract) class, however, some of its behaviors are deliberately left to be defined by its own subclasses. Abstract classes cannot be instantiated because of this - only instances of concrete subclasses can be created.
An interface is almost identical to an abstract class with no data members and no method definitions.

In C++ this is exactly how you’d define an interface: by declaring a class with no data members and only pure virtual functions - something like this, for example:

class Interface {
public:
virtual void getState( int oState, int nState ) = 0;
};

A class could then “implement” the interface by deriving from it:

class MyClass : SomeOtherClass, Interface {
public:
void getState( int oState, int nState ){
if( nState > oState ){
..... // do stuff
}
}
.... // remainder of class
};

In Java, an interface is defined using the interface keyword:

public interface MyInterface
void getState( int oState, int nState );
}

The interface is then implemented by a class:

public class MyClass implements MyInterface {

public void getState( int oState, int nState ){
.... // do stuff
}
.... // remainder of class
}

A common pattern you’ll see with languages that support both interfaces and abstract classes is the provision of a default implementation of an interface via an abstract class. For example, the following

interface:

public interface XMLReader {
public XMLObject fromString( String str );
public XMLObject fromReader( Reader in );
}

might have this default implementation:

public abstract class XMLReaderImpl {
public XMLObject fromString( String str ){
fromString( new StringReader( str ) );
}
public abstract XMLObject fromReader( Reader in );
}

A programmer who wanted to implement XMLReader would then have the option of creating a class that
subclasses XMLReaderImpl (likely as a nested class) and only implement one method instead of two.

Comments

Popular posts from this blog

MFC - Microsoft Foundation Classes Design Patterns

1 Introduction This paper describes the use of object-oriented software design patterns, as presented in Design Patterns: Elements of Reusable Object-Oriented Software by Gamma et al., within the Microsoft Foundation Class Library (MFC). MFC is used for implementing applications for Microsoft Windows operating systems. Because of the size of the MFC library, a complete analysis would have been beyond the scope of this assignment. Instead, we identified various possible locations for design patterns, using the class hierachy diagram of MFC, and studied the source carefully at these locations. When we did not find a pattern where we expected one, we have documented it anyway, with examples of how the particular problem could have been solved differently, perhaps more elegantly, using design patterns. We have included a brief introduction to MFC in Section 2 , as background information. The analysis has been split into three parts, with one section for each major design pattern ca...

Explain Polymorphism and Flavors of Polymorphism...

Polymorphism is the ability of different objects to react in an individual manner to the same message. This notion was imported from natural languages. For example, the verb "to close" means different things when applied to different objects. Closing a door, closing a bank account, or closing a program's window are all different actions; their exact meaning is determined by the object on which the action is performed. Most object-oriented languages implement polymorphism only in the form of virtual functions. But C++ has two more mechanisms of static (meaning: compile-time) polymorphism: Operator overloading. Applying the += operator to integers or string objects, for example, is interpreted by each of these objects in an individual manner. Obviously, the underlying implementation of += differs in every type. Yet, intuitively, we can predict what results are. Templates. A vector of integers, for example, reacts differently from a vector of string objects when it receives ...

• Why might you need exception handling be used in the constructor when memory allocation is involved?

Your first reaction should be: "Never use memory allocation in the constructor." Create a separate initialization function to do the job. You cannot return from the constructor and this is the reason you may have to use exception handling mechanism to process the memory allocation errors. You should clean up whatever objects and memory allocations you have made prior to throwing the exception, but throwing an exception from constructor may be tricky, because memory has already been allocated and there is no simple way to clean up the memory within the constructor.