Qual √© o estado da sua arte? 

Sep/09
25
O estado da sua arte
√Č comum ouvir algu√©m perguntar qual “arquitetura” usar para uma certa aplica√ß√£o,
ou se usa o Spring junto com o JSF e Hibernate é uma boa escolha, ou como
acessar store procedures pelo hibernate. Esta escolha de frameworks é chamada
de “escolha da arquitetura” e diferentes pacotes de escolhas s√£o referidos como
“arquiteturas” e ouvimos falar que a “arquitetura com Spring √© melhor que com EJB”.
√ďbviamente por consequencia a pessoa que decide que pacote usar √© chamado de arquiteto.
Pode ser chocante ,ent√£o, para estas pessoas, saber que essas coisas n√£o
s√£o arquiteturas e que nada disso tem a haver com arquitetura e sim com design.
Infelizmente na lingua portuguesa a palavra design não tem uma boa tradução. O mais semelhante
seria desenho, mas em português isso se confunde com desenho Рforma de escrita (que em inglês
√© draw). Design Patterns √© traduzido para Padr√Ķes de Projeto porque Padr√Ķes de Desenho
não pareceu apelar às massas. Então, a bem da exactidão vou utilizar a palavra design
e n√£o traduzi-la, tal como se faz em artes gr√°ficas.
Se escolher este tipo de frameworks e tecnologia não é arquitetura , então o que é?
Ao fazer isto a pessoa está implicitamente escolhendo a sua plataforma de aplicação.
A Plataforma de Aplicação é um conjunto de classes, baseados na Plataforma Virtual,
que mediam entre as classes próprias da aplicação e as classes próprias das tecnologias utlizadas na arquitetura. Por exemplo,
se a arquitetura decide que um sistema web é que vamos fazer isso implica Рem java Рutilizar
um web container e programar tecnologias baseadas na Servlet API. Mas a Servlet API pura
não é muito produtiva. Então escolhe-se, ou faz-se, um conjunto de classes que isolam/encapsulam
o uso desta API de forma que a programação seja de mais alto nivel que a utilização directa
de uma API base. Nesta situação pode não existir muita vantagem Рà primeira vista Рmas estamos,
implicitamente, escolhendo a nossa Plataforma de Aplicação.
Lamentávelmente é raro que alguem pense e escolha a Plataforma de Aplicação de forma
consciente e explicita. E é aqui que nascem os problemas.
O pradigma de OO é suposto levar à reutilização. A reutilização mais importante
é a reutilização de objetos do dominio porque são eles que contêm as regras da aplicação.
O resto dos objetos apenas existe para que esta teutilização seja possivel isolando toda e
qualquer dependencia entre as classes do dominio e as classes da tecnologia subjacente.
√Č porque este isolamento n√£o existe na maioria esmagadora das aplica√ß√Ķes que n√£o vemos
aplica√ß√Ķes serem migradas de web para swing distribuido ou vice-versa. N√£o ha migra√ß√£o, ha re-escrita.
Uma Plataforma de Aplicação bem desenhada pode salvar a sua empresa de re-escrever e retestar o
mesmo produto infinitas vezes. E como seria uma plataforma de aplicação bem desenhada ?
Dizer que basta seguir os principios de orientação a objetos é verdade, mas parece pouco.
√Č mais f√°cil entender que os objetos que voc√™ quer reutilizar n√£o podem depender de
objetos da tecnologia subjacente. A forma de fazer isso é criar um conjunto de interfaces
que mediam a comunicação entre o dominio e a tecnologia subjacente.
um exemplo clássico é manipular o objeto HttpServletRequest directamente. Ora isto, por si só,
cria uma dependencia com a Servlets API impossibilitando que essa classe seja utilizada
fora de um web container. Isto é ruim para a evolução do seu sistema, mas começa sendo
um empecilho para o teste automático das suas classes e da sua aplicação. Utilizar uma interface
que esconde o objeto HttpServletRequest é a solução ideal. Se estivermos dentro
de um servlet container o HttpServletRequest será encapsulado nessa interface agnóstica
e se tivermos fora uma outra implementação da mesma interface será passada.
A ideia é isolar todas as classes da tecnologia subjacente. Com isto você já pode começar
a pensar em mudar da Servlet API pura para a JSF, por exemplo. Se apenas uma interface n√£o
é abstração suficiente, continue abstraindo até que as duas tecnologias possam ser tratadas
da mesma forma.
Ter uma Plataforma de Aplicação que pode evoluir sozinha e em separado da aplicação
é essencial para a evolução e longividade da aplicação. Se você quer que sua aplicação
sobreviva mais do que três anos você precisa disto. Repare que o custo de
manter uma plataforma de aplicação atualizada e afinada pode até ser o mesmo
re-escrever a aplicação toda a vez, mas o esforço é muito, muito, menor.
Um exemplo simples disto pode ser entendido imaginando um sistema classico de cadastro
pela web ( um micro ERP por exemplo). Em muitos locais é preciso utilizar um
campo de data. Vc usa um objeto input do HTML e algum javascript para
criar uma mascara. Agora alguem pede para internacionalizar essa data para que ela possa
ser colocada conforme a localização do usuário e além disso quer colocar um calendário drop down.
Ok, você vai em todas as páginas que tem input de data e altera scripts e HTML, página a página,
campo a campo, para o novo formato e lógica. Simples, certo ? Simples, mas extremanente chato,
tedioso, propenso a erros e completamente fora do conceito de componentização e reaproveitamento.
Outro cen√°rio, seria vc ter definido uma tag costumizada para insers√£o de data. No primeiro tempo
ela simplesmente renderiza um objeto input do HTML. No segundo, ela renderiza o input e controla
o drop down do calendário, a internacionalização, e até a validação. Quantas páginas vc alterou?
Nenhuma. O esforço é muitissimo menor. Porquê ? Porque você criou um isolamento
entra a necessidade da aplicação (colocar um campo data) e a tecnologia usada para isso (
renderizar um campo data com drop down de calend√°rio). Se agora alguem pedir
para renderizar usando três combobox de escolha de dia,mês e ano, o esfoço será linear com a vantagem
de manter a estratégia anterior. Na primeira opção seria quadrático e sem essa opção.
Criar e manter uma Plataforma de Aplicação não é simples e pode consumir os recursos
do seu projeto. Mas por outro lado,uma Plataforma de Aplicação bem desenhada pode ser
reaproveitada para outros projetos diluindo os custos de a manter e aumentando a sua
efic√°cia. Para empresas que produzem software como negocio core, manter esta plataforma
n√£o √© apenas bom, √© essencial. √Č o maior asset da empresa. Nele est√£o contidos conhecimentos
das v√°rias pessoas que passaram pela empresa, as decis√Ķes feitas contra adversidades encontradas
na realidade em dezenas de projetos. Nela est√° a competividade da empresa no mercado face
à sua concorrência. E a longo prazo ela reduz custos de manutenção e evolução.
Imagine aplica√ß√Ķes criada em java 1.4 que n√£o utilizam os beneficios de algo simples como a classe
Executor e em vez disso têm uma implementação in-house. Não é dificil aceitar que essa implementação
seja incompleta e cheia de m√°s decis√Ķes de design e at√© de programa√ß√£o. Contudo, se essa implementa√ß√£o
foi colocada atrás de uma interface, é muito fácil plugar uma implementação que use Executor
quando a aplicação está rodando numa JVM mais recente. E hoje, isso é uma realidade porque
java 1.4 não têm suporte oficial há anos. Contudo muita gente ainda usa porque a sua Plataforma
de Aplicação não está preparada para evoluir com baixo esforço. Ela está ultrapassada pelo estado-da-arte.
Se você é dono ou responsável por uma software house, ou por um produto de software que visa
estar no mercado por muitos anos e competir com a concorrência você precisa de uma Plataforma
de Aplicação. Se você é desenvolvedor, você precisa entender o que é uma Plataforma de Aplicação
e como construir uma. Escolher os frameworks certos √© apenas o primeiro passo…
Se você acha que já sabe criar uma Plataforma de Aplicação, pense se ela é capaz de se adaptar e tirar
proveito das novas classes adicionadas a cada vers√£o do java, de novos frameworks e de novas
tecnologias e tendencias. Pense no estado da sua arte. Por exemplo, qual o esforço para incluir
ajax na sua aplica√ß√£o ? E para incluir componentes avan√ßados como cheked lists, tabs, anima√ß√Ķes,
mensagens, quantidades e data localizadas conforme o usu√°rio … Como o seu estado de arte
vai aproveitar as inova√ß√Ķes do Java 7 ? Como ele vai lidar com a descontinua√ß√£o do Java 5 ?
E mais importante que tudo : quanto isso lhe vai custar ?

√Č comum ouvir algu√©m perguntar qual “arquitetura” usar para uma certa aplica√ß√£o,¬†ou se usar o Spring junto com o JSF e Hibernate √© uma boa escolha, ou como¬†acessar store procedures pelo hibernate. Esta escolha de frameworks √© chamada¬†de “escolha da arquitetura”, e diferentes pacotes de escolhas s√£o referidos como¬†“arquiteturas”. Por isso, ouve-se falar que a “arquitetura com Spring √© melhor que com EJB”.

Obviamente, por consequência, a pessoa que decide que pacote usar é chamado de arquiteto.

Pode ser chocante, ent√£o, para estas pessoas, saber que essas coisas n√£o s√£o arquiteturas e que nada disso tem a ver com arquitetura, mas sim com design.

Infelizmente na l√≠ngua portuguesa a palavra “design” n√£o tem uma boa tradu√ß√£o. O mais semelhante¬†seria desenho, mas em portugu√™s isso se confunde com desenho – forma de escrita (que em ingl√™s¬†√© draw). Design Patterns √© traduzido para Padr√Ķes de Projeto porque Padr√Ķes de Desenho n√£o pareceu apelar √†s massas. Ent√£o, a bem da exatid√£o ,vou utilizar a palavra design¬†e n√£o traduzi-la, tal como se faz em artes gr√°ficas.

Se escolher este tipo de frameworks e tecnologia não é arquitetura, então o que é?  Ao fazer isto a pessoa está implicitamente escolhendo a sua plataforma de aplicação. A Plataforma de Aplicação é um conjunto de classes, baseados na Plataforma Virtual, que mediam entre as classes próprias da aplicação e as classes próprias das tecnologias utlizadas na arquitetura. Por exemplo, se a arquitetura decide que um sistema web é que vamos fazer isso implica Рem java Рutilizar um web container e programar tecnologias baseadas na Servlet API. Mas a Servlet API pura não é muito produtiva. Então escolhe-se, ou faz-se, um conjunto de classes que isolam/encapsulam o uso desta API, de forma que a programação seja de mais alto nível que a utilização direta de uma API base. Nesta situação pode não existir muita vantagem Рà primeira vista Рmas estamos, implicitamente, escolhendo a nossa Plataforma de Aplicação.

Lamentavelmente, é raro que alguém pense e escolha a Plataforma de Aplicação de forma consciente e explícita. E é aqui que nascem os problemas.

O paradigma de OO é suposto levar à reutilização. A reutilização mais importante é a reutilização de objetos do domínio porque são eles que contêm as regras da aplicação. O resto dos objetos apenas existem para que esta reutilização seja possível isolando toda e qualquer dependência entre as classes do domínio e as classes da tecnologia subjacente.

Por conta deste isolamento n√£o existir na maioria esmagadora das aplica√ß√Ķes √© que n√£o vemos¬†aplica√ß√Ķes serem migradas de web para swing distribu√≠do ou vice-versa. N√£o h√° migra√ß√£o, h√° re-escrita.

Uma Plataforma de Aplicação bem desenhada pode salvar a sua empresa de re-escrever e retestar o mesmo produto infinitas vezes. E como seria uma plataforma de aplicação bem desenhada? Dizer que basta seguir os princípios de orientação a objetos é verdade, mas parece pouco.

√Č mais f√°cil entender que os objetos que voc√™ quer reutilizar n√£o podem depender de objetos da tecnologia subjacente. A forma de fazer isso √© criar um conjunto de interfaces¬†que mediam a comunica√ß√£o entre o dom√≠nio e a tecnologia subjacente. Um exemplo cl√°ssico √© manipular o objeto HttpServletRequest directamente. Ora isto, por si s√≥,¬†cria uma depend√™ncia com a Servlets API, impossibilitando que essa classe seja utilizada¬†fora de um web container. Isto √© ruim para a evolu√ß√£o do seu sistema, mas come√ßa sendo¬†um empecilho para o teste autom√°tico das suas classes e da sua aplica√ß√£o. Utilizar uma interface¬†que esconde o objeto HttpServletRequest √© a solu√ß√£o ideal. Se estivermos dentro¬†de um servlet container o HttpServletRequest ser√° encapsulado nessa interface agn√≥stica¬†e se tivermos fora uma outra implementa√ß√£o da mesma interface ser√° passada.

A ideia é isolar todas as classes da tecnologia subjacente. Com isto você já pode começar a pensar em mudar da Servlet API pura para a JSF, por exemplo. Se apenas uma interface não é abstração suficiente, continue abstraindo até que as duas tecnologias possam ser tratadas da mesma forma.

Ter uma Plataforma de Aplicação que pode evoluir sozinha e em separado da aplicação é essencial para a evolução e longividade da aplicação. Se você quer que sua aplicação sobreviva mais do que três anos você precisa disto. Repare que o custo de manter uma plataforma de aplicação atualizada e afinada pode até ser o mesmo re-escrever a aplicação toda a vez, mas o esforço é muito, muito, menor. Um exemplo simples disto pode ser entendido imaginando um sistema clássico de cadastro  pela web ( um micro ERP por exemplo). Em muitos locais é preciso utilizar um campo de data. Você usa um objeto input do HTML e algum javascript para criar uma máscara. Agora alguém pede para internacionalizar essa data para que ela possa ser colocada conforme a localização do usuário e além disso quer colocar um calendário drop down. Ok, você vai em todas as páginas que tem input de data e altera scripts e HTML, página a página, campo a campo, para o novo formato e lógica. Simples, certo? Simples, mas extremanente chato, tedioso, propenso a erros e completamente fora do conceito de componentização e reaproveitamento. Outro cenário, seria você ter definido uma tag costumizada para insersão de data. No primeiro tempo, ela simplesmente renderiza um objeto input do HTML. No segundo, ela renderiza o input e controla o drop down do calendário, a internacionalização, e até a validação. Quantas páginas você alterou? Nenhuma. O esforço é muitíssimo menor. Por quê? Porque você criou um isolamento  entre a necessidade da aplicação (colocar um campo data) e a tecnologia usada para isso (renderizar um campo data com drop down de calendário). Se agora alguém pedir para renderizar usando três combobox de escolha de dia, mês e ano, o esfoço será linear com a vantagem de manter a estratégia anterior. Na primeira opção seria quadrático e sem essa opção.

Criar e manter uma Plataforma de Aplica√ß√£o n√£o √© simples e pode consumir os recursos¬†do seu projeto. ¬†Mas por outro lado, uma Plataforma de Aplica√ß√£o bem desenhada pode ser¬†reaproveitada para outros projetos diluindo os custos de a manter e aumentando a sua¬†efic√°cia. Para empresas que produzem software como neg√≥cio core, manter esta plataforma¬†n√£o √© apenas bom, √© essencial. √Č o maior asset da empresa. Nele est√£o contidos conhecimentos¬†das v√°rias pessoas que passaram pela empresa, as decis√Ķes feitas contra adversidades encontradas¬†na realidade em dezenas de projetos. Nela est√° a competividade da empresa no mercado face¬†√† sua concorr√™ncia. E a longo prazo ela reduz custos de manuten√ß√£o e evolu√ß√£o.

Imagine aplica√ß√Ķes criada em java 1.4 que n√£o utilizam os beneficios de algo simples como a classe¬†Executor e em vez disso t√™m uma implementa√ß√£o in-house. N√£o √© dificil aceitar que essa implementa√ß√£o¬†seja incompleta e cheia de m√°s decis√Ķes de design e at√© de programa√ß√£o. Contudo, se essa implementa√ß√£o foi colocada atr√°s de uma interface, √© muito f√°cil plugar uma implementa√ß√£o que use Executor¬†quando a aplica√ß√£o est√° rodando numa JVM mais recente. E hoje, isso √© uma realidade porque¬†java 1.4 n√£o t√™m suporte oficial h√° anos. Contudo, muita gente ainda usa porque a sua Plataforma¬†de Aplica√ß√£o n√£o est√° preparada para evoluir com baixo esfor√ßo. Ela est√° ultrapassada pelo estado-da-arte.

Se voc√™ √© dono ou respons√°vel por uma software house, ou por um produto de software que visa estar no mercado por muitos anos e competir com a concorr√™ncia voc√™ precisa de uma Plataforma¬†de Aplica√ß√£o. Se voc√™ √© desenvolvedor, voc√™ precisa entender o que √© uma Plataforma de Aplica√ß√£o¬†e como construir uma. Escolher os frameworks certos √© apenas o primeiro passo…

Se voc√™ acha que j√° sabe criar uma Plataforma de Aplica√ß√£o, pense se ela √© capaz de se adaptar e tirar¬†proveito das novas classes adicionadas a cada vers√£o do java, de novos frameworks e de novas¬†tecnologias e tendencias. Pense no estado da sua arte. Por exemplo, qual o esfor√ßo para incluir¬†ajax na sua aplica√ß√£o? E para incluir componentes avan√ßados como cheked lists, tabs, anima√ß√Ķes,¬†mensagens, quantidades e data localizadas conforme o usu√°rio … Como o seu estado de arte vai aproveitar as inova√ß√Ķes do Java 7 ? Como ele vai lidar com a descontinua√ß√£o do Java 5 ?¬†E mais importante que tudo: quanto isso lhe vai custar ?

2 comentários para “Qual √© o estado da sua arte?”

  1. Parabéns cara, seu artigo ficou muito bom.
    Saber o qu√£o vol√°til √© um conte√ļdo, e em que camada ele vai ser colocado, e que interfaces ele vai ter, √© muito importante chave para uma arquitetura decente.

    Escolher frameworks realmente n√£o √© arquitetura, √© simplesmente escolher subs√≠dios para uma arquitetura j√° definida. Os frameworks lhe ajudam porque de certa forma de “induzem” a boas pr√°ticas da arquitetura – como voc√™ disse – isolamento do que √© aplica√ß√£o, e o que √© dom√≠nio do problema.

    Mais uma vez, parab√©ns ūüôā

  2. Gostei do artigo. √Č inspirador. Parab√©ns.

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos