Generalization & Inheritance

Before we start

The one-sentence idea

Grouping similarities in different classes into a general class. That's all generalization is.

Everyday analogy

Think about Animal. A Dog is an animal. A Cat is an animal. Both breathe, eat, and have a name and an age — so instead of writing "has a name" three separate times, you say it once, up at "Animal," and let Dog and Cat both get it for free. Dog then only needs to add what makes it special: it bark()s. Cat only adds meow().

That's the whole chapter in one idea: pull out what's shared, push down what's specific. UML calls this relationship generalization, and the mechanism that lets Dog and Cat automatically "receive" Animal's features is called inheritance.

Definition

Generalization is the relationship between one class (the superclass) and one or more variations of it (the subclasses).

The superclass holds whatever every variation has in common — attributes, operations, relationships. Each subclass then inherits all of that automatically, and adds only what makes it different. This is also called the "is-a" relationship: a Dog is an Animal, a Cat is an Animal.

Animal name : string age : int Dog bark() Cat meow()

The hollow triangle is UML's generalization arrow — it always points up at the superclass. Dog and Cat both inherit name and age for free.

Notation rule: the hollow arrowhead points to the superclass, never the subclasses. You can draw a separate arrow to every subclass, but it's usually cleaner to group them into one tree, as shown above.

Generalization can stack — a hierarchy can have several levels, not just one. When it does, we call the classes above a given class its ancestors, and the classes below it its descendants. An object automatically has every attribute of every ancestor, and can call any operation defined anywhere up the chain.

Worked examples

Seeing it with the book's own diagrams

The textbook uses two examples. Let's walk both, simplified.

Example 1 — Factory equipment (Figure 3.24)

Every physical asset in a plant is a piece of Equipment — it has a name, a manufacturer, a weight, and a cost. But a Pump also needs a flow rate, and a Tank also needs a volume. So we generalize:

Equipment name : string manufacturer : string weight : float cost : float Pump suctionPressure flowRate HeatExchanger surfaceArea tubeDiameter Tank volume pressure CentrifugalPump impellerDiameter DiaphragmPump diaphragmMaterial PlungerPump plungerLength SphericalTank diameter PressurizedTank diameter height FloatingRoofTank diameter height

Figure 3.24 — Standard UML generalization notation: each class box has a name compartment and an attribute compartment, and hollow-triangle arrows converge on a shared trunk pointing up to the superclass. This is a multilevel hierarchy: a real object like P101 : DiaphragmPump carries the features of DiaphragmPump, Pump, and Equipment all at once.

Where a class sits in the tree doesn't matter visually. The book notes that whether Tank is drawn to the left or right of Pump carries no meaning — only the arrows themselves matter.

Example 2 — Shapes on screen (Figure 3.25)

Every Figure drawn on screen — a point, a line, a circle — shares a color, a position, and operations like move, select, and rotate. But some behavior only makes sense for certain shapes: you can't sensibly "fill" a single Point with color, since it has no interior.

Figure color centerPosition move() select() rotate() ZeroDimensional OneDimensional orientation scale() TwoDimensional orientation fillType scale() fill() {dimensionality} Point display() Line endPoints display() Arc radius startAngle arcAngle display() Spline controlPts display() Polygon numOfSides vertices display() Circle diameter display() rotate()

Use of Generalization

The book gives three concrete payoffs.

01

Polymorphism

Code written against the superclass — "tell this Figure to rotate()" — automatically runs the right version for whatever subclass the object actually is. Add a new shape later, and old code doesn't need to change.

02

Structuring the model

Drawing a generalization is a conceptual claim, not just a coding shortcut — you're building a taxonomy that says "these things are fundamentally related," which is more meaningful than describing every class in total isolation.

03

Reuse

You write the shared behavior once — in the superclass — and every subclass gets it without retyping it. You can still tweak a subclass to fit its own needs on top of what it inherited.

Three words, one idea: generalization and specialization are the same relationship viewed from opposite ends — generalization looks up toward the shared superclass, specialization looks down toward the refined subclasses. Inheritance is simply the mechanism that makes the sharing happen.

Overriding features

Sometimes a subclass needs to replace, not just add to, something it inherited. That's called overriding: the subclass defines a feature with the same name as one from its superclass, and its version takes priority.

From Figure 3.25: Figure declares a generic display operation, but every leaf shape (Point, Line, Circle...) must override it with its own drawing logic — a circle and a line simply don't draw the same way. Circle also overrides rotate to do nothing at all, since rotating a circle in place doesn't change how it looks — a small performance win.