DEV Community

Cover image for Code Smell 267 - Objects Aliasing
Maxi Contieri
Maxi Contieri

Posted on • Originally published at maximilianocontieri.com

Code Smell 267 - Objects Aliasing

Favor immutability to retain control of your objects

TL;DR: Use immutable objects to prevent unexpected changes caused by aliasing.

Problems

  • Unexpected mutations
  • Difficult bug tracking
  • Unpredictable code behavior
  • Reduced code predictability
  • Increased coupling
  • Compromised thread safety

Solutions

  1. Use immutable objects
  2. Implement defensive copying
  3. Favor functional programming

Refactorings

Context

Aliasing happens when multiple references point to the same mutable object.

This can lead to unexpected changes in them when one part of the code modifies the object, affecting all references.

Immutable objects mitigate this risk by ensuring you cannot change their internal representation once you create an object.

Collection Aliasing is a notable example of this issue.

Sample Code

Wrong

public class Person {
  private String name; 
}

public void modifyPerson(Person person) {
  person.setName("Cosmo Kramer");
}

public static void main(String[] args) {
  Person p1 = new Person("Newman");
  Person p2 = p1; // p1 and p2 refer to the same object

  modifyPerson(p1);

  System.out.println(p1.name()); // Output: Cosmo Kramer
  System.out.println(p2.name()); // Output: Cosmo Kramer (unexpected)
}
Enter fullscreen mode Exit fullscreen mode

Right

public class ImmutablePerson {
  private final String name; 

  public ImmutablePerson(String name) {
    this.name = name; 
  } 
}

public ImmutablePerson withName(String newName) {
    return new ImmutablePerson(newName);
}

public static void main(String[] args) {
  ImmutablePerson p1 = new ImmutablePerson("Newman");
  ImmutablePerson p2 = p1; // p1 and p2 refer to the same object

  // Modifying p1 creates a new object
  ImmutablePerson p3 = p1.withName("Cosmo Kramer");
  // but this is a bad practice 
  // since only constructors should create new objects
  // A better option is
  ImmutablePerson p3 = new ImmutablePerson("Cosmo Kramer");

  System.out.println(p1.name()); // Output: Newman
  System.out.println(p2.name()); // Output: Newman
  System.out.println(p3.name()); // Output: Cosmo Kramer
}
Enter fullscreen mode Exit fullscreen mode

Detection

[X] Semi-Automatic

You can detect this smell by reviewing your code for mutable objects shared across different parts of your program.

Tags

  • Mutability

Level

[x] Intermediate

AI Generation

AI generators might introduce this smell if they're not specifically trained to prioritize immutability and avoid aliasing issues.

AI Detection

AI detectors identify this smell by analyzing code for mutable shared objects and suggesting immutable alternatives.

They need specific instructions on the context and the importance of immutability in the codebase.

Try Them!

Remember AI Assistants make lots of mistakes

ChatGPT Claude
Perplexity
Gemini

Conclusion

Using immutable objects and avoiding aliasing can significantly improve your code's predictability, reduces bugs, and improves thread safety.

It requires a shift in thinking and the benefits of immutability far outweigh the initial learning curve.

Relations

More Info

Disclaimer

Code Smells are my opinion.

Credits

Photo by Natural Photos on Unsplash


Immutability changes everything.

Pat Helland


This article is part of the CodeSmell Series.

Top comments (5)

Collapse
 
mcsee profile image
Maxi Contieri

as long as it creates immutable objetcts, Factory pattern is fine

Collapse
 
framemuse profile image
Valery Zinchenko

Is the "Immutable" prefix required part of a right code?

Collapse
 
mcsee profile image
Maxi Contieri

No. In fact is a code smell. All Objects should be immutable by default.

The example is here to show the differences