Indecent Exposure

When a class or method exposes internal details to the public unnecessarily.

Sign of Smell

When a class or method unnecessarily exposes its internal details, this is referred to as indecent exposure, also known as excessive exposure. We should strive to keep everything private as much as possible. If a function is only used internally within its own class, there is no need for it to be public.

You may notice that this smell is very similar to Feature Envy and Inappropriate Intimacy. That's true because they are all related. "Feature Envy" refers to a method that excessively depends on another class, while "Inappropriate Intimacy" refers to a class that excessively depends on another class. Indecent Exposure is, in a way, the root cause of Feature Envy and Inappropriate Intimacy. If we solve the Indecent Exposure in one way, we might also solve the other two smells at the same time.

Reason of Smell

  • Law of Demeter: The Law of Demeter, also called the "principle of least knowledge," states that a class or a method should have limited knowledge of another class's internal structure. Indecent exposure occurs when a method or class excessively reveals its internal details to the public, rather than interacting through well-defined interfaces.

  • Lack of Encapsulation: Exposing internal details violates the principle of Encapsulation, which is essential for maintaining a clean and understandable codebase. Encapsulation hides complex internal implementation details and exposes only the necessary high-level interfaces. When you expose too much, it becomes harder to reason about the code because unnecessary implementation details are revealed.

  • Complexity: Exposing such code means that clients are aware of code that is either unimportant or only indirectly important. This adds to the complexity of a design.

  • High Coupling: When you expose internal details, it often leads to high coupling between different parts of the codebase. High coupling makes it difficult to change one part of the code without affecting other parts, increasing the risk of unintended side effects and making the code less maintainable.

  • Reduced Modifiability: Exposed details can become dependencies for other parts of the code. When you later need to modify the internal implementation or refactor the code, you may have to make changes in multiple places, increasing the likelihood of introducing bugs and making code maintenance more challenging.

  • Security Risks: Exposing too much can also pose security risks. If sensitive data or implementation details are accessible to unauthorized parts of the code or external entities, it can lead to vulnerabilities and potential breaches.

Refactoring Recipes

  • Encapsulate Classes with Factory

  • Encapsulate Field

  • Encapsulate Collection

Encapsulate Classes with Factory

Use a factory method or factory class to encapsulate the instantiation of objects. By this way, you can abstract away the concrete class and expose a more flexible and abstract interface.

Encapsulate Field

Use getter and setter methods to encapsulate access to fields, allowing you to control and validate access and modifications.

Encapsulate Collection

Use methods to encapsulate access and modification of the collection, allowing you to control and validate operations.

Reference

https://luzkan.github.io/smells/indecent-exposure

https://ducmanhphan.github.io/2020-01-10-Refactoring-couplers/#excessive-exposure

Last updated