If your method is jealous and don't trust in delegation, you should start to do it.
TL;DR: Don't abuse your friend objects.
Problems
Coupling
Low Reuse
Low Testability
Bad Responsibilities Assignment
Bijection Fault
Solutions
- Move method to the appropriate class.
Sample Code
Wrong
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());
}
}
Right
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());
//We might even move this responsability 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();
}
}
Detection
Some linters can detect a sequential pattern of collaborations with another object.
Tags
- Coupling
Conclusion
- We should assign responsibilities according to real object mappers and avoid abusing other objects protocol.
Relations
More info
Credits
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
This article is part of the CodeSmell Series.
Top comments (2)
Shouldn't it be the address that does the printing?
It might be another envy, but it is clearly a chance