Abri o OpenOffice Writer, mandei gravar uma macro, escrevi “teste”, selecionei e pintei de vermelho. Olha o código gerado:
sub Main rem ---------------------------------------------------------------------- rem define variables dim document as object dim dispatcher as object rem ---------------------------------------------------------------------- rem get access to the document document = ThisComponent.CurrentController.Frame dispatcher = createUnoService("com.sun.star.frame.DispatchHelper") rem ---------------------------------------------------------------------- dim args1(0) as new com.sun.star.beans.PropertyValue args1(0).Name = "Text" args1(0).Value = "teste" dispatcher.executeDispatch(document, ".uno:InsertText", "", 0, args1()) rem ---------------------------------------------------------------------- dispatcher.executeDispatch(document, ".uno:SelectAll", "", 0, Array()) rem ---------------------------------------------------------------------- dim args3(0) as new com.sun.star.beans.PropertyValue args3(0).Name = "FontColor" args3(0).Value = 16711680 dispatcher.executeDispatch(document, ".uno:FontColor", "", 0, args3()) end sub
Há muito código complexo por aí. Nesse caso, para invocar os métodos dos objetos do OpenOffice, é preciso usar um objeto dispatcher, chamando executeDispatcher, e passando o objeto, o nome do método e um array de argumentos. Que espécie de sadismo leva alguém a projetar uma solução como essa? Vale lembrar o que diz o Zen do Python:
Se uma implementação é difícil de explicar, é uma idéia ruim.
Outro exemplo interessantíssimo é o protocolo SOAP. Se você precisar construir um serviço SOAP do zero, dê uma investigada na documentação que você vai ter que ler. Compare com a documentação do protocolo XML-RPC, para ter uma idéia.
Meninos, o tio vai ensinar um segredo a vocês, a complexidade se reproduz assexuadamente. Há muito código complexo demais por aí. Se você encontrar indícios de complexidade hoje, corte antes que ela se reproduza, porque ela tende a fugir do controle. Cada vez que você deixa uma implementação complexa num componente de um sistema, você está complicando um pouquinho todos os pontos do sistema que usam aquele. Os resultados ruins são exponenciais. Por mais talentoso que você seja, se deixar a complexidade se enraizar e crescer, vai chegar um momento em que a lógica vai “jogar a toalha” e você vai começar a programar na base da tentativa e erro.
Lembre-se, então, partes simples, conectadas por interfaces simples. Complicado é errado, feio e mau, faz você entregar atrasado e com bugs. E, se precisar de inspiração, abra o Python e digite:
import this
Olá, parabéns pelo site e pelo artigo. Sobre a complexidade acho que a melhor maneira de fugirmos dela é com a máxima de software “dividir e conquistar”.
E acho que cabe citarmos aqui a frase de Leonardo Da Vinci: “Simplicidade é o extremo da sofisitação”, ou seja, quanto mais simples melhor.
Um abraço a todos.
Fernando
Elcio, show o teu blog! Coloquei o RSS dele lá no i-scrum.ning.com
Abraços,
Cesar
“a complexidade se reproduz assexuadamente.”
Não vou mais me esquecer disso!
> “A única maneira de construir software complexo que não desaba na sua cara é
> construí-lo de módulos simples…
Sim, sem dúvida. 😀
Mas não tenho certeza que, mesmo que implementada com módulos simples, será fácil de ser *explicada*, por conta de implementar uma idéia complexa. Mas que deve ser feita com módulos simples, sim, não há dúvida. Afinal, é um dos princípios básicos que aprendemos em Eng. de Software.
Acho que meu comentário anterior não foi muito claro, hehehehehe… acho que acabei passando a idéia de que idéias complexas exigiam implementações complicadas, mas não foi isso que quis dizer. Deve-se usar implementações o mais modulares e simples possível, mas não garante que a implementação é facilmente “explicável” (se é que existe essa palavra)… é, só uma discordância com uma interpretação possível da frase “Se uma implementação é difícil de explicar, é uma idéia ruim”.
E realmente Julio, o MVC – quando bem implementado – nos permite implementar exatamente isso.
“módulos simples conectados por interfaces bem definidas” esse seria o tal código ravioli =)
Acho que esse é um dos grandes méritos do pattern MVC, quando bem implementado. Uma coisa que estou gostando muito de aprender nesse sentido é TDD, já havia visto muita coisa sobre, mas só agora comecei a utilizar. Devo dizer que aumentou muito tanto a produtividade quanto a qualidade do código.
Jerônimo, sobre idéias complexas, requisitos complexos, negócios complexos, gosto de lembrar o Eric S. Raymond: “A única maneira de construir software complexo que não desaba na sua cara é construí-lo de módulos simples conectados por interfaces bem definidas, de forma que a maioria dos problemas seja local e você tenha alguma esperança de consertar ou otimizar uma parte sem quebrar o todo.”
Apesar de discordar da parte do “Se uma implementação é difícil de explicar, é uma idéia ruim”, concordo com todo o resto. Há aplicações que são idéias complexas por si (o que tornaria a implementação um pouco mais complexa), mas não que a implementação seja ruim; ela é simplesmente tão complexa quanto a idéia. 😛
Mas sim, concordo que há muita gente que implementa soluções complexas para problemas simplíssimos, e é aí que reside o problema, conforme disseste, Elcio. É fogo pegar um código legado e ver que tem gente que faz um canhão pra matar uma mosca.
Nada como manter tudo simples! Eu sigo essa filosofia: vale a pena passar um bom tempo simplificando algo antes de implementar do que implementar rápido e ter dores de cabeça na hora de usar. Por isso eu simpatizo (embora ainda não use) com linguagens como Ruby e Python.
E pode deixar tio, o segredo vai ser passado de geração em geração até o final dos tempos =)