Cataloging Dependency Injection Anti-Patterns in Software Systems

TL;DR

This paper introduces a catalog of 12 Java Dependency Injection anti-patterns, validated through static analysis and practitioner surveys, aiming to improve code quality by guiding developers to avoid common DI pitfalls.

Contribution

The study proposes a comprehensive catalog of DI anti-patterns, develops a static analysis tool with high accuracy, and evaluates practitioner perceptions, filling gaps in practical understanding of DI anti-patterns.

Findings

At least 9 DI anti-patterns are common in analyzed projects.

The static analyzer achieved 92.19% recall and high precision.

Practitioners find the catalog relevant and are willing to refactor anti-patterns.

Abstract

Context: Dependency Injection (DI) is a commonly applied mechanism to decouple classes from their dependencies in order to provide higher modularization. However, bad DI practices often lead to negative consequences, such as increasing coupling. Although white literature conjectures about the existence of DI anti-patterns, there is no evidence on their practical relevance, usefulness, and generality. Objective: The objective of this study is to propose and evaluate a catalog of Java DI anti-patterns and associated refactorings. Methodology: We reviewed existing reported DI anti-patterns in order to analyze their completeness. The limitations found in literature motivated proposing a novel catalog of 12 DI anti-patterns. We developed a tool to statically analyze the occurrence level of the candidate DI anti-patterns in both open-source and industry projects. Next, we survey practitioners to assess their perception on the relevance, usefulness, and their willingness on refactoring anti-pattern instances of the catalog. Results: Our static code analyzer tool showed a relative recall of 92.19% and high average precision. It revealed that at least 9 different DI anti-patterns appeared frequently in the analyzed projects. Besides, our survey confirmed the perceived relevance of the catalog and developers expressed their willingness to refactor instances of anti-patterns from source code. Conclusion: The catalog contains Java DI anti-patterns that occur in practice and that are perceived as useful. Sharing it with practitioners may help them to avoid such anti-patterns, thus improving source-code quality.