If your method is jealous and doesn't trust in delegation you should start to do it.
TL;DR: Don't abuse your friend objects.
-
Coupling
-
Low Reuse
-
Low Testability
-
Bad Responsibilities Assignment
-
Bijection Fault
The One and Only Software Design Principle
- Move the method to the appropriate class.
class Candidate {
void printJobAddress(Job job) {
System.out.println("This is your position address");
System.out.println(job.address().street());
System.out.println(job.address().city());
System.out.println(job.address().ZipCode());
}
}
class Job {
void printAddress() {
System.out.println("This is your job position address");
System.out.println(this.address().street());
System.out.println(this.address().city());
System.out.println(this.address().ZipCode());
// You might even move this responsibility directly to the address!
// Some address information is relevant to a job
// and not for package tracking
}
}
class Candidate {
void printJobAddress(Job job) {
job.printAddress();
}
}
Some linters can detect a sequential pattern of collaborations with another object.
- Coupling
- We should assign responsibilities according to real object mappers and avoid abusing other objects' protocol.
Code Smell 89 - Math Feature Envy
Code Smell 191 - Misplaced Responsibility
Code Smell 64 - Inappropriate Intimacy
We argue that design practices which take a data-driven approach fail to maximize encapsulation because they focus too quickly on the implementation of objects. We propose an alternative object-oriented design method which takes a responsibility-driven approach.
Rebecca Wirfs-Brock
Software Engineering Great Quotes
This article is part of the CodeSmell Series.