ReadyToGo Logo ReadyToGo
Login Sign Up
› Module 6: Abstract Classes, Interfaces & Relationships › 6.2 Interface: Pure Behavioral Contracts
M O D U L E

Module 6: Abstract Classes, Interfaces & Relationships

Abstract classes, interface contracts, association, aggregation, and strong composition

6.1 Abstract Class: Partial Blueprints

An Abstract Class is a restricted class declared with the abstract keyword that cannot be directly instantiated with new. It is engineered to serve as a foundational superclass for related derived classes.

An abstract class can contain both abstract methods (declared without body, forcing subclasses to implement them) and concrete methods (fully implemented, providing shared inherited functionality).

6.2 Interface: Pure Behavioral Contracts

An Interface is a formal contract specifying a collection of abstract method signatures that an implementing class must define. Interfaces contain zero instance state (all variables are implicitly public static final constants).

Figure 6.1: Architectural Comparison: Abstract Class vs Interface Abstract Class • Can have abstract AND concrete methods • Can maintain instance variables (state) • Can define constructors • Supports single inheritance only • Defines "what a class IS" (core identity) Interface • Traditionally only abstract method specs • Only static final constants; NO instance fields • NO constructors allowed • Supports multiple inheritance of interface • Defines "what a class CAN DO" (capabilities)

Figure 6.1: Abstract classes establish shared state and code reuse; Interfaces define contract capabilities across unrelated class hierarchies.

6.3 Object Relationships: Association, Aggregation & Composition

Beyond "IS-A" inheritance, OOP architectures model how independent objects connect and interact. These fall into three distinct relationships of increasing tightness:

  • Association (Uses-A): A loose peer relationship between two autonomous objects where neither owns the other. Both can exist independently (e.g. Teacher and Student).
  • Aggregation (Has-A, Weak): A whole-part relationship where a container object contains references to parts, but the parts have an independent lifecycle. If the container is destroyed, the parts survive (e.g. A Department has Professors; if the department closes, professors still exist). Represented in UML by an empty diamond.
  • Composition (Has-A, Strong): A strict whole-part relationship with tightly bound lifecycles. The part cannot exist without the whole. Destroying the container immediately destroys all composite parts (e.g. A House has Rooms; if the house is destroyed, the rooms cease to exist). Represented in UML by a solid filled diamond.
Figure 6.2: Association vs Aggregation vs Composition 1. Association (Independent objects, peer link): Teacher teaches → Student (Both exist independently) 2. Aggregation (Weak Has-A: Part survives without Whole): Department Professor (Professor survives if Dept closes) 3. Composition (Strong Has-A: Part cannot exist without Whole): House Room (Room is destroyed if House is destroyed)

Figure 6.2: Structural differentiation between loose Association, weak Aggregation (empty diamond), and life-bound Composition (filled diamond).

MODULE COMPREHENSIVE QUIZ

Module 6 Final Quiz

Test your understanding across all 3 topics of this module with interview-grade questions, tricky edge cases, and code output predictions.

Take Module 6 Final Quiz →
ReadyToGo · OOP Concepts Study Guide
Yukti Mascot