2IRR00 · Topic 07
Making Software Reusable
Data abstraction, enums, records, SOLID, KISS
Types, abstract classes vs interfaces, enums, records
Data abstraction defines new reference types (classes, abstract classes, interfaces, enums, records) to represent the real world, decouple representation from implementation, and prevent value corruption.
Primitive types store a value (copy = independent). Reference types store a reference (copy = shared reference; changing the copy changes the same object). arr.clone() deep-copies primitives but only shallow-copies references.
Abstract class vs interface (neither is instantiable): an interface is a collection of behaviour, all methods must be implemented by the class, and a class can implement MULTIPLE interfaces. An abstract class is abstracted behaviour of a class hierarchy, can have abstract AND concrete methods (must have ≥1 abstract method), and is part of single inheritance.
Enum: a fixed set of named constants (public static final); no 'new', no inheritance, but can have a constructor, fields, methods, and implement interfaces; improves type safety; usable in switches/loops.
Record (Java 14+): stores fixed 'components'; auto-generates private fields, public getters, a canonical constructor, and toString(); for simple data carriers (points, tuples).
public enum Suit {
DIAMONDS(Color.RED), HEARTS(Color.RED),
SPADES(Color.BLACK), CLUBS(Color.BLACK); // semicolon required
private final Color color;
Suit(Color color) { this.color = color; }
public Color getColor() { return color; }
}Common mistakes
- Believing enums need a mandatory constructor (it's optional) or can be defined at runtime (they can't).
- Representing fixed-domain values (suits) as raw int/String — easy to corrupt, coupled to code.
Exam tips
- Enum properties (MCQ): fixed set of named constants ✔, improves type safety ✔; constructor NOT mandatory ✘, cannot be defined at runtime ✘.
- Interface: multiple implementable, all methods abstract (classically). Abstract class: single inheritance, mix of abstract + concrete.
Types, abstract classes vs interfaces, enums, records practice
1 questions
SOLID & KISS
SOLID is five OO design principles (Martin): Single responsibility, Open/closed, Liskov substitution, Interface segregation, Dependency inversion. KISS = Keep It Simple.
Single responsibility: a class has only one reason to change.
Open/closed: open for extension, closed for modification — add features (e.g. via inheritance) without changing existing code.
Liskov substitution: code using a superclass reference must work with any subclass object without knowing it.
Interface segregation: no client should depend on methods it doesn't use — split large interfaces into cohesive ones.
Dependency inversion: high- and low-level modules both depend on abstractions; the client refers to an ADT, the provider implements it — so implementations can be swapped without impacting other units.
KISS: simpler solutions are less error-prone and more comprehensible (we design for humans).
Common mistakes
- Listing 'Separation of concerns' as a SOLID letter — it is a general principle, NOT one of the five.
- Confusing the letters (e.g. interface segregation vs dependency inversion).
Exam tips
- MCQ trap: SOLID = Single responsibility, Open/closed, Liskov, Interface segregation, Dependency inversion. 'Separation of concerns' is a distractor (wrong).
- Open/Closed does NOT require inheritance — composition (Strategy pattern, interfaces) also achieves it. Trap option: 'must be implemented via inheritance' is FALSE.
- Dependency inversion ⇒ depend on abstractions; client codes against the ADT, provider implements it.
SOLID & KISS practice
1 questions