Paradigmas das Aplicações Corporativas

Fui apresentado a esse termo recentemente. Lógico que já ouvi falar em aplicação corporativa, mas agora estou comprometido a desenvolver um sistema desses.

A empresa onde estou trabalhando montou uma equipe para ter uma área pioneira em desenvolvimento de sistemas corporativos.

Meu mundo caiu e estou acordando em outro, completamente diferente. O foco mudou.

Antes, no meu ponto de vista, o desenvolvedor sentava com o cliente, ouvia suas necessidades e montava o programa conforme o entendimento do problema.

Ainda nesse cenário, o programador não tinha códigos prontos e nenhuma facilidade. O próprio desenvolvedor analisava as necessidades do cliente, montava a estrutura do programa e ainda codificava e testava a aplicação.

Esse cenário mudou. Hoje em dia, o desenvolvedor recebe do arquiteto a aplicação pré-montada. Em rápidas reuniões técnicas sobre problemas específicos, o arquiteto e o desenvolvedor alinham o entendimento geral do projeto e seguem em frente.

Nesse novo cenário, o cliente nem sabe da existência do programador. E este ainda conta com muitas facilidades, como frameworks específicos para abstrair partes complicadas de se fazer na mão. Resumindo, o programador hoje em dia tem muitos blocos de código prontos para utilizar em sua programação, facilitando assim o que chamamos de "trabalho sujo" ou ainda "trabalho pesado".

Um exemplo disso é o NHibernate. Este framework se propõem a montar todas as querys SQL para você, independente do banco de dados que você utiliza, seja ele Sql Server, Oracle, MySql etc.

Isso facilita muito as coisas, pois basta mapear as tabelas do banco em um formato específico do NHibernate e criar classes que representam as tabelas dentro da aplicação, e o framework cuida do resto.

Mas não pára por aqui. Existem ainda programas como o MyGeneration que auxiliam na criação de códigos repetitivos. Através de templates programados pelo próprio desenvolvedor, ou mesmo baixados da internet, podemos criar arquivos de mapeamento e classes inteiras com apenas alguns cliques.

Resumindo mais uma vez, hoje em dia basta você ter bons templates para implementação de código repetitivo, alguns frameworks para fazer o trabalho sujo e voilá: você pode se tornar um ótimo programador!

Veja que com essa mudança na forma de programar, mudou também o foco da aplicação. A programação não é mais voltada para o objeto, para o método ou mesmo para o evento. Agora é voltada para o aspecto da aplicação, ou para o serviço a ser prestado, para o domínio do negócio, ou ainda para os testes de sistema.

Isso mesmo, o objeto não é mais o foco do problema. Foi natural durante um tempo que a programação orientada a objetos permanecesse como motivo de preocupação. É realmente difícil aprender orientação a objetos. A curva de aprendizado no início é muito íngreme. Leva-se muito tempo para começar a desenvolver alguma coisa até pegar o jeito.

Mas o tempo foi passando e os desenvolvedores foram ficando habituados a esse tipo de programação. Isso fez com que o foco mudasse, ou seja a preocupação mudasse. Já que não era mais segredo desenvolver aplicações orientadas ao objeto, qual era a preocupação então?

Isolar os objetos em contâiners. Imagine que você tem um objeto muito valioso e delicado. Por exemplo um lenço para limpar os olhos. Se este lenço cair em uma poça de lama, como você vai separar a lama do lenço de forma que ele fique novamente apto para limpar seus olhos?

Esse é o problema com os objetos. Muitos deles estão tão acoplados e tão dependentes uns dos outros que não podem ser separados e reaproveitados em outros projetos. De repente esses objetos não ficam mais tão atraentes. Para que serve um objeto se eu não posso utilizá-lo mais de uma vez, em outros programas?

É a mesma coisa com o lenço. Mas qual a solução? Bom, para o lenço, o ideal seria que você pudesse colocar a maior parte do lenço dentro de um invólucro e selá-lo, deixando apenas uma ponta do lenço para fora. Dessa forma apenas essa parte do lenço ficaria exposta para se acoplar com a lama. Você então teria cumprido seu objetivo de sujar o lenço de lama sem estragá-lo de vez, pois boa parte do lenço ainda está limpa.

Seguindo essa mesma idéia do lenço, os objetos gerados pelos programadores também devem ser encapsulados e isolados. Assim bastaria acoplar conectores cabíveis para cada aplicação que necessitasse deste objeto. Temos então um objeto reutilizável!

Com essa idéia em mente as grandes empresas descobriram ser um grande negócio agrupar estes objetos com propósitos em comum, em grandes pacotes chamados de frameworks. Esses pacotes são aplicações inteiras com o único propósito de servir de plataforma para o desenvolvimento da sua aplicação.

Na verdade tudo isso que estou escrevendo define a quebra do paradigma relatada pelo pattern Separation of Concerns (Separação de Preocupações). Ultrapassada essa etapa, podemos dar atenção a outros problemas, como partes do sistema que transcendem as camadas e os objetos.

Um exemplo disso é o Log (rastro), pois um sistema de rastreamento ultrapassa as camadas da aplicação e dos objetos. Se não tomarmos cuidado, esse Log pode ficar tão acoplado com as classes a ponto de torná-las totalmente dependentes e incapazes de funcionar sozinhas em outros sistemas.

Chegamos então a outro paradigma: Inversão de Controle!

Aguardem novos capítulos!
Renato Graccula