Objectively Speaking: What Building a Media Diary in Java Taught Me (Besides Patience)

This week’s blog is dedicated to the unsung hero of my university life right now: my Object-Oriented Programming (OOP) assignment. I’ve spent a good chunk of the past week inside VS Code (although NetBeans or IntelliJ would the top choice for this one, requirements told me otherwise), slowly sculpting a Media Diary application in Java while also trying not to melt into a puddle of Boolean confusion.

Let’s just say... the caffeine intake was high, the bugs were stubborn, and the victory dances after a successful build were plentiful (if not entirely graceful).

---

The Assignment

The brief? Design and build a Java application that allows users to track their media consumption across a week. Think TV shows, books, video games, podcasts... basically, all the ways we avoid doing our chores.

The app had to include good class design, proper encapsulation, and thoughtful use of inheritance, interfaces, and abstraction. So, I did what every determined developer does when faced with such a challenge: opened a fresh Java file and whispered “let’s do this” to the void.

---

Building Blocks

The application is built around several core classes:

• User: the person doing the watching/reading/gaming
• MediaDiary: a container for that week’s entries
• MediaEntry: the abstract parent of various specific entries like BookEntry, TVShowEntry, and GameEntry
• TimeTracker: because someone had to do the maths
• Comparer: an interface that allows for different comparison strategies (e.g. time spent, purpose of media)

After many UML diagram drafts (some with more arrows than a medieval battle), I finally landed on a structure that made sense and didn’t make my IDE weep.

---

Features I’m Proud Of

• Comparison Logic: I implemented a comparer interface with a concrete class CompareByPurpose that tells you who watched more “Educational” content. Spoiler: it wasn’t me.
• Encapsulation Done Right: All the juicy details are private, accessed neatly via getters and setters.
• Flexible Design: Thanks to interfaces and abstract classes, adding new media types or comparison strategies won’t break the whole app. Probably. I think. I am confident. Fairly.

---

Lessons Learned

1. Planning Matters: The UML diagram wasn’t just for decoration. It helped shape my thinking and structure.
2. Java is Strict: Forget a semicolon? Java will let you know. Repeatedly.
3. OOP Principles Work: Encapsulation, inheritance, and polymorphism are more than buzzwords. They’re sanity-saving patterns.
4. Refactoring is Life: Just when I thought I was done, I wasn’t. But that’s okay. The evolution of the code is part of the process.

---

In Closing

While I’m still working on the final polish (and, yes, the report), I’ve learned a ton. This project challenged me but also gave me the satisfaction of seeing concepts I’d studied come to life in an actual application.

And don’t worry, I’ll write a proper post-mortem once the grades are in. For now, I’ll leave you with this thought: Java may be verbose, but when it works, it really works.

Next up: abstraction, the mysterious stranger in the OOP party who only tells you what you need to know.