Review of Java Fundamentals: Object-oriented Design
When I picked up the Java programming language a few years back, I focused on understanding the syntax, API and tooling of the language. Yet one area that I quickly glazed over was object oriented design patterns. Over the years, I’ve been itching to research this topic since I’ve heard that good architecture and the right design patterns could increase the maintainability of my source code.
For that reason, I decided last week that I would level up my design skills and take a course over Java object oriented design patterns on pluralsight.com.
The pluralsight course covered the popular SOLID principles mentioned in most Java OO design textbooks but with the authors spin on things.
After taking the course over a 3 day time span, I feel like it was time well spent! I had a lot of misconceptions about object oriented programming that were debunked in the first hour of the modules. Here are a few things I absorbed from the course.
1. The object with the most data should do the heavy lifting
2. Ask for help from objects, not their data
We can illustrate the first two points with a simple use case.
In this example we want to find the number of books with less than 100 pages in a shelf.
Ok Code
// ES6 const MAX_PAGES_FOR_SHORT_BOOK = 100 const numOfShortBooks = shelf.getBooks().filter(book => book.getTotalPages() < MAX_PAGES_FOR_SHORT_BOOK).length
Figure: Code 1.1
The problem here is that the shelf object is exposing too much information about itself, which could make refactoring hard.
In the course, the author states that objects should communicate and accomplish tasks using public methods, while keeping their inner data structures private and locked down. Avoid getter and setters of internal data like the plague. Not doing so will produce more run-time exceptions because of the unexpected way a external class is using your code.
Check this out.
Improved Code
// ES6 const MAX_PAGES_FOR_SHORT_BOOK = 100 const numOfShortBooks = shelf.countBooksByTotalPages(MAX_PAGES_FOR_SHORT_BOOK)
Figure: Code 1.2
As you can see, the method calls were wrapped inside .countBooksByTotalPages() to hide the complexity. Less code, less bugs.
3. Prefer interfaces over concrete classes.
In OO design, your objects should care about getting the job done regardless of the class. That's why you should prefer interacting with interfaces rather than classes. Interfaces will give you a greater number of objects that can fulfill a role because it's based on abilities. However, class must have the correct super class in it's class hierarchy to meet a requirement.
// in groovy language
interface Talkative {
void speak()
}
class Person {
speak(){
println("Where's my money?")
}
}
class Dog {
speak(){
println("woof! woof!")
}
}
def saySomething(Talkative thing){
thing.speak()
}
// :-( Doesn't work with Dog
def personSaySomething(Person person){
person.speak()
}
saySomething(new Person()) // prints where's my money!
saySomething(new Dog()) // prints woof! woof!
personSaySomething(new Person()) // prints where's my money!
personSaySomething(new Dog()) // Error! Dog isn't of class Person
Figure: Code 1.3
In the above code, you can see that the saySomething() method is more flexible then personSaySomething().
Review: 5/5 - Recommended
Pros:
+ Short and concise
+ Covers the popular SOLID principles
+ Straight forward and complete examples
Cons:
- It not about designing objects. For that you'll have to find a course over Object-oriented analysis and design (OOAD)
- More info:
Java Fundamentals: Object-oriented Design
Larry Battle
I love to program, and discover new tech. Check out my stackoverflow and github accounts.
Follow Me:
