Michel Zanini

No link about do site do spring é possível encontrar os objetivos propostos pelos desenvolvedores do framework:

1. J2EE should be easier to use
2. It is best to program to interfaces, rather than classes. Spring reduces the complexity cost of using interfaces to zero.
3. JavaBeans offer a great way of configuring applications.
4. OO design is more important than any implementation technology, such as J2EE.
5. Checked exceptions are overused in Java. A framework shouldn’t force you to catch exceptions you’re unlikely to be able to recover from.
6. Testability is essential, and a framework such as Spring should help make your code easier to test.

Gostaria de comentar o meu ponto de vista sobre cada um dos pontos levantados:

1. Na época em que o framework surgiu, em meados de 2003, desenvolver aplicações J2EE era uma tarefa árdua. Para reduzir essa complexidade, o Spring trouxe o conceito de POJO programming Model. Segundo esse modelo o desenvolvedor não é obrigado a implementar ou estender nenhuma classe, de nenhum framework ou API. Toda infra-estrutura necessária é realizada de forma transparente e não intrusiva. O Spring também trouxe o conceito de Template, uma classe que implementa o desing pattern Template Method. Os templates do Spring são usados para evitar o chamado “boilerplate code” (código repetitivo), como a utilização de API’s JDBC, JPA, JMS, JNDI, e etc. Os templates reduzem drasticamente a quantidade de código necessário. Somado a isso tudo, ainda temos as vantagens da utilização de injeção de dependências. Portanto, pós Spring, acredito que o Java EE se tornou muito mais simples.
2. Esse item é uma prática muito importante da programação OO. O Spring facilita a utilização de interfaces, pois não é necessário escrever a inicialização da classe concreta (operador new), é possível injetar a dependência em um objeto o qual dependerá apenas da interface.
3. Como mencionado no item um, o Spring trouxe o conceito de POJO programming Model pois isso simplifica muito a aplicação. É simples para qualquer iniciante entender a idéia de “JavaBean” e saber programá-la.
4. Esse é o item mais importante de todos em minha opinião. A programação OO deve prevalecer SEMPRE em relação a qualquer tecnologia utilizada, independente de quem a criou. Se você está utilizando EJB 2.x e eles te obrigam a criar código não OO, pense novamente. Procure os frameworks que são menos intrusivos o possível. Essa é a nova tendência que está sendo seguida por todos os projetos. Por exemplo: o Struts 2.x não depende mais da API de Servlets. O JUnit 4.x não necessita mais implementar uma super classe, pode-se utilizar anotações. Os “backing beans” do JSF são POJO’s. No EJB 3.x também não é mais necessário implementar interfaces, ou estender classes. E assim por diante. Essa abordagem facilita a aplicação de testes de unidade, e mais importante, facilita a posterior migração de API’s/tecnologias de forma menos traumática. O Spring é muito bom nesse ponto. O código fonte do framework é EXTREMAMENTE orientado a objetos e, é sempre possível utilizar seus recursos sem depender de suas classes.
5. Mais um item importantíssimo. Varias API’s feitas dentro do JDK ou JEE foram muito mal projetadas. O tratamento correto de exceções é raramente bem feito por programadores Java, pois se utiliza muito de exceções checadas. Em certos casos, como um acesso JDBC, não há muito o que uma aplicação possa fazer ao receber uma SQLException. O mesmo para RemoteException obrigatória em uma interface RMI, essa ainda mais danosa, pois fixa o cliente a conhecer a origem remota do objeto, dificultando a programação OO. O Spring criou para cada Template uma hierarquia de exceções não checadas. Assim, os métodos dos templates sempre lançam a exceção correta, e mais específica, sendo que você não é obrigado a criar nenhum bloco try-catch. Por exemplo, num código JDBC você pode, se quiser tratar uma exceção de integridade referencial, fazer um catch por “DataIntegrityViolationException” e o catch só será executado sobre essas condições. Bem melhor do que tentar “traduzir” uma SQLException.
6. Como comentado no item quatro. Aplicando uma boa programação orientada a objetos e utilizando frameworks não intrusivos, o código fica simples de testar. Um POJO é sempre facilmente testável. Com elaboração de testes de unidade seu código ficará muito mais confiável e trará uma economia de tempo e dinheiro, por pegar os maiores BUG’s ainda em etapa de desenvolvimento.

Um ponto não mencionado, que também gostaria de destacar, são as vantagens de trazer a Programação Orientada a Aspectos (AOP) para o dia a dia do desenvolvedor. A AOP ainda é pouco conhecida pelo usuário final e isso é um fato lamentável. Acredito que a AOP é uma grande ferramenta disponível a um desenvolvedor, e o Spring traz esse “poder” de forma prática e integrada.

Em um próximo post vou falar sobre os Templates disponíveis no Spring e qual a idéia básica por trás deles. Também irei voltar a falar sobre POJO Programming Model e unit testing.

Abraços,

Michel Zanini.