JavaFX: Implementando soluções com CDI

As linguagens de programação já evoluem ao longo de décadas de maneira a facilitar o trabalho executado pelo programador e, consequentemente, impacta positivamente na produtividade do desenvolvimento de software.

É possível afirmar que grande parte da evolução é alcançada à medida que estas linguagens se aproximam do mundo real e se tornam mais fáceis e intuitivas, deixando de ser uma linguagem puramente de máquina para se tornar uma linguagem humanamente compreensível.

Com base nesta máxima, as linguagens orientadas a objetos permitem que um sistema seja desenvolvido por meio de uma abstração do mundo real, onde entidades como uma pessoa ou um automóvel são representadas por objetos, e suas características e comportamentos pertinentes são evidenciados por atributos e métodos, respectivamente.

Mesmo que a orientação a objetos tenha levado a codificação a um nível mais próximo da realidade, durante o desenvolvimento de sistemas os programadores ainda se deparam com problemas parecidos, os quais são inerentes a este paradigma de programação.

Apesar disso, muitos desses problemas já foram catalogados em padrões de projeto. Assim, muitas vezes é necessário apenas reconhecer o problema, para então aplicar a solução conhecida.

Hoje já existem diversos padrões de projeto divulgados nos mais diferentes meios de publicação; é o caso dos padrões G.R.A.S.P. (General Responsibility Assignment Software Patterns), apresentados no artigo da Edição 129, ou os padrões GoF (Gang of Four), que são os mais conhecidos.

Neste ponto é válido ressaltar que diversos padrões de projeto são baseados no princípio de Hollywood (BOX 1), o qual acrescenta um desacoplamento maior entre as classes que desempenham um papel de coordenação da tarefa e as que apenas são coordenadas.

Deste modo, essas classes usuárias (ou coordenadas) não possuem conhecimento sobre o padrão implementado, pois são chamadas apenas para realizar uma pequena e específica porção do trabalho, ao passo que as classes que contemplam o padrão de projeto são responsáveis por chamar as classes coordenadas e orquestrar a comunicação entre elas para atingir o objetivo proposto.

A dinâmica entre esses objetos promove a divisão das tarefas em um trabalho colaborativo e coordenado.

Esta característica existe em alguns padrões de projeto, a exemplo do MVC e da própria Injeção de Dependências, e permite que as classes envolvidas trabalhem de forma coordenada, caracterizando-se então como um framework.

Por sua vez, um framework é um conjunto de classes relacionadas (ou API) que permitem ao programador a criação de pontos de extensão de acordo com a necessidade da aplicação.

Normalmente, estes pontos são representados por classes e objetos que implementam os requisitos funcionais do software, como telas ou entidades.

Assim, é possível observar esta característica em bibliotecas bem conhecidas como o Swing, onde as telas são criadas com o uso da API disponibilizada no JDK.

Dito isso, ressalta-se que o tema a ser abordado neste artigo está intimamente relacionado com os conceitos de framework e design patterns vistos até então, principalmente porque a injeção de dependências é também um padrão de projeto que visa atender um problema recorrente no desenvolvimento de sistemas orientados a objetos.

Também referenciada como Inversão de Controle (Inversion of Control – IoC), é a arte de fazer as “coisas” virem até você, como em um passe de mágica. Assim, o trabalho de um framework IoC é essencialmente criar objetos, verificar quais destes se relacionam e atribuir as respectivas instâncias a quem precisa delas ...