DRY Principle: The Dos and Don'ts of Object-Oriented Design
DRY is all about code factorization
This article is the first in a series dedicated to good design practices. It addresses the DRY principle, which translates to "Don't Repeat Yourself". Even though the examples provided here are written in Java, the DRY principle is common to all programming languages.
Quick definition
As from the book “The pragmatic programmer” :
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
In other words, each business logic or algorithm must exist uniquely within an application.
Violations of DRY
Let us now examine some cases of violation of this principle in Java language.
Business logic duplication
In the code snippet below, the business logic of displaying an array of items is duplicated.
Don'ts
//Code with duplication
public void someMethodWithoutDRY1(String[] arr) {
// Perform some business treatments.....
// Display an array of strings on the screen
for (String stringValue : arr) {
System.out.println(stringValue + " ");
}
// Perform other business treatments...
}
public void someMethodWithoutDRY2(Integer[] arr) {
// Perform some business treatments.....
// Display an array of integers on the screen
for (Integer intValue : arr) {
System.out.println(intValue + " ");
}
// Perform other business treatments...
}
Do's
Here is the code after proper application of the DRY principle
//Without duplicated code
public void displayWithDRY(Object[] arr) {
// Display an array of objects on the screen
for (Object objectValue : arr) {
System.out.println(objectValue + " ");
}
}
public void someMethodWithDRY1(String[] arr) {
// Perform some business treatments.....
// Display an array of strings on the screen
displayWithDRY(arr);
// Perform other business treatments....
}
public void someMethodWithDRY2(Integer[] arr) {
// Perform some business treatments.....
// Display an array of integers on the screen
displayWithDRY(arr);
// Perform other business treatments...
}
Algorithm duplication
Let's now have a look at a situation where an algorithm is duplicated. In the code snippet below, the algorithm used to calculate the area of a rectangle is duplicated in both the Rectangle and the Square classes.
Don'ts
class Rectangle {
double width;
double length;
Rectangle(double width, double length) {
this.length = length;
this.width = width;
}
public double calculateArea() {
return width * length;
}
}
class Square {
double side;
Square(double side) {
this.side = side;
}
public double calculateArea() {
return side * side;
}
}
//Testing
public static void main(String[] args) {
Rectangle r = new Rectangle(2, 3);
Square s = new Square(2);
System.out.println(r.calculateArea()); // displays 6
System.out.println(s.calculateArea()); // displays 4
}
Let's see how to fix it.
Do's
We change the Square class as follows:
class SquareDRY extends Rectangle {
double side;
SquareDRY(double side) {
super(side, side);//invokes the superclass constructor Rectangle(double width, double length)
}
//No need to rewrite the calculateArea() method as it's inherited from the superclass
}
//Testing
public static void main(String[] args) {
Rectangle r = new Rectangle(2, 3);
Rectangle s = new SquareDRY(2);
System.out.println(r.calculateArea()); // displays 6
System.out.println(s.calculateArea()); // displays 4
}
Conclusion
In this quick article, we examine two cases of violation of the DRY principle: business logic duplication and algorithm duplication. For each of these cases, we have seen what to do and what not to do.
What are your thoughts about the DRY principle? Let us know in the comment section.
Ready to take your Java skills to the next level? Stay in the loop with our latest tutorials and courses by liking, commenting, and subscribing to our newsletter. If you found this helpful, consider supporting our work by buying us a coffee. Your support keeps us fueled to create more valuable content for you. Join our community of learners and let's grow together!
Subscribe to my newsletter
Read articles from Noel KAMPHOA directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Noel KAMPHOA
Noel KAMPHOA
I am a computer engineer with more than ten years of practice. I worked for almost 9 years as a consultant on payroll processing and salary calculation software. I have solid experience in setting up tax rules related to salary processing. I also have some experience in the banking field, with some banking system migration missions. I recently started writing because I have always had a passion for transmitting knowledge. I have been a mentor for several years on platforms like CodeMentor and Openclassrooms.