[pt] Injeção de dependências, uma forma de inversão de controle, é uma forma de estruturar a configuração e composição de componentes de software que traz vários benefícios como um acoplamento reduzido entre componentes. No entanto, um framework genérico de injeção de dependências requer instrospecção em tempo de execução, o que explica por que injeção de dependências é popular em Java mas praticamente inexistente em C Mais Mais. Neste trabalho apresentamos um sistema de introspecção para C Mais Mais 11 e mostramos como ele pode ser usado para melhorar uma implementação de Service Component Architecture (SCA) para C Mais Mais. Usamos vários novas funcionalidades de C Mais Mais 11 como perfect forwarding, variadic templates e lvalue references para melhorar a usabilidade da API de reflexão e minimizar o overhead de execução. / [en] Dependency injection, a form of inversion of control, is a way of structuring the configuration and composition of software components that brings many benefits such as a loose coupling of components. However, a generic dependency injection framework requires runtime type introspection and this is why dependency injection is popular in Java and almost non-existent in C plus plus. In this work we present a introspection system for C plus plus 11 and show how to use it to improve an implementation of the Service Component Architecture (SCA) for C plus plus. It uses several features of C plus plus 11 such as perfect forwarding, variadic templates and lvalue references to improve usability and minimize overhead.

[pt] Contexto Injeção de Dependência (DI) é um mecanismo comumente aplicado para desacoplar classes de suas dependências com o objetivo de prover uma melhor modularização do software. No contexto de Java, a existência de uma especificação de DI e frameworks populares, como o Spring, facilitam o emprego de DI em projetos de software. Entretanto, más práticas de implementação de DI podem trazer más consequências, como maior acoplamento, dificultando alcançar o principal objetivo de DI. Apesar de a literatura sugerir a existência de anti-padrões de DI, não há uma documentação detalhada de tais más práticas. Em adição, não há evidência da ocorrência e da percepção de utilidade dos mesmos do ponto de vista de desenvovedores. Objetivos Nosso objetivo é revisar os anti-padrões de DI reportados com o objetivo de analisar sua completude e propor um novo catálogo de anti-padrões de DI para Java. Método Nós propomos um catálogo contendo 12 anti-padrões de DI para Java. Nós selecionamos 4 projetos open-source e 2 projetos closed-source que adotam um framework de DI e desenvolvemos uma ferramenta que analisa estaticamente a ocorrência dos anti-padrões de DI candidatos no código fonte das aplicações. Em adição, nós conduzimos uma pesquisa por meio de entrevistas face a face com três desenvolvedores experientes que regularmente aplicam DI em seus projetos. Nós estendemos a pesquisa com o objetivo de obter a percepção de um conjunto de 15 desenvolvedores experientes e novatos por meio de um questionário online Resultados Ao menos 9 anti-padrões de DI apareceram frequentemente nos projetos de software analisados. Em adição, a avaliação recebida dos desenvolvedores confirmaram a relevância do catálogo. Por fim, os respondentes expressaram o desejo de refatorar as instâncias de antipadrões de DI propostas. Conclusões O catálogo contém anti-padrões de DI que ocorrem na prática e são úteis. Compartilhar com praticantes da indústria os permitirá evitar a introdução de anti-padrões em seus projetos de software. / [en] Background Dependency Injection (DI) is a commonly applied mechanism to decouple classes from their dependencies in order to provide better modularization of software. In the context of Java, the availability of a DI specification and popular frameworks, such as Spring, facilitate DI usage in software projects. However, bad DI implementation practices can have negative consequences, such as increasing coupling, hindering the achievement of DI s main goal. Even though the literature suggests the existence of DI anti-patterns, there is no detailed documentation of such bad practices. Moreover, there is no evidence on their occurrence and perceived usefulness from the developer s point of view. Aims Our goal is to review the reported DI anti-patterns in order to analyze their completeness and to propose and evaluate a novel catalog of Java DI anti-patterns. Method We propose a catalog containing 12 Java DI anti-patterns. We selected 4 opensource and 2 closed-source software projects that adopt a DI framework and developed a tool to statically analyze the occurrence of the candidate DI anti-patterns within their source code. Also, we conducted a survey through face to face interviews with three experienced developers that regularly apply DI. We extended the survey in order to gather the perception of a set of 15 expert and novice developers through an online questionnaire. Results At least 9 different DI anti-patterns appeared frequently in the analyzed projects. In addition, the feedback received from the developers confirmed the relevance of the catalog. Besides, the respondents expressed their willingness to refactor instances of anti-patterns from source code. Conclusions The catalog contains Java DI anti-patterns that occur in practice and are useful. Sharing it with practitioners may help them to avoid such anti-patterns.