Code Smell 266 – Collection Aliasing

Exposing your collections couples your solution

TL;DR: Use immutable collections to prevent unintended side effects.

Problems

Unpredictable behavior
Debugging challenges
Data corruption
Violation of the Principle of Least Astonishment
Premature optimization
Unexpected Mutations
Concurrency problems
Compromised thread safety
Increased coupling

Solutions

Use immutable collections
Create immutable classes
Copy the collection before modification
Avoid collection getters
Avoid automatic properties
Favor information hiding and encapsulation

Context

Aliasing happens when two or more variables refer to the same object.

This can lead to unexpected side effects, especially when one variable modifies the shared object.

You can’t change immutable collections after creation helping you prevent accidental aliasing.

Premature optimizators will argue that copying collections is an expensive operation that you should avoid.

This is a special case of Object Aliasing

Sample Code

Wrong

public class MutableExample {
public static void main(String[] args) {
List<Integer> numbers = List.of(1, 2, 3);
List<Integer> otherNumbers = numbers; // Aliasing
otherNumbers.add(4);
System.out.println(numbers); // Output: [1, 2, 3, 4]
}
}

Right

public class ImmutableExample {
public static void main(String[] args) {
List<Integer> numbers = List.of(1, 2, 3);
List<Integer> otherNumbers = List.copyOf(numbers); // Creating a copy
otherNumbers.add(4);
System.out.println(numbers); // Output: [1, 2, 3]
}
}

Detection

[x] Semi-Automatic

Several static analysis tools can warn you of aliasing abuse.

Tags

Immutability

Level

[x] Intermediate

AI Generation

AI code generators might not always create immutable objects by default, especially when working with mutable collections.

You can prompt them to prioritize immutable collections and wrap existing ones to avoid aliasing.

AI Detection

AI tools can analyze code for potential aliasing issues and suggest using immutable collections instead.

Conclusion

You can avoid unintended side effects using immutable collections.

This will make your code more predictable and easier to reason about.

Related Reading

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xviii

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxvi

https://hackernoon.com/finding-the-stinky-parts-of-your-code-code-smell-256-mutable-getters

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxii

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiv

More Info

https://hackernoon.com/is-it-crystal-clear-for-everybody-that-a-date-should-not-mutate-wuoy3z03?embedable=true

https://hackernoon.com/nude-models-part-ii-getters-sjo3ua2?embedable=true

https://hackernoon.com/coupling-the-one-and-only-software-designing-problem-9z5a321h?embedable=true

:::warning
Disclaimer: Code Smells are my opinion.

:::

:::info
Credits: Photo by Martino Pietropoli on Unsplash

:::

If an object is immutable, it can be in only one state, and you win big.

Joshua Bloch

https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true

:::tip
This article is part of the CodeSmell Series on HackerNoon: How to Find the Stinky Parts of your Code

:::

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.