Definition and Purpose

Concept

Interface: abstract type specifying method signatures without implementation. Purpose: define a contract for classes to implement, ensuring a common API.

Role in OOP

Enables polymorphism: objects of different classes accessed through common interface type. Facilitates loose coupling and modular design.

Historical Context

Originated to solve multiple inheritance issues. Introduced in Java 1.0 and C# 1.0 as a clean abstraction mechanism.

Syntax and Structure

General Components

Contains method signatures: name, return type, parameters; no method bodies (until default methods). May include constants.

Java Syntax

Declared with 'interface' keyword. Methods implicitly abstract and public. Fields implicitly public, static, final.

C# Syntax

Declared with 'interface' keyword. Methods implicitly public and abstract. No fields allowed; only properties, methods, events.

Interfaces and Polymorphism

Subtype Polymorphism

Interface type variable can refer to any implementing class instance. Enables dynamic method dispatch.

Decoupling Code

Code depends on interface, not concrete class. Easier to extend and maintain.

Example

Shape interface with method draw(); Circle, Rectangle implement draw(); client code uses Shape reference.

interface Shape { void draw();}class Circle implements Shape { public void draw() { /* implementation */ }}class Rectangle implements Shape { public void draw() { /* implementation */ }}void render(Shape s) { s.draw();}

Interfaces vs Multiple Inheritance

Multiple Inheritance Problems

Diamond problem: ambiguity with inherited method implementations. Complexity in state management.

Interfaces as Solution

Only method signatures inherited, no state or implementation. Eliminates ambiguity by requiring implementation in class.

Comparison Table

AspectMultiple InheritanceInterfaces
Allows state inheritanceYesNo
Method implementation inheritanceYesNo (except default methods)
Ambiguity issuesYesNo
Supported in JavaNoYes

Implementation in Java

Declaring Interfaces

Use 'interface' keyword. Example: public interface Runnable { void run(); }

Implementing Interfaces

Use 'implements' keyword in class declaration. Must implement all interface methods or declare class abstract.

Extending Interfaces

Interfaces can extend multiple other interfaces using 'extends' keyword.

public interface A { void methodA();}public interface B extends A { void methodB();}public class C implements B { public void methodA() { /* impl */ } public void methodB() { /* impl */ }}

Implementation in C#

Declaring Interfaces

Use 'interface' keyword. All members implicitly public and abstract.

Implementing Interfaces

Use ':' symbol followed by interface name(s). Must implement all members explicitly or implicitly.

Multiple Interfaces

Supports multiple interface inheritance. Implements all members from each interface.

interface IWorker { void Work();}interface IRunner { void Run();}class Employee : IWorker, IRunner { public void Work() { /* impl */ } public void Run() { /* impl */ }}

Default and Static Methods

Default Methods in Java 8+

Allow method implementation inside interfaces using 'default' keyword. Enables backward compatibility.

Static Methods

Interfaces may contain static methods callable on interface type without instance.

Conflict Resolution

If multiple interfaces provide same default method, implementing class must override it explicitly.

interface A { default void show() { System.out.println("A"); }}interface B { default void show() { System.out.println("B"); }}class C implements A, B { public void show() { A.super.show(); // resolve conflict B.super.show(); }}

Interfaces in Design Patterns

Strategy Pattern

Defines family of algorithms via interface; clients select implementation dynamically.

Observer Pattern

Subject and Observer interfaces decouple notification mechanism.

Factory Pattern

Factory interface abstracts object creation details from clients.

Advantages and Limitations

Advantages

Enforce contract consistency, enable polymorphism, support multiple inheritance, decouple code, enhance testability.

Limitations

No state or implementation (except default methods), cannot declare constructors, possible verbose code due to many small interfaces.

Mitigations

Use default methods carefully, combine interfaces with abstract classes when state needed.

Best Practices

Interface Segregation

Design small, specific interfaces to avoid forcing unnecessary methods on implementers.

Naming Conventions

Use adjectives or descriptive nouns (e.g., Runnable, Comparable). Avoid verbs.

Documentation

Document method contracts clearly to prevent implementation ambiguity.

Common Mistakes

Overloading Instead of Overriding

Failing to implement interface methods correctly, leading to hidden bugs.

Large Fat Interfaces

Creating monolithic interfaces violating Interface Segregation Principle.

Ignoring Default Methods

Not leveraging default methods leads to breaking changes in evolving APIs.

Comparison with Abstract Classes

Inheritance vs Contract

Abstract classes provide partial implementation and state; interfaces only specify method signatures (except default methods).

Multiple Inheritance

Classes can implement multiple interfaces; can extend only one class.

Use Cases

Abstract classes: shared base functionality. Interfaces: capability declaration, polymorphic behavior.

FeatureInterfaceAbstract Class
State (fields)NoYes
Method implementationNo (except default methods)Yes
Multiple inheritanceYesNo
ConstructorsNoYes

References

  • Booch, G., Object-Oriented Analysis and Design with Applications, Addison-Wesley, 3rd ed., 2007, pp. 45-72.
  • Schildt, H., Java: The Complete Reference, McGraw-Hill, 11th ed., 2018, pp. 300-340.
  • Albahari, J., & Albahari, B., C# 9.0 in a Nutshell, O'Reilly Media, 2021, pp. 220-255.
  • Gamma, E., Helm, R., Johnson, R., & Vlissides, J., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994, pp. 17-45.
  • Larman, C., Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design, Prentice Hall, 3rd ed., 2004, pp. 150-180.