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
:::
\
Welcome to Billionaire Club Co LLC, your gateway to a brand-new social media experience! Sign up today and dive into over 10,000 fresh daily articles and videos curated just for your enjoyment. Enjoy the ad free experience, unlimited content interactions, and get that coveted blue check verification—all for just $1 a month!
Account Frozen
Your account is frozen. You can still view content but cannot interact with it.
Please go to your settings to update your account status.
Open Profile Settings