TL;DR: Don't abuse your friend objects.

Problems

• Coupling

• Low Reuse

• Low Testability

• Bad Responsibilities Assignment

• Bijection Fault

Solutions

1. Move the 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 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();
  }
}

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

• Refactoring Guru

• C2 Wiki

• Wikipedia

Credits

Photo by Hisu lee on Unsplash

---

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.