Provocação
coluna
Estamos preparados para
utilizar padrões?
Quais são as dificuldades na utilização de herança,
Qua
design patterns e frameworks
É inegável que o livro “Design Patterns” foi um marco para o mundo
da orientação para objetos. Ele atuou como um “concentrador”
dos padrões até então identificados, mas também teve em seus
capítulos iniciais discussões profundas sobre OO, que até hoje geram
polêmicas. Neste artigo será discutido um pouco destes tópicos
que são menos explorados, e levantamos aqui a polêmica: estamos
mesmo preparados para a orientação para objetos?
P odemos entender o livro “Design Patterns” como um livro
com dois modelos de leitura. A parte relativa aos patterns, a
partir da página 80, utiliza como um “i-ching” (uma espécie
de livro de conselhos oriental, tendo como principal característica ter
cada página totalmente independente das demais, com um conselho
isolado para aquele momento), no qual abrimos quando necessitamos
de um “conselho” de como implementar da melhor forma alguma parti-
cularidade em um código. Esta parte do livro vem extensamente sendo
explorada, com diversos artigos e exemplos. Até a página 80, por outro
lado, existe um rico texto explorando diversos aspectos da orientação
para objetos, que estaremos abordando neste artigo.
Um pouco de história
Os primórdios da OO remontam à década de 60. Vários livros memoráveis
foram escritos ao longo dos anos, de mestres como Beck e Winfs-Brock, Booch,
Rumbaugh, Yacobson, Meilir Jones, Fowler, Larman, entre muito outros. Várias
abordagens de notações foram criadas, como OMT, OOAD e UML. Várias me-
todologias também foram criadas e exploradas, como waterfall, fontain, ite-
rativo, incremental, componentizada, métodos ágeis. Para aqueles que ainda
têm dúvidas sobre a longevidade das linguagens OO, existiam compiladores
Smalltalk comerciais em 1969.
12 www.mundoj.com.br
Digital
Glauco dos Santos Reis
(glauco@portalbpm.com.br): é bacharel e mestrando
em Ciências da Computação. Trabalha com Java
desde 1996 e é especialista em orientação para
objetos, utilizando linguagens OO há mais de 20
anos (C++ e Java). Tem as certificações SCJP 1.1 e
1.5, SCWCD 1.4, e é certificado em Websphere pela
IBM. Atuou em dezenas de projetos e tem mais de
160 artigos publicados em revistas do segmento de
informática. É especialista em BPM e publicou um
livro sobre a notação BPMN (www.glaucoreis.com.
br). Também é mantenedor do site PortalBPM (www.
portalbpm.com.br), que trata dos assuntos SOA, BPM,
BPMS e CEP. Atua como arquiteto de sistemas na CPA
(www.cpaconsulting.com.br).
De forma geral, houve um longo período de maturação dos conceitos básicos
nas décadas de 70 e 80, unindo conceitos de vários autores, com a criação de
linguagens como C++, por Bjarne StrouStrup (1983) e chegando na década de
90 o nosso Java (começou ao Brasil em torno de 1997). Mas parece que ainda
faltava alguma peça para completar o quebra-cabeça.
Na década de 80 houve uma grande demanda por tecnologias componentiza-
das e ferramentas RAD, como Delphi e VB, que utilizavam conceitos de OO em
um encapsulamento mais “forte”. A ideia de peças de software (como existe
até hoje em hardware) na teoria traria grande produtividade na construção de
sistemas. Houve uma grande difusão de componentes, entre eles VBX, OCX
e vários outros. Na prática se observou grande produtividade na construção
de softwares através da reutilização de componentes prontos. A experiência
mostrou que os códigos gerados por tais ferramentas tinham uma qualidade
muito baixa, dificultando muito a manutenção. Ou seja, estas ferramentas RAD
tinham grande produtividade na criação, mais baixíssimo reaproveitamento
dos códigos além dos próprios componentes básicos utilizados na criação.
Esta grande produtividade em boa parte acontecia porque a maioria dos con-
ceitos de orientação para objetos eram implementados pelos componentes
(encapsulados), e muitos dos programadores em VB e Delphi programavam
orientado a componentes, ou seja, utilizavam as interfaces que os compo-
nentes expunham, junto com toda uma infraestrutura de drag and drop para
facilitar a interação. Na maioria dos casos estas interfaces eram comuns, com

propriedades e métodos (toda implementação de JavaBeans foi inspirada
neste conceito de componentes).
Claro que não podemos generalizar, já que vários programadores utilizavam
em profundidade a ferramenta. Mas a programação orientada a componentes
permitia que muitos outros programadores criassem códigos, sem a necessi-
dade de um grande conhecimento em OO.
Toda esta estrutura de componentes em torno de um paradigma visual de
drag and drop era um imenso framework de desenvolvimento. E por que não
deu certo?
Em minha opinião, na época não tínhamos ainda completo domínio de como
deveriam ser criados códigos com qualidade, nem padronização para tal. Cada
ferramenta “colava” os componentes de uma forma, e as informações neces-
sárias para manter esta “cola” também não eram padronizadas. Em resumo,
embora um componente VBX pudesse ser utilizado no Delphi sem problemas,
nenhum código do VB poderia ser utilizado diretamente no Delphi.
Recordo-me de ter utilizado bastante o
Visual Age for Java por toda sua existência,
e a produtividade na criação de programas
Swing era imensa. Tudo era feito através
de setas com conexão, inclusive passagem
de parâmetros, retorno dos métodos,
os parâmetros dos métodos e por aí vai.
Conforme os códigos iam sendo criados,
de forma totalmente visual e com altís-
sima produtividade (bem maior que a
obtida posteriormente com o Eclipse), um
monte de setas se amontoavam na tela.
Se você criasse blocos menores, o código
ficava com uma qualidade melhor, mas a
produtividade caia. Ainda existia o fato de
os mecanismos utilizados para manter as
representações visuais não serem padrão,
ou seja, quando foi necessário migrar para
outra ferramenta toda prototipação visual
se perdeu no processo.
O fato é que nos dias atuais, as ferramentas RAD, como as existentes na
década de 80, estão praticamente extintas. Ao final da década de 90, a
grande inovação foi o lançamento da linguagem Java. Sua grande ino-
vação não foi a orientação para objetos em si (na verdade ela era mais
limitada se comparada ao C++), mas tinha a vantagem de ser multi-
plataforma, o que “caía como uma luva” para o momento do mercado
corporativo.
Afinal, na época, se tinha uma imensa quantidade de hardwares de baixa
plataforma deixados pelo fracasso gerado pelo downsizing, ao lado dos
Mainframes que ainda não haviam sido migrados. Cada um deles com
suas linguagens e particularidades.
A consolidação da linguagem Java aconteceu com a criação e evolução
dos servidores de aplicações. É bem verdade que muitos devem se lem-
brar do início, com o “Duke” rodando na tela via applets, mas creio que
hoje em dia o mercado de applets está praticamente erradicado, ou tem
nichos muito específicos. A linguagem Java começou a ser vendável e
1SPWPDBÎÍP
%JHJUBM
t
&TUBNPT
QSFQBSBEPT
QBSB
VUJMJ[BS
QBESÜFT
se tornou sucesso quando foi adotada pelo mercado corporativo. Veja:
áreas de negócio não compram Java. O que o negócio precisa é uma
plataforma robusta para construção de aplicativos que permitam atingir
novos mercados com confiabilidade, que na linguagem da TI significam
servidores de aplicação rodando aplicativos Web Based. Estes servidores
de aplicação, na maioria das vezes, são baseados em J2EE, e Java segue
por tabela neste processo. E como os aplicativos Java/WEB utilizam prin-
cípios OO, normalmente a demanda por programadores OO é grande.
Na verdade, este foi um dos raros momen-
tos em que a TI entendeu de verdade o
que as áreas de negócio realmente neces-
sitavam (atingir novos mercados via Web).
No meu entendimento, Java, Orientação
para Objetos, e mais recentemente SOA
não têm significado para as áreas de negó-
cio, embora existam alguns “evangelistas”
insistindo em dizer que SOA é a tábua
de salvação para o negócio. Por mais que
eu goste de Java, é preciso admitir que
a tecnologia em si não é um argumento
vendável.
Retornando à evolução, creio que a peça que faltava eram metodologias
para desenvolvimento OO. Uma delas, que se originou de um termo
chamado de visão 4+1 e posteriormente gerou a RUP (Rational Unified
Process), foi originalmente publicado por Philip Krutchen, um dos pais
da RUP. Isto aconteceu quase ao mesmo tempo em que houve uma pa-
dronização das representações gráficas em torno do UML. Curiosamente
todos estes eventos (inclusive o lançamento do livro Design Patterns)
aconteceram entre 1994 e 1998. Foi um momento histórico de grande
profusão de conhecimento em torno da OO.
Mas estamos preparados para a Orientação
para Objetos?
Esta pergunta é bastante interessante, e como a revista Mundoj tem seu
foco em Java, que é uma linguagem orientada para objetos, imagino que
irá gerar revolta de um grupo de pessoas. Atualmente, mais de 80% dos
programas criados em Java se utilizam de frameworks para várias tarefas,
como Struts e JSF, para criação de aplicações web e Hibernate e JPA para
o mapeamento objeto-relacional. Estes frameworks “escondem” boa par-
te da complexidade OO, fazendo com que os programas muitas vezes se
reduzam à implementação de classes que se encaixam nos seus pontos
de extensão (leia nesta edição uma rica discussão sofre frameworks e OO
em “Herança e Composição – Os Princípios por Trás dos Padrões”).
Ou seja, hoje, podemos dizer que na maio-
ria das vezes não programamos orientado
para objetos na sua plenitude. O que faze-
mos é a criação de blocos de códigos que
rodam sobre frameworks (o que diminui
bastante o grau de complexidade).
13

Esta afirmação, um tanto “picante”, já estava entre as 70 páginas descritas nos
capítulos iniciais do GOF:
“Um framework dita a arquitetura da sua aplicação. Ele define a arquitetura de
forma geral, sua subdivisão em classes e objetos, a responsabilidade entre eles,
como os objetos colaboram. Um framework predefine estes padrões de desen-
volvimento para você. O desenvolvedor/implementador pode se concentrar
em detalhes da aplicação...”. GoF Pg 26.
Quase nunca pensamos sobre isto, mas a grande realidade é que o maior bene-
fício trazido pelo Struts, apenas para citá-lo como um framework de exemplo,
foi a criação de uma estrutura mais engessada para servir como base para o
desenvolvimento. Anteriormente, havia uma grande diversidade na criação de
códigos em aplicações web. Alguns utilizavam Servlets e classes de apoio para
fazer a renderização, outros criavam páginas JSP com helpers para incorporar
lógica. Mesmo com a existência de padrões (modelo 2 e modelo 3) ainda era
muito flexível. Os programadores ficavam pensando novas formas de codificar,
e perdiam o foco, que era o atendimento às regras do negócio.
“Você não apenas constrói suas aplicações mais rapidamente, mas as aplica-
ções têm estruturas similares. Eles são mais fáceis de manter, e parecem mais
consistentes para o usuário”. GoF Pg 27.
Isto significa que a padronização trazida por um framework facilita a manuten-
ção, já que as estruturas de codificação são muito similares.
Em resumo, na maioria das vezes, hoje em dia, não estamos programando
utilizando OO na sua plenitude. Criamos pequenos blocos de códigos que se
conectam (leia artigo nesta edição) e executam sobre frameworks, e muitos
programadores mais inexperientes não têm a noção da complexidade envol-
vida, embora sejam peritos na utilização do framework em si. Isto permite que
programadores que antes teriam grande dificuldade em desenvolver sistemas
Java consigam criar sistemas complexos, com grande foco nas necessidades
reais do sistema e pouquíssima preocupação com as complexidades da OO.
Se você é uma das pessoas que se julga capaz de utilizar todo o potencial
da linguagem, se aventure na construção de um framework. Para isso, um
bom começo é a leitura do artigo nesta edição 'Herança e Composição – Os
Princípios por Trás dos Padrões', que mostra como iniciar com a reutilização de
código”.
“Se aplicações são difíceis de desenvolver, e toolkits são ainda mais difíceis, os
frameworks são os mais difíceis de todos” Gof Pg 27
Veja esta frase que interessante:
“Grandes níveis de reuso são conseguidos por uma inversão de controle entre
a aplicação e o software no qual ele é baseado. Quando você utiliza um toolkit,
você escreve o código main e sua aplicação chama o código que deseja utilizar.
Quando você utiliza um framework, você reusa o método main e escreve o
código chamado. Você tem que escrever métodos com nomes particulares e
convenções, mas isto reduz as decisões de design que deveria fazer”. Pg 27.
Você poderia imaginar que esta frase foi retirada de algum livro do Rod John-
son (criador do Spring), mas já estava em 1995 no GOF. Entretanto, o Spring e
um melhor detalhamento destas ideias somente foram feitos em 2003. Levou
quase oito anos para que alguém conseguisse ler, compreender e criar algo
que utilizasse estes conceitos para construir algo compreensivo com esta frase
que estava no GOF.
Hoje, lendo a frase, ficamos lamentando porque não tivemos a ideia do Rod
14 www.mundoj.com.br
Provocação
Digital
Johnson, não é mesmo? Não precisamos ficar acanhados, já que visualizar e
entender estas coisas não é tarefa simples.
Toda a arquitetura J2EE é baseada na inversão de controle, ou seja, não me
chame que eu chamo você. Quando você cria um Servlet não é seu código
quem chama o Servlet. Os métodos da classe HTTPServlet (doGet,doPost e os
demais) são chamados e controlados pelo servidor de aplicações, que na es-
sência são implementações de frameworks. O mesmo acontece com EJB e JCA,
por exemplo. Nós não nos damos conta, mas não criamos mais os programas,
mas sim blocos de códigos que rodam em uma estrutura mais complexa.
Claro que hoje nosso foco de atenção é outro, como, por exemplo, gerar um
look and feel esperado pelo usuário, que está mais próximo das necessidades
e mais longe da TI. Raramente em um servidor de aplicações ficamos preocu-
pados com o número de acessos simultâneos, transações concorrentes e coisas
deste tipo.
Problemas até na JDK?
Acho que nada demanda maior grau de conhecimento em OO do que a
evolução da própria linguagem Java, certo? A linguagem deve ser uma pri-
mazia em termos orientação para objetos. Pois bem, veja a classe de pilha
(java.util.Stack). Uma pilha é uma LIFO (Last In First Out), o que significa
que elementos inseridos por último são os primeiros retirados, como uma
“pilha de pratos”. Se você observar no JavaDoc da classe, perceberá que
ela foi implementada como uma herança da classe Vector (java.util.Vector).
Em uma pilha, você nunca deve retirar os pratos que estão no meio, mas
como foi utilizada uma herança, a classe Vector permite acesso a qualquer
elemento de forma indistinta. Isto significa que embora uma pilha não
permita retirar elementos fora da ordem, os métodos públicos de Vector
permitem e, portanto, o objeto Stack não é robusto. Você pode facilmente
quebrar o Stack através de algumas chamadas a métodos de Vector. Até
hoje o problema não foi resolvido, embora novamente o livro encabeçado
por Erich Gamma tenha a resposta para a questão:
“Favoreça a composição de objetos sobre a herança de classes”. Pg 20.
Por sinal, este é o segundo princípio fundamental do design, proposto pelo
livro. A utilização de herança como mecanismo de reutilização de códigos
deve ser utilizada com muito critério e pode arrebentar com o encapsula-
mento se não for bem empregada. Isto pode ser exemplificado da seguinte
forma: imagine que você crie uma classe para uma necessidade sistêmica.
Em outra parte do código, você necessita de uma implementação ligeira-
mente diferente, e naturalmente herda da classe-base sua implementação.
Bom neste ponto todo o sistema está funcionando normalmente.
Mas se você necessitar alterar a classe-base (pai) para um novo compor-
tamento, este forte acoplamento entre as classes podem fazer com que
a classe-filha passe a se comportar de forma anômala. Ou seja, alterações
em classes externas não deveriam causar anomalias no comportamento
de uma classe. É claro que, se codificarmos da forma correta, este problema
nunca ocorreria na prática.
Como todos os métodos dos pais estão presentes nos filhos, instâncias
de objetos podem se comportar de forma inesperada. A solução para o
problema é utilizar uma composição somada a uma delegação ao invés
de herança.
Ao invés de utilizar herança como mecanismo de reaproveitamento, o ide-
al é criar uma instância dentro do objeto (composição) e reutilizá-la através

da chamada de métodos (o que é chamado de delegação). Você obtém
um maior controle na chamada de um método, e ainda o objeto sendo
reutilizado pode ser substituído durante a execução (o que significa maior
flexibilidade e controle).
Associando as frases anteriores ao exemplo citado, a classe Stack não de-
veria herdar de Vector, mas sem ter uma instância de objeto Vector privada
dentro de Stack. Quando fosse chamado um método do Stack, este “dele-
garia” a chamada para a instância de Vector, fazendo com que os métodos
que poderiam destruir a consistência do objeto não estivessem visíveis
para o usuário de Stack. Novamente a resposta está lá no GOF (Gang of
Four – como também é chamado o livro). Entretanto, apesar da impor-
tância da robustez necessária para um JDK, até hoje pequenos problemas
como este ainda existem na implementação.
Acho que, na verdade, o livro é mais enfático do que isto. Ele diz que
herança deveria ser utilizada como mecanismo de implementação de po-
limorfismo, e não como reaproveitamento de código. Ou seja, deveríamos
criar vários tipos de objetos sendo referenciados por uma mesma interface,
mas com implementações diferentes. O mecanismo que deveria ser utili-
zado para reaproveitamento é a composição somada à delegação, como
descrito acima. Quando utilizamos composição, o objeto que será utilizado
pode ser definido durante a execução. Com herança, o pai é definido no
momento da compilação e somente pode ser alterado recompilando os
códigos, o que torna o código menos flexível. Gof. Pg 21.
Iterativo e incremental atrapalhando
Quando utilizamos metodologias que fatiam as implementações, como
RUP (também poderia arriscar scrum), a tendência é criar códigos para
cada caso de uso (no caso da RUP) ou funcionalidade. Estes códigos
podem ser criados por vários grupos, e todo este processo incremental
pode dificultar a localização de padrões.
Entretanto, quanto mais extensiva é a aplicação de um padrão em um
projeto, maiores os benefícios em termos de reaproveitamento. Isto é
fácil de visualizar, já que um framework permeia toda uma aplicação,
e funciona como um grande conjunto de padrões em sinergia, o que
permite altos graus de produtividade.
Padrões não são fáceis de implementar, e quando utilizados em contex-
tos isolados costumam aumentar a complexidade e raramente trazem
benefícios em escala.
Se tivesse entrado no início deste projeto, duvido que tivesse a visibili-
dade ou mesmo a “inspiração” para chegar a decisão de selecionar um
padrão que permeasse todo o projeto. Na maioria das vezes, acabamos
selecionando nos projetos fórmulas prontas e frameworks de mercado,
de forma a não errarmos.
Cada vez mais novas metodologias obrigam a decisões mais rápidas,
tornando o processo de escolha pelas decisões mais sábias menos
importantes do que o respeito aos prazos extremamente reduzidos. E
como não há muito tempo para entendimentos iniciais, se perde oportu-
nidades de aplicar inovações na forma de padrões mais específicos que
aumentam produtividade ao projeto.
Ou seja, utilizamos no dia-a-dia o “feijão com arroz”, e quanto maior for
a pressão para entrega, menor o tempo para utilização da criatividade.
1SPWPDBÎÍP
%JHJUBM
t
&TUBNPT
QSFQBSBEPT
QBSB
VUJMJ[BS
QBESÜFT
Lembro-me de um projeto do qual participei,
mas que por particularidades do projeto fui
incorporado ao time quando vários casos de
uso já estavam prontos, e descreviam várias
partes do sistema. Analisando estes casos
de uso, acabamos descobrindo que havia
em comum entre todos eles um comporta-
mento de navegação em uma árvore, e uma
vez localizado um elemento em particular,
algo era efetuado (um elemento inserido,
removido, valores eram acumulados etc.).
A decisão foi implementar uma árvore que
era navegada através de um pattern visitor,
com comandos específicos para cada execu-
ção. Como era sempre o mesmo código de
visita a cada nó da árvore, a complexidade
do sistema se reduziu à implementação de
comandos (implementação do padrão Com-
mand) que efetuavam as diversas operações
do sistema.
Padrões reinventados
Ainda parece que existe uma gana para
encontrar novos padrões, mesmo que
estes novos padrões sejam os velhos pa-
drões renomeados.
Após o surgimento do GOF, vários livros surgiram explorando padrões de
desenvolvimento, sendo talvez os mais famosos o “Core J2EE Patterns” de
Deepak Alur et all e “EJB Design Patterns” – Floyd Marinescu. Vários livros
com dezenas ou mesmo centenas de patterns foram lançados, mas a maio-
ria foi reinvenção de algo existente.
A coisa mais importante do pattern é sua semântica. Uma palavra deve
servir de comunicação entre dois programadores. Se lhe digo para imple-
mentar um singleton, provavelmente vêm a sua mente todo um trecho
de código que indica o que deve ser feito. Sem a definição do padrão, a
informação precisaria ser repassada entre as equipes repetidas vezes.
Sugiro que leia o excelente livro “Core J2EE Patterns”, que também tem
capítulos que exploram arquiteturas de construção em camadas para apli-
cativos Web. Neste livro, existem padrões que me passam a percepção de
já estarem documentados antes no GOF. Existe, por exemplo, um padrão
descrito como “Composite View”. A ideia é criar visualizações mais com-
plexas a partir de composições de blocos mais simples. Absolutamente
inovador, mas idêntico ao pattern descrito como Composite no GOF. Claro,
não era aplicado especificamente à arquitetura Web, mas na verdade seria
possível fazer uma analogia com o exemplo de editor de textos explorado
durante todo o livro (chamado Lexi).
O pattern “Session Façade” descrito no Core J2EE também é idêntico ao “Fa-
çade” do GOF. Também existe o pattern “DAO” (Data Access Object), que no
Core J2EE é um padrão que permite tornar um objeto em algo persistente,
que pode ser uma base de dados, flat file ou qualquer outro mecanismo.
15

Pois bem, esta é exatamente a finalidade do Memento do GOF, que permi-
te externalizar o estado de um objeto para posterior reutilização.
Estes livros foram escritos por especialistas do segmento, e talvez o grande
objetivo fosse o de apresentar os mesmos padrões em contextos diferen-
tes, com o objetivo de tornar clara a utilização, em contextos mais especí-
ficos. Talvez fosse interessante não modificar os nomes originais, apenas
apresentando novas utilizações, pois a semântica é algo muito importante
em um padrão.
Novas experiências e distorções na OO
As linguagens mais novas vêm fazendo experiências, que de certa forma exer-
citam variações dos princípios fundamentais da OO e podem gerar resultados
positivos ou negativos. Outro dia um colega estava me mostrando um recurso
da linguagem Ruby (que é orientada para objetos), que segundo as palavras
dele “era algo muito legal”. A linguagem permite que novos métodos sejam de-
finidos dinamicamente, durante a execução e apenas para algumas instâncias
de objetos. Ou seja, você tem dentro de um mesmo código, objetos de uma
mesma classe, cada um deles com comportamentos e métodos diferentes.
Bem, minha opinião, sobre essa funcionalidade é: "a coisa mais louca que já
vi na minha vida". Vai contra todos os princípios da orientação para objetos, e
se o objetivo do polimorfismo é criar clareza no código, através de famílias de
objetos similares, este recurso cria objetos iguais, mas na realidade diferentes,
o que é muito complicado de se gerenciar na prática.
O polimorfismo permite que tenhamos classes diferentes com uma mesma
“interface”, ou conjunto de métodos, de forma que cada uma delas poderá ter
implementações de comportamentos diferentes. Isto permite tratar objetos de
tipos diferentes de uma mesma forma. O que está se propondo é exatamente
o inverso do polimorfismo. Ou seja, objetos do mesmo tipo, alguns com mé-
todos e outros sem o método. Será que alguém poderia me dizer como se usa
isto de forma segura? Estas experimentações podem gerar colapsos inacredi-
táveis nos códigos futuros.
Mas já que estamos falando de padronização, algumas características do
Ruby, especialmente em aplicações Ruby on Rails, são muito interessantes.
Por exemplo, são gerados padrões de diretórios para os códigos criados, com
repetições de nomes, o que torna seu uso muito intuitivo. Qualquer um que
observa a estrutura de diretórios entende muito facilmente.

DSJBOEP
TVB
QSØQSJB
CBTF
EF
DPOIFDJNFOUPt

Mas vamos fazer um retrospecto: não foi exatamente isto que aconteceu com
o Java? A linguagem foi criada a partir do C++, com a premissa de ser uma
linguagem mais simples. Elementos como unions, enumerations, structs, tipos
parametrizados foram retirados da linguagem. O Java foi uma simplificação

3JDIBSE
)FMN

3BMQI
+PIOTPO
F
+PIO
7MJTTJEFT
tremenda do C++, com classes e tipos básicos apenas. Tudo se encaixava em
uma destas categorias. Quem participou desta época relembra como foi uma
migração para algo mais simples.
E mesmo com esta simplicidade foi possível surgirem servidores de aplicação
muito complexos em funcionalidade. Precisávamos mesmo de toda esta evo-
lução?
Atualmente a linguagem incorporou uma série de novos recursos, muitos
deles para competir com a evolução do C#, o que pode ser visto como uma
evolução ou uma "involução", já que o complexo ficou simples, e agora volta
gradualmente a se tornar complexo de novo. Foi engraçado ver as pessoas
comemorarem a criação dos tipos parametrizados como uma grande novida-
de, sendo que já existia desde o início em C++, inclusive com uma biblioteca
16 www.mundoj.com.br
Provocação
Digital
própria (STL). Torço para que algum dia alguém não tenha a ideia magnífica de
implementar macrosubstituição em Java, como existe em C++, que torna o
código incompreensível e sujeitos a nichos de programação.
Nem tudo está perdido
Existem movimentos no sentido de uma aproximação maior entre as
áreas técnicas e de negócios. Mais precisamente, uma aproximação no
sentido da área técnica para a área de negócios.
Entre elas podemos destacar Domain Driven Design e as soluções BPMS
(Business Process Management Systems). Hoje se tem um gradual retorno
ao entendimento de que o mais importante é que qualquer que seja a
tecnologia criada, ela deve simplificar as atividades técnicas no sentido de
manter o foco nas necessidades dos clientes, ao invés de obscurecer com
particularidades que dificultam aos programadores inexperientes o enten-
dimento destes conceitos. Este tipo de conceito, apesar de parecer óbvio,
levou um grande tempo de maturação para chegarmos aos dias atuais.
Considerações finais
Estes exemplos mostram que a atividade de ser criativo na construção de
um sistema OO é mais próxima de uma arte do que dependente de técnica.
Afinal, textos como a obra de arte Design Patterns permaneceram por anos
com vários conceitos que apenas anos depois a comunidade tem maturi-
dade de compreender e adotar. Também me parece que existe um grande
esforço na tentativa de tornar os conceitos de OO como algo “engessado” nos
projetos, numa clara tentativa de tornar massificado o acesso de tecnologias
OO a um grupo maior de pessoas. Movimentos no sentido de agregar mais
e mais funcionalidades na linguagem podem aumentar a complexidade,
reduzindo o grupo de pessoas com acesso à tecnologia.
Apesar de tudo, temos conseguido grande evolução no entendimento e
utilização destes conceitos todos, e este conhecimento está sendo utilizado
de forma a simplificar o acesso à tecnologia.
Hoje a orientação para objetos já é uma disciplina em cursos de graduação,
e não um trabalho para ser criado nas férias escolares. Os muitos frameworks
vêm fazendo os programadores e arquitetos a refletir vantagens de uma
BCPSEBHFN
PV
PVUSB
Referências
%FTJHO
1BUUFSOT

o

&SJDI
(BNNB
Core J2EE Patterns – Deepak Alur, John Crupi e Dan Malks
EJB Design Patterns Floyd Marinescu
Expert One-on-One J2EE Design and Development – Rod Johnson
Fundamentos do desenho orientado para objetos – Meilir Page Jones
Applying UML and Patterns – Craig Larman
Object Oriented Analysis and design – Grady Booch
IUUQNBSUJOGPXMFSDPNBSUJDMFTJOKFDUJPOIUNM
&ODBQTVMBUJPO
BOE
*OIFSJUBODF
JO
0CKFDU0SMFOUFE
1SPHSBNNJOH
-BOHVBHFT
o

IUUQXXXDTDPMPSBEPFEV_EJXBODMBTTQBQFSTTOZEFSQEG
"Se sentiu provocado? Discordou de algum ponto de vista? Res-
ponda as provocações! Envie um e-mail para artigos@mundoj.
com.br com um texto contendo sua contra-argumentação que
ele poderá ser publicado em uma de nossas próximas edições."