UNC COMP 301 - F26/Lec 6 - Abstract classes; Inheritance application; Aggregation, Composition

Overview

Muhammad Sayeed Ghani explains how abstract classes enforce shared behavior when subclasses must implement a method but no sensible default exists, then applies inheritance to refactor four animal classes into an Animal interface and shared implementation. He concludes by contrasting aggregation and composition through a university Course model, emphasizing how component ownership, creation, and lifetime depend on the design’s use case.

Key takeaways

An abstract method is useful when subclasses must expose the same operation but the superclass has no meaningful default; declaring it also requires the containing class to be abstract.
Abstract classes can combine fields, constructors, and shared implementations with mandatory subclass methods, while an interface primarily defines a type contract.
In the animal refactoring, Animal provides a common API and AnimalImpl shares ID, location, and getters; animal-specific movement and sounds remain overridden or abstract.
A final reference does not guarantee immutability: Course’s final roster reference still points to a list whose student membership can change.
Aggregation and composition both model has-a relationships, but differ in component ownership and lifecycle; the right classification depends on how a particular system creates, accesses, and replaces components.

Chapters

0:00 Assignment 2 Reminder and Lecture Roadmap

Ghani urges students to accept the Assignment 2 invite before it expires that night, even if they are not ready to begin.
The lecture plans to cover abstract classes and methods, apply inheritance to a larger example, then introduce object relationships.

1:35 Why Person Does Not Define getStatus()

The earlier Student and Professor classes shared name fields, constructors, and getName(), so those elements moved into a Person superclass.
Their getStatus() methods were not shared: students derive class standing from credits, while professors use academic rank.
“Status” also has no clearly defined meaning for every Person subclass, making it a poor general-purpose Person method.

8:18 Enforcing getStatus() Without a Default

If every Person subtype must provide getStatus(), a concrete superclass method could be overridden, but its default behavior would be arbitrary.
A null or generic default does not explain what status means for other possible people, such as university service employees or infants.
An abstract getStatus() declares the required method without supplying an implementation, obligating concrete subclasses to define it.

13:08 Abstract Methods Require Abstract Classes

Declaring public abstract String getStatus() without a method body makes the containing Person class abstract.
A class with one or more abstract methods must be abstract; an abstract class does not necessarily need any abstract methods.
Abstract classes cannot be instantiated, and a hierarchy must eventually reach a concrete subclass that implements its inherited abstract methods.

16:30 Abstract Classes Versus Interfaces: State and Constructors

Like an interface, an abstract class can define a contract that subclasses must satisfy and cannot be instantiated directly.
Unlike an interface’s contract, an abstract class can hold instance state in fields and define a constructor to initialize that state.
A class extends an abstract class, whereas it implements an interface; abstract classes can combine shared code and state with abstract requirements.

19:28 When to Choose an Abstract Class

Use an abstract method when all relevant subclasses need the same operation but no sensible superclass implementation exists.
Abstract types let client code call a shared operation without depending on whether the runtime object is, for example, a Student or Professor.
A class can also be abstract solely to prevent generic instances, such as an Animal, even if all its methods have implementations.

25:39 Refactoring Four Animal Classes: Bears, Python, and Robin

The example starts with separate BlackBear, PolarBear, Python, and Robin classes, each storing an ID and a Point3D location.
Point3D holds x, y, and z coordinates and calculates distance using the three-dimensional Pythagorean formula.
The bears share lumbering, trekking, and growling; Python slithers and hisses, while Robin can hop, walk, or fly and chirps.

35:00 Animal Interface and Shared Animal Implementation

An Animal interface defines four common operations: getID(), getLocation(), move(), and speak().
BlackBear, PolarBear, Python, and Robin implement Animal, while a shared AnimalImpl class provides reusable behavior.
AnimalImpl centralizes the common ID and Point3D location fields, constructor, and getters; inconsistent field names can be standardized during refactoring.

43:00 Sharing Location Updates with super.move()

Each animal’s move logic differs, but all four implementations finish by setting location to the requested destination.
AnimalImpl supplies a concrete move() that updates the location; each animal overrides move() for its own movement rules and calls super.move() afterward.
The shared method standardizes the operation for callers, even though subclasses still implement most of the movement behavior.

53:00 Abstract speak() and Further Bear Specialization

Because bears growl, Python hisses, and Robin chirps, AnimalImpl cannot provide a meaningful common speak() body.
Making speak() abstract also makes AnimalImpl abstract; each concrete animal class must provide its own overridden sound behavior.
Ghani suggests a further Bear interface and implementation to share the BlackBear and PolarBear behavior, leaving that refactoring as an exercise.

55:09 From Point Abstraction to the University Course Model

A Line represented by two Point objects is simpler to reason about than four separate coordinate values, illustrating abstraction through encapsulation.
The example extends the university model with Room and Course objects alongside existing Professor and Student classes.
Room uses private final fields and a useful toString() representation for its building and room details.

59:07 Course Fields, Roster Mutability, and Object Setup

Course stores a Professor, Room, student roster, course name, and credit count; its constructor receives the course’s initial objects and values.
Final references do not make Course fully immutable: the roster reference cannot be reassigned, but students can still be enrolled or dropped from its list.
The example creates professors, rooms, and courses, enrolls students, and prints course details and rosters.

1:03:15 Aggregation: Courses Hold Independent Objects

Aggregation is a has-a relationship: Course is a container that refers to components such as a Professor, Room, and students.
In the example, these objects exist independently of Course; ending a course does not end the lives of its professor or students.
Aggregation differs from inheritance’s is-a relationship: a Course has a Professor, but a Course is not a Professor.

1:05:09 Composition, Object Lifetimes, and the Ownership Spectrum

Composition describes tightly owned components whose lifetimes depend on the container; the example is a human body and its heart, lungs, and limbs.
A backpack containing independently created books and a calculator is aggregation, while a building that creates and manages its rooms is closer to composition.
A vehicle’s wheels, axles, and engine can fit either model depending on whether the system treats them as replaceable independent objects or owned parts.
Ghani characterizes aggregation and composition as a spectrum shaped by the use case, and previews a later comparison of composition and inheritance.

Summary, takeaways, and chapters were generated by AI from the video's transcript and may contain errors. The video belongs to its creator, Muhammad Sayeed Ghani.