Вы находитесь на странице: 1из 5

Provocação

coluna Digital

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”
Glauco dos Santos Reis
dos padrões até então identificados, mas também teve em seus (glauco@portalbpm.com.br): é bacharel e mestrando
capítulos iniciais discussões profundas sobre OO, que até hoje geram em Ciências da Computação. Trabalha com Java
desde 1996 e é especialista em orientação para
polêmicas. Neste artigo será discutido um pouco destes tópicos objetos, utilizando linguagens OO há mais de 20
que são menos explorados, e levantamos aqui a polêmica: estamos anos (C++ e Java). Tem as certificações SCJP 1.1 e
1.5, SCWCD 1.4, e é certificado em Websphere pela
mesmo preparados para a orientação para objetos? 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).

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 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
de livro de conselhos oriental, tendo como principal característica ter 90 o nosso Java (começou ao Brasil em torno de 1997). Mas parece que ainda
cada página totalmente independente das demais, com um conselho faltava alguma peça para completar o quebra-cabeça.
isolado para aquele momento), no qual abrimos quando necessitamos
Na década de 80 houve uma grande demanda por tecnologias componentiza-
de um “conselho” de como implementar da melhor forma alguma parti-
das e ferramentas RAD, como Delphi e VB, que utilizavam conceitos de OO em
cularidade em um código. Esta parte do livro vem extensamente sendo
um encapsulamento mais “forte”. A ideia de peças de software (como existe
explorada, com diversos artigos e exemplos. Até a página 80, por outro até hoje em hardware) na teoria traria grande produtividade na construção de
lado, existe um rico texto explorando diversos aspectos da orientação sistemas. Houve uma grande difusão de componentes, entre eles VBX, OCX
para objetos, que estaremos abordando neste artigo. 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
Um pouco de história mostrou que os códigos gerados por tais ferramentas tinham uma qualidade
muito baixa, dificultando muito a manutenção. Ou seja, estas ferramentas RAD
Os primórdios da OO remontam à década de 60. Vários livros memoráveis tinham grande produtividade na criação, mais baixíssimo reaproveitamento
foram escritos ao longo dos anos, de mestres como Beck e Winfs-Brock, Booch, dos códigos além dos próprios componentes básicos utilizados na criação.
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- Esta grande produtividade em boa parte acontecia porque a maioria dos con-
todologias também foram criadas e exploradas, como waterfall, fontain, ite- ceitos de orientação para objetos eram implementados pelos componentes
rativo, incremental, componentizada, métodos ágeis. Para aqueles que ainda (encapsulados), e muitos dos programadores em VB e Delphi programavam
têm dúvidas sobre a longevidade das linguagens OO, existiam compiladores orientado a componentes, ou seja, utilizavam as interfaces que os compo-
Smalltalk comerciais em 1969. 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

12 www.mundoj.com.br
1SPWPDBÎÍP%JHJUBMt&TUBNPTQSFQBSBEPTQBSBVUJMJ[BSQBESÜFT

propriedades e métodos (toda implementação de JavaBeans foi inspirada se tornou sucesso quando foi adotada pelo mercado corporativo. Veja:
neste conceito de componentes). á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
Claro que não podemos generalizar, já que vários programadores utilizavam novos mercados com confiabilidade, que na linguagem da TI significam
em profundidade a ferramenta. Mas a programação orientada a componentes servidores de aplicação rodando aplicativos Web Based. Estes servidores
permitia que muitos outros programadores criassem códigos, sem a necessi-
de aplicação, na maioria das vezes, são baseados em J2EE, e Java segue
dade de um grande conhecimento em OO.
por tabela neste processo. E como os aplicativos Java/WEB utilizam prin-
Toda esta estrutura de componentes em torno de um paradigma visual de cípios OO, normalmente a demanda por programadores OO é grande.
drag and drop era um imenso framework de desenvolvimento. E por que não
deu certo?
Na verdade, este foi um dos raros momen-
Em minha opinião, na época não tínhamos ainda completo domínio de como tos em que a TI entendeu de verdade o
deveriam ser criados códigos com qualidade, nem padronização para tal. Cada que as áreas de negócio realmente neces-
ferramenta “colava” os componentes de uma forma, e as informações neces- sitavam (atingir novos mercados via Web).
sárias para manter esta “cola” também não eram padronizadas. Em resumo, No meu entendimento, Java, Orientação
embora um componente VBX pudesse ser utilizado no Delphi sem problemas, para Objetos, e mais recentemente SOA
nenhum código do VB poderia ser utilizado diretamente no Delphi. não têm significado para as áreas de negó-
cio, embora existam alguns “evangelistas”
insistindo em dizer que SOA é a tábua
Recordo-me de ter utilizado bastante o de salvação para o negócio. Por mais que
Visual Age for Java por toda sua existência, eu goste de Java, é preciso admitir que
e a produtividade na criação de programas a tecnologia em si não é um argumento
Swing era imensa. Tudo era feito através vendável.
de setas com conexão, inclusive passagem
de parâmetros, retorno dos métodos, Retornando à evolução, creio que a peça que faltava eram metodologias
os parâmetros dos métodos e por aí vai. para desenvolvimento OO. Uma delas, que se originou de um termo
Conforme os códigos iam sendo criados, chamado de visão 4+1 e posteriormente gerou a RUP (Rational Unified
de forma totalmente visual e com altís- Process), foi originalmente publicado por Philip Krutchen, um dos pais
sima produtividade (bem maior que a da RUP. Isto aconteceu quase ao mesmo tempo em que houve uma pa-
obtida posteriormente com o Eclipse), um dronização das representações gráficas em torno do UML. Curiosamente
monte de setas se amontoavam na tela. todos estes eventos (inclusive o lançamento do livro Design Patterns)
Se você criasse blocos menores, o código aconteceram entre 1994 e 1998. Foi um momento histórico de grande
ficava com uma qualidade melhor, mas a profusão de conhecimento em torno da OO.
produtividade caia. Ainda existia o fato de
os mecanismos utilizados para manter as Mas estamos preparados para a Orientação
representações visuais não serem padrão,
ou seja, quando foi necessário migrar para para Objetos?
outra ferramenta toda prototipação visual
Esta pergunta é bastante interessante, e como a revista Mundoj tem seu
se perdeu no processo.
foco em Java, que é uma linguagem orientada para objetos, imagino que
irá gerar revolta de um grupo de pessoas. Atualmente, mais de 80% dos
O fato é que nos dias atuais, as ferramentas RAD, como as existentes na programas criados em Java se utilizam de frameworks para várias tarefas,
década de 80, estão praticamente extintas. Ao final da década de 90, a como Struts e JSF, para criação de aplicações web e Hibernate e JPA para
grande inovação foi o lançamento da linguagem Java. Sua grande ino- o mapeamento objeto-relacional. Estes frameworks “escondem” boa par-
vação não foi a orientação para objetos em si (na verdade ela era mais te da complexidade OO, fazendo com que os programas muitas vezes se
limitada se comparada ao C++), mas tinha a vantagem de ser multi- reduzam à implementação de classes que se encaixam nos seus pontos
plataforma, o que “caía como uma luva” para o momento do mercado de extensão (leia nesta edição uma rica discussão sofre frameworks e OO
corporativo. em “Herança e Composição – Os Princípios por Trás dos Padrões”).

Afinal, na época, se tinha uma imensa quantidade de hardwares de baixa


plataforma deixados pelo fracasso gerado pelo downsizing, ao lado dos Ou seja, hoje, podemos dizer que na maio-
Mainframes que ainda não haviam sido migrados. Cada um deles com ria das vezes não programamos orientado
suas linguagens e particularidades. para objetos na sua plenitude. O que faze-
mos é a criação de blocos de códigos que
A consolidação da linguagem Java aconteceu com a criação e evolução
rodam sobre frameworks (o que diminui
dos servidores de aplicações. É bem verdade que muitos devem se lem-
bastante o grau de complexidade).
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

13
Provocação
Digital

Esta afirmação, um tanto “picante”, já estava entre as 70 páginas descritas nos Johnson, não é mesmo? Não precisamos ficar acanhados, já que visualizar e
capítulos iniciais do GOF: entender estas coisas não é tarefa simples.

“Um framework dita a arquitetura da sua aplicação. Ele define a arquitetura de Toda a arquitetura J2EE é baseada na inversão de controle, ou seja, não me
forma geral, sua subdivisão em classes e objetos, a responsabilidade entre eles, chame que eu chamo você. Quando você cria um Servlet não é seu código
como os objetos colaboram. Um framework predefine estes padrões de desen- quem chama o Servlet. Os métodos da classe HTTPServlet (doGet,doPost e os
volvimento para você. O desenvolvedor/implementador pode se concentrar demais) são chamados e controlados pelo servidor de aplicações, que na es-
em detalhes da aplicação...”. GoF Pg 26. 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,
Quase nunca pensamos sobre isto, mas a grande realidade é que o maior bene- mas sim blocos de códigos que rodam em uma estrutura mais complexa.
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 Claro que hoje nosso foco de atenção é outro, como, por exemplo, gerar um
desenvolvimento. Anteriormente, havia uma grande diversidade na criação de look and feel esperado pelo usuário, que está mais próximo das necessidades
códigos em aplicações web. Alguns utilizavam Servlets e classes de apoio para e mais longe da TI. Raramente em um servidor de aplicações ficamos preocu-
fazer a renderização, outros criavam páginas JSP com helpers para incorporar pados com o número de acessos simultâneos, transações concorrentes e coisas
lógica. Mesmo com a existência de padrões (modelo 2 e modelo 3) ainda era deste tipo.
muito flexível. Os programadores ficavam pensando novas formas de codificar,
e perdiam o foco, que era o atendimento às regras do negócio. Problemas até na JDK?
“Você não apenas constrói suas aplicações mais rapidamente, mas as aplica- Acho que nada demanda maior grau de conhecimento em OO do que a
ções têm estruturas similares. Eles são mais fáceis de manter, e parecem mais evolução da própria linguagem Java, certo? A linguagem deve ser uma pri-
consistentes para o usuário”. GoF Pg 27. 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
Isto significa que a padronização trazida por um framework facilita a manuten-
que elementos inseridos por último são os primeiros retirados, como uma
ção, já que as estruturas de codificação são muito similares.
“pilha de pratos”. Se você observar no JavaDoc da classe, perceberá que
Em resumo, na maioria das vezes, hoje em dia, não estamos programando ela foi implementada como uma herança da classe Vector (java.util.Vector).
utilizando OO na sua plenitude. Criamos pequenos blocos de códigos que se Em uma pilha, você nunca deve retirar os pratos que estão no meio, mas
conectam (leia artigo nesta edição) e executam sobre frameworks, e muitos como foi utilizada uma herança, a classe Vector permite acesso a qualquer
programadores mais inexperientes não têm a noção da complexidade envol- elemento de forma indistinta. Isto significa que embora uma pilha não
vida, embora sejam peritos na utilização do framework em si. Isto permite que permita retirar elementos fora da ordem, os métodos públicos de Vector
programadores que antes teriam grande dificuldade em desenvolver sistemas permitem e, portanto, o objeto Stack não é robusto. Você pode facilmente
Java consigam criar sistemas complexos, com grande foco nas necessidades quebrar o Stack através de algumas chamadas a métodos de Vector. Até
reais do sistema e pouquíssima preocupação com as complexidades da OO. hoje o problema não foi resolvido, embora novamente o livro encabeçado
por Erich Gamma tenha a resposta para a questão:
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 “Favoreça a composição de objetos sobre a herança de classes”. Pg 20.
bom começo é a leitura do artigo nesta edição 'Herança e Composição – Os
Por sinal, este é o segundo princípio fundamental do design, proposto pelo
Princípios por Trás dos Padrões', que mostra como iniciar com a reutilização de
livro. A utilização de herança como mecanismo de reutilização de códigos
código”.
deve ser utilizada com muito critério e pode arrebentar com o encapsula-
“Se aplicações são difíceis de desenvolver, e toolkits são ainda mais difíceis, os mento se não for bem empregada. Isto pode ser exemplificado da seguinte
frameworks são os mais difíceis de todos” Gof Pg 27 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-
Veja esta frase que interessante: mente diferente, e naturalmente herda da classe-base sua implementação.
Bom neste ponto todo o sistema está funcionando normalmente.
“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, Mas se você necessitar alterar a classe-base (pai) para um novo compor-
você escreve o código main e sua aplicação chama o código que deseja utilizar. tamento, este forte acoplamento entre as classes podem fazer com que
Quando você utiliza um framework, você reusa o método main e escreve o a classe-filha passe a se comportar de forma anômala. Ou seja, alterações
código chamado. Você tem que escrever métodos com nomes particulares e em classes externas não deveriam causar anomalias no comportamento
convenções, mas isto reduz as decisões de design que deveria fazer”. Pg 27. de uma classe. É claro que, se codificarmos da forma correta, este problema
nunca ocorreria na prática.
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 Como todos os métodos dos pais estão presentes nos filhos, instâncias
um melhor detalhamento destas ideias somente foram feitos em 2003. Levou de objetos podem se comportar de forma inesperada. A solução para o
quase oito anos para que alguém conseguisse ler, compreender e criar algo problema é utilizar uma composição somada a uma delegação ao invés
que utilizasse estes conceitos para construir algo compreensivo com esta frase de herança.
que estava no GOF.
Ao invés de utilizar herança como mecanismo de reaproveitamento, o ide-
Hoje, lendo a frase, ficamos lamentando porque não tivemos a ideia do Rod al é criar uma instância dentro do objeto (composição) e reutilizá-la através

14 www.mundoj.com.br
1SPWPDBÎÍP%JHJUBMt&TUBNPTQSFQBSBEPTQBSBVUJMJ[BSQBESÜFT

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
Lembro-me de um projeto do qual participei,
reutilizado pode ser substituído durante a execução (o que significa maior
mas que por particularidades do projeto fui
flexibilidade e controle).
incorporado ao time quando vários casos de
Associando as frases anteriores ao exemplo citado, a classe Stack não de- uso já estavam prontos, e descreviam várias
veria herdar de Vector, mas sem ter uma instância de objeto Vector privada partes do sistema. Analisando estes casos
dentro de Stack. Quando fosse chamado um método do Stack, este “dele- de uso, acabamos descobrindo que havia
garia” a chamada para a instância de Vector, fazendo com que os métodos em comum entre todos eles um comporta-
que poderiam destruir a consistência do objeto não estivessem visíveis mento de navegação em uma árvore, e uma
para o usuário de Stack. Novamente a resposta está lá no GOF (Gang of vez localizado um elemento em particular,
Four – como também é chamado o livro). Entretanto, apesar da impor- algo era efetuado (um elemento inserido,
tância da robustez necessária para um JDK, até hoje pequenos problemas removido, valores eram acumulados etc.).
como este ainda existem na implementação. A decisão foi implementar uma árvore que
era navegada através de um pattern visitor,
Acho que, na verdade, o livro é mais enfático do que isto. Ele diz que com comandos específicos para cada execu-
herança deveria ser utilizada como mecanismo de implementação de po- ção. Como era sempre o mesmo código de
limorfismo, e não como reaproveitamento de código. Ou seja, deveríamos visita a cada nó da árvore, a complexidade
criar vários tipos de objetos sendo referenciados por uma mesma interface, do sistema se reduziu à implementação de
mas com implementações diferentes. O mecanismo que deveria ser utili- comandos (implementação do padrão Com-
zado para reaproveitamento é a composição somada à delegação, como mand) que efetuavam as diversas operações
descrito acima. Quando utilizamos composição, o objeto que será utilizado do sistema.
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. Padrões reinventados

Iterativo e incremental atrapalhando


Ainda parece que existe uma gana para
Quando utilizamos metodologias que fatiam as implementações, como encontrar novos padrões, mesmo que
RUP (também poderia arriscar scrum), a tendência é criar códigos para estes novos padrões sejam os velhos pa-
cada caso de uso (no caso da RUP) ou funcionalidade. Estes códigos drões renomeados.
podem ser criados por vários grupos, e todo este processo incremental
pode dificultar a localização de padrões. 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
Entretanto, quanto mais extensiva é a aplicação de um padrão em um Deepak Alur et all e “EJB Design Patterns” – Floyd Marinescu. Vários livros
projeto, maiores os benefícios em termos de reaproveitamento. Isto é com dezenas ou mesmo centenas de patterns foram lançados, mas a maio-
fácil de visualizar, já que um framework permeia toda uma aplicação, ria foi reinvenção de algo existente.
e funciona como um grande conjunto de padrões em sinergia, o que
permite altos graus de produtividade. A coisa mais importante do pattern é sua semântica. Uma palavra deve
servir de comunicação entre dois programadores. Se lhe digo para imple-
Padrões não são fáceis de implementar, e quando utilizados em contex- mentar um singleton, provavelmente vêm a sua mente todo um trecho
tos isolados costumam aumentar a complexidade e raramente trazem de código que indica o que deve ser feito. Sem a definição do padrão, a
benefícios em escala. informação precisaria ser repassada entre as equipes repetidas vezes.

Se tivesse entrado no início deste projeto, duvido que tivesse a visibili- Sugiro que leia o excelente livro “Core J2EE Patterns”, que também tem
dade ou mesmo a “inspiração” para chegar a decisão de selecionar um capítulos que exploram arquiteturas de construção em camadas para apli-
padrão que permeasse todo o projeto. Na maioria das vezes, acabamos cativos Web. Neste livro, existem padrões que me passam a percepção de
selecionando nos projetos fórmulas prontas e frameworks de mercado, já estarem documentados antes no GOF. Existe, por exemplo, um padrão
de forma a não errarmos. descrito como “Composite View”. A ideia é criar visualizações mais com-
plexas a partir de composições de blocos mais simples. Absolutamente
Cada vez mais novas metodologias obrigam a decisões mais rápidas, inovador, mas idêntico ao pattern descrito como Composite no GOF. Claro,
tornando o processo de escolha pelas decisões mais sábias menos não era aplicado especificamente à arquitetura Web, mas na verdade seria
importantes do que o respeito aos prazos extremamente reduzidos. E possível fazer uma analogia com o exemplo de editor de textos explorado
como não há muito tempo para entendimentos iniciais, se perde oportu- durante todo o livro (chamado Lexi).
nidades de aplicar inovações na forma de padrões mais específicos que
aumentam produtividade ao projeto. 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
Ou seja, utilizamos no dia-a-dia o “feijão com arroz”, e quanto maior for Core J2EE é um padrão que permite tornar um objeto em algo persistente,
a pressão para entrega, menor o tempo para utilização da criatividade. que pode ser uma base de dados, flat file ou qualquer outro mecanismo.

15
Provocação
Digital

Pois bem, esta é exatamente a finalidade do Memento do GOF, que permi- própria (STL). Torço para que algum dia alguém não tenha a ideia magnífica de
te externalizar o estado de um objeto para posterior reutilização. implementar macrosubstituição em Java, como existe em C++, que torna o
código incompreensível e sujeitos a nichos de programaçã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-
Nem tudo está perdido
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
Existem movimentos no sentido de uma aproximação maior entre as
apresentando novas utilizações, pois a semântica é algo muito importante
áreas técnicas e de negócios. Mais precisamente, uma aproximação no
em um padrão.
sentido da área técnica para a área de negócios.

Novas experiências e distorções na OO Entre elas podemos destacar Domain Driven Design e as soluções BPMS
(Business Process Management Systems). Hoje se tem um gradual retorno
As linguagens mais novas vêm fazendo experiências, que de certa forma exer- ao entendimento de que o mais importante é que qualquer que seja a
citam variações dos princípios fundamentais da OO e podem gerar resultados tecnologia criada, ela deve simplificar as atividades técnicas no sentido de
positivos ou negativos. Outro dia um colega estava me mostrando um recurso manter o foco nas necessidades dos clientes, ao invés de obscurecer com
da linguagem Ruby (que é orientada para objetos), que segundo as palavras particularidades que dificultam aos programadores inexperientes o enten-
dele “era algo muito legal”. A linguagem permite que novos métodos sejam de- dimento destes conceitos. Este tipo de conceito, apesar de parecer óbvio,
finidos dinamicamente, durante a execução e apenas para algumas instâncias levou um grande tempo de maturação para chegarmos aos dias atuais.
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. Considerações finais
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 Estes exemplos mostram que a atividade de ser criativo na construção de
se o objetivo do polimorfismo é criar clareza no código, através de famílias de um sistema OO é mais próxima de uma arte do que dependente de técnica.
objetos similares, este recurso cria objetos iguais, mas na realidade diferentes, Afinal, textos como a obra de arte Design Patterns permaneceram por anos
o que é muito complicado de se gerenciar na prática. 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
O polimorfismo permite que tenhamos classes diferentes com uma mesma
esforço na tentativa de tornar os conceitos de OO como algo “engessado” nos
“interface”, ou conjunto de métodos, de forma que cada uma delas poderá ter
projetos, numa clara tentativa de tornar massificado o acesso de tecnologias
implementações de comportamentos diferentes. Isto permite tratar objetos de
OO a um grupo maior de pessoas. Movimentos no sentido de agregar mais
tipos diferentes de uma mesma forma. O que está se propondo é exatamente
e mais funcionalidades na linguagem podem aumentar a complexidade,
o inverso do polimorfismo. Ou seja, objetos do mesmo tipo, alguns com mé-
reduzindo o grupo de pessoas com acesso à tecnologia.
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- Apesar de tudo, temos conseguido grande evolução no entendimento e
táveis nos códigos futuros. utilização destes conceitos todos, e este conhecimento está sendo utilizado
de forma a simplificar o acesso à tecnologia.
Mas já que estamos falando de padronização, algumas características do
Ruby, especialmente em aplicações Ruby on Rails, são muito interessantes. Hoje a orientação para objetos já é uma disciplina em cursos de graduação,
Por exemplo, são gerados padrões de diretórios para os códigos criados, com e não um trabalho para ser criado nas férias escolares. Os muitos frameworks
repetições de nomes, o que torna seu uso muito intuitivo. Qualquer um que vêm fazendo os programadores e arquitetos a refletir vantagens de uma
observa a estrutura de diretórios entende muito facilmente. BCPSEBHFNPVPVUSB DSJBOEPTVBQSØQSJBCBTFEFDPOIFDJNFOUPt
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 Referências
linguagem mais simples. Elementos como unions, enumerations, structs, tipos
parametrizados foram retirados da linguagem. O Java foi uma simplificação %FTJHO1BUUFSOTo&SJDI(BNNB 3JDIBSE)FMN 3BMQI+PIOTPOF+PIO7MJTTJEFT
Core J2EE Patterns – Deepak Alur, John Crupi e Dan Malks
tremenda do C++, com classes e tipos básicos apenas. Tudo se encaixava em EJB Design Patterns Floyd Marinescu
uma destas categorias. Quem participou desta época relembra como foi uma Expert One-on-One J2EE Design and Development – Rod Johnson
Fundamentos do desenho orientado para objetos – Meilir Page Jones
migração para algo mais simples. Applying UML and Patterns – Craig Larman
Object Oriented Analysis and design – Grady Booch
E mesmo com esta simplicidade foi possível surgirem servidores de aplicação IUUQNBSUJOGPXMFSDPNBSUJDMFTJOKFDUJPOIUNM
muito complexos em funcionalidade. Precisávamos mesmo de toda esta evo- &ODBQTVMBUJPOBOE*OIFSJUBODFJO0CKFDU0SMFOUFE1SPHSBNNJOH-BOHVBHFTo
IUUQXXXDTDPMPSBEPFEV_EJXBODMBTTQBQFSTTOZEFSQEG
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 "Se sentiu provocado? Discordou de algum ponto de vista? Res-
evolução ou uma "involução", já que o complexo ficou simples, e agora volta ponda as provocações! Envie um e-mail para artigos@mundoj.
gradualmente a se tornar complexo de novo. Foi engraçado ver as pessoas com.br com um texto contendo sua contra-argumentação que
comemorarem a criação dos tipos parametrizados como uma grande novida- ele poderá ser publicado em uma de nossas próximas edições."
de, sendo que já existia desde o início em C++, inclusive com uma biblioteca

16 www.mundoj.com.br