Inheritance in Java: Family Drama Done Right
Inheritance in Java is all about handing things down. Not your grandma’s silverware, but class attributes and methods. This week I’ve been learning how subclasses can inherit from superclasses, all while finishing up a UML diagram for my OOP assignment that now has more versions than my CV. From reusable code to class-based family trees, I break down the basics of inheritance with humour, clear examples, and mild existential dread. What Is Inheritance (in Code, Not Cash)? In Java, inheritance allows one class to acquire the properties and methods of another. You create a parent class (also called a superclass), and then other classes (subclasses) can extend it. public class MediaEntry { protected String title; protected int duration; public String getSummary() { return title + ": " + duration + " minutes"; } } public class TVEntry extends MediaEntry { private String channel; public String getTVSummary() { return getSummary() + ", aired on " + channel; } } With just a few lines, TVEntry inherits all the logic from MediaEntry. No duplication. No cut-and-paste disasters. It’s basically code with a family tree. OOP Assignment, UML Diagrams, and Mild Existential Dread In parallel with learning inheritance, I’ve also been working on my OOP assignment for uni. It’s the one where we design a full-on media diary app using classes, objects, and a healthy dose of late-night self-doubt. Building the UML class diagram took several tweaks, trials, and tribulations. But after enough iterations, I finally arrived at something I was happy with, and here it is: If you squint, you’ll see: A User who collects MediaDiaries A MediaDiary full of diverse MediaEntries (TV, books, video games, the usual modern distractions) A TimeTracker class that helps sum it all up (because someone has to do the maths) An abstract class and an interface politely shaking hands in the corner like they’re at a formal object-oriented networking event Let’s just say, this diagram has seen more edits than my CV. Why It Matters Inheritance isn’t just a clever trick. It is fundamental to writing scalable, maintainable code. Here’s why it matters: You reduce duplication (DRY principle for the win) You separate shared logic from specific details You make your code easier to test and extend That said, inheritance is not always the answer. Sometimes composition is the better approach. But that is a conversation for another day, and another caffeine level. Final Thoughts Learning inheritance made me realise how far I’ve come. A few months ago, I was wrestling with brackets. Now I’m designing class hierarchies with intention and confidence (well, most of the time). Inheritance is one of those moments where Java starts to feel less like a language and more like a toolkit, full of logic, structure, and the occasional dramatic relative. Next up: polymorphism, or as I call it, Java’s version of identity theft.

Inheritance in Java is all about handing things down. Not your grandma’s silverware, but class attributes and methods. This week I’ve been learning how subclasses can inherit from superclasses, all while finishing up a UML diagram for my OOP assignment that now has more versions than my CV.
From reusable code to class-based family trees, I break down the basics of inheritance with humour, clear examples, and mild existential dread.
What Is Inheritance (in Code, Not Cash)?
In Java, inheritance allows one class to acquire the properties and methods of another. You create a parent class (also called a superclass), and then other classes (subclasses) can extend it.
public class MediaEntry {
protected String title;
protected int duration;
public String getSummary() {
return title + ": " + duration + " minutes";
}
}
public class TVEntry extends MediaEntry {
private String channel;
public String getTVSummary() {
return getSummary() + ", aired on " + channel;
}
}
With just a few lines, TVEntry inherits all the logic from MediaEntry. No duplication. No cut-and-paste disasters. It’s basically code with a family tree.
OOP Assignment, UML Diagrams, and Mild Existential Dread
In parallel with learning inheritance, I’ve also been working on my OOP assignment for uni. It’s the one where we design a full-on media diary app using classes, objects, and a healthy dose of late-night self-doubt.
Building the UML class diagram took several tweaks, trials, and tribulations. But after enough iterations, I finally arrived at something I was happy with, and here it is:
If you squint, you’ll see:
- A User who collects MediaDiaries
- A MediaDiary full of diverse MediaEntries (TV, books, video games, the usual modern distractions)
- A TimeTracker class that helps sum it all up (because someone has to do the maths)
- An abstract class and an interface politely shaking hands in the corner like they’re at a formal object-oriented networking event
Let’s just say, this diagram has seen more edits than my CV.
Why It Matters
Inheritance isn’t just a clever trick. It is fundamental to writing scalable, maintainable code. Here’s why it matters:
- You reduce duplication (DRY principle for the win)
- You separate shared logic from specific details
- You make your code easier to test and extend
That said, inheritance is not always the answer. Sometimes composition is the better approach. But that is a conversation for another day, and another caffeine level.
Final Thoughts
Learning inheritance made me realise how far I’ve come. A few months ago, I was wrestling with brackets. Now I’m designing class hierarchies with intention and confidence (well, most of the time).
Inheritance is one of those moments where Java starts to feel less like a language and more like a toolkit, full of logic, structure, and the occasional dramatic relative.
Next up: polymorphism, or as I call it, Java’s version of identity theft.