Exam Practice
MCQs, flashcards, UML scenario diagrams, and refactoring examples covering the four pillars, SOLID, GRASP, DRY/YAGNI/KISS, and code refactoring.
Reference text: Object First with Java, Barnes and Kölling, 6th Ed.
Four pillars
AbstractionHide unnecessary detail, show what an object does.
EncapsulationGroup data and behavior, protect and control access.
InheritanceIS-A relationship, reuse via extends.
PolymorphismOne reference, many possible object types.
Relationships
| Relationship | Meaning | Example |
|---|---|---|
| Association | Objects are connected | Student, Course |
| Aggregation | Weak whole-part, part can exist alone | Team, Player |
| Composition | Strong whole-part, part depends on whole | House, Room |
| Inheritance | IS-A relationship | Dog, Animal |
| Realization | Implements an interface | Circle, Drawable |
| Dependency | One class uses another | A uses B |
SOLID
S - Single ResponsibilityOne class, one reason to change.
O - Open-ClosedOpen for extension, closed for modification.
L - Liskov SubstitutionSubtype must be usable wherever supertype is expected.
I - Interface SegregationDo not force a class to depend on methods it does not use.
D - Dependency InversionDepend on abstractions, not concrete implementations.
Other design principles
DRYDon't Repeat Yourself. One authoritative place for each piece of logic.
YAGNIYou Aren't Gonna Need It. Don't build functionality before it is needed.
KISSKeep It Simple. Prefer the simplest solution that works.
Hollywood PrincipleDon't call us, we'll call you. Framework code calls your code, not the reverse.
GRASPGeneral Responsibility Assignment Software Patterns, for assigning responsibilities to classes.
GRASP patterns
Information ExpertGive the responsibility to the class that has the needed information.
CreatorClass A creates B when A aggregates, contains, or closely uses B.
ControllerA non-UI class coordinates a system event or use case.
Low CouplingMinimize unnecessary dependencies between classes.
High CohesionKeep a class's responsibilities closely related.
PolymorphismLet varying behavior live in the types themselves, not conditionals.
Pure FabricationAn artificial class added purely for low coupling and high cohesion.
Protected VariationsWrap an unstable point behind a stable interface.
Refactoring essentials
RefactoringRestructure code without changing external behavior.
Technical DebtProblems from quick, messy coding decisions that pile up over time.
Code SmellA sign of a deeper design problem, not necessarily a bug.
Legacy CodeInherited existing code, often undertested and hard to follow.
18 refactoring techniques
Extract MethodLong method to smaller, well-named method.
Inline MethodUnnecessary method to code placed directly.
Extract ClassOne class does too much to a new class.
Inline ClassUseless small class merged into another.
Move MethodBehavior moved to the class it belongs to.
Move FieldData moved to the class it belongs to.
Replace Temp with QueryTemp variable becomes a method.
Rename Variable / MethodUnclear name to a meaningful one.
Pull Up FieldCommon field moved to the parent.
Push Down FieldSpecific field moved to the child.
Pull Up MethodDuplicate method moved to the parent.
Push Down MethodSpecific method moved to the child.
Extract InterfaceCommon behavior becomes an interface.
Replace Type Code with SubclassesType code becomes a subclass hierarchy.
Decompose ConditionalComplex if becomes small, named methods.
Introduce Parameter ObjectMany related params become one object.
Replace Conditional with PolymorphismSwitch on type becomes overriding.
Substitute AlgorithmSame result, cleaner algorithm.