Orientação a objetos e a medicina - André Pires Blog > Home
Orientação a objetos e a medicina
Posted on 11/24/2012 by André Pires in
Hoje bati um bom papo com um de meus alunos, e durante a conversa surgiram algumas questões sobre desenvolvimento de software. Ele me disse que tem uma certa dificuldade para entender como alguns dos assuntos que eu falo em sala de aula podem ser aplicados no mundo real, no dia-a-dia do desenvolvedor. Eu usei aspectos da vida humana, das coisas que conhecemos e até da medicina para tentar explicar. Será que consegui?
Bom, a dúvida era comum. Eu já a havia enfrentado em outras aulas, com outras pessoas.
Tratava-se daquilo que eu considero que seja uma das mais difíceis tarefas da carreira de um desenvolvedor: Entender OO e seus conceitos e princípios. Nesse caso específico, o assunto era basicamente a Abstração.
A pergunta foi a seguinte: Como desenvolver um software, seja ele qual for, sem fazer uma análise profunda de antemão, sobre o que deve ser feito?
Eu sei as razões pelas quais essa pergunta me é feita com frequência... Eu sou um evangelista de práticas ágeis, de arquitetura emergente, OO, padrões de design, etc, e sempre cito tudo o que eu defendo e acredito em minhas aulas. Quando eu falo que é possível iniciar um projeto de software sem ter que especificar tudo logo de cara, esse tipo de pergunta se torna uma constante...
Enfim, qual foi minha resposta? Bem, eu falei muita coisa :)
Comecei com uma das coisas mais básicas que aprendemos quando iniciamos nossas carreiras, lá na disciplina de Sistemas de Informação: Um sistema é algo que recebe um "dado", o processa, e te dá em retorno uma "informação". Essa informação, pode servir como dado para outro sistema, e assim por diante. Não vou citar aqui os sistemas reentrantes e outros conceitos de SI, o que quero é o foco nessa "peça", nesse elemento menor que faz o trabalho de processar um dado e nos dar uma informação, ok?
Essa peça é uma unidade. Sendo uma unidade, ela deve ser autônoma, ou seja, deve realizar a tarefa que a torna útil, de forma independente de outras peças. Sendo uma unidade, ela deve ser testável, ou seja, ela deve permitir que algum mecanismo externo verifique e garanta que a tarefa que essa peça se propõe a fazer, seja realmente feita, de acordo com uma especificação.
Se você se concentrar nesse princípio básico da SI, você acabará por perceber que sistemas complexos nada mais são do que várias dessas pequenas peças, unidas por um contexto comum, trabalhando de forma ordenada, afim de realizar tarefas.
Você pode também selecionar um conjunto de peças iguais ou diferentes, maiores ou menores, organizá-las de modos diferentes para conseguir resolver problemas diferentes... Alguém já montou um robô ou brincou de lego?
O ser humano aprendeu a fazer isso muito bem, em várias áreas de nosso conhecimento... A engenharia mecânica, a eletrônica e outras, já masterizaram essa capacidade de criar peças pequenas, autônomas, testáveis como uma unidade, substituíveis, independentes, desacopladas e com interfaces claras. Por que em nossa área, a do software, a coisa é tão difícil de se entender e de se aplicar?
Eu não tenho a certeza, mas tenho um palpite: Nas engenharias, as "coisas" criadas são, em sua maioria, físicas, reais, palpáveis... Graças a essa característica, fica claro que essas peças funcionam e trabalham dentro dos limites físicos conhecidos. Esses limites físicos impedem que façamos coisas absurdas (na maioria das vezes, ao menos... :)).
Por exemplo: Um engenheiro mecânico vai projetar seu novo carro. Imagine o que seria, fisicamente, se o projeto se tornasse um carro que exigisse de seus usuários que, ao trocar um pneu, o cara tivesse que pegar uma talhadeira e uma marreta, um maçarico e com isso tudo tivesse que tirar a força a roda do eixo do carro... Como seria tal carro para o usuário? É fisicamente possível de se fazer um carro assim, mas é viável? Não!
Mas acontece que, pelo fato desses elementos mecânicos serem físicos, fica fácil perceber que fazer um carro assim é errado.
No caso do software, as peças são lógicas, não físicas. Isso é bom e ruim. É bom porque, por serem lógicas, podemos usar nossa criatividade para criar praticamente qualquer coisa que quisermos. Podemos gerar inclusive riqueza, muita riqueza, sem gastar uma grama de materiais físicos. Por outro lado é ruim porque sua natureza lógica nos permite criar peças "improváveis", malucas, doidas, etc...
O homem é criativo... Acreditem: Já vi muita peça "incategorizável" por aí...
Na minha opinião, o que um desenvolvedor deve fazer para entender de vez o OO é entender esses conceitos, das peças...
O que as outras engenharias já fizeram, e muito bem, foi entender esse conceito de Objeto. Eles sabem muito bem o que objetos são, como eles se comportam e como criá-los com pouco ou nenhum acoplamento. Eles sabem definir interfaces, eles sabem o que é Abstração.
Se meu carro apresentar um defeito no motor, eu posso trocar o motor por outro que "implemente" a mesma interface, que o carro, como um todo, vai continuar a funcionar... Devemos fazer o mesmo com o software: Entender objetos, abstrações e interfaces...
Para eliminar o problema do desconhecido, você deve fazer o teu software depender de abstrações, não de concretizações. Quando não se conhece nada sobre uma peça da qual o teu sistema vai depender no futuro, pense na interface que possa satisfazer o mínimo para o funcionamento desse sistema. Esse mínimo pode ser um conjunto de poucas propriedades e métodos que você já conhece. Se você não conhece nada, lembre-se do seguinte: Uma interface serve basicamente como um elo de ligação entre duas peças distintas que devem se comunicar. Você geralmente vai conhecer bem ao menos uma dessas peças e geralmente essa peça será uma que você já especificou e está desenvolvendo. Quando a segunda parte desse relacionamento surgir e você perceber que não conhece nada sobre ela, simplesmente desenvolva uma interface que se "encaixe" na peça que você já conhece. Esqueça da outra, ou menos por enquanto. Quando você faz isso, você simplesmente abstraiu o funcionamento dessa peça desconhecida e disse para o mundo externo que para se comunicar com a peça que você conhece, esse mundo externo deverá se adaptar à sua interface pública. Em casos mais extremos você ainda poderá criar interfaces realmente muito genéricas, que cumprem o papel mínimo dos sistemas, que eu citei no início desse post: Crie uma interface que aceite dados genéricos de entrada e que forneça informações genéricas de saída. Garanto a você que mesmo com o "genérico" presente, quem quiser se comunicar com tua peça, irá conseguir... :)
Por fim, o que isso tudo tem a ver com medicina?
Bem, no fim da conversa eu perguntei: Sabe porque a medicina é a área de conhecimento mais complexa do conhecimento humano (ao menos na minha opinião)?
Simples: O objeto de estudo da medicina é o objeto mais complexo e, principalmente, mais acoplado que conhecemos...
Você já reparou que o corpo humano é composto por "peças" com funções diferentes e que juntas fazem de nós o que nós somos? Entretanto, essas peças estão altamente acopladas e interdependentes. O acoplamento é tão alto, tão forte que a tarefa de substituir a maioria dessas peças, ainda é impossível. Notem: Eu disse "ainda"! :)
Se você é uma pessoa antenada, talvez já tenha visto os avanços na medicina e talvez já tenha visto que o homem já consegue substituir, até com certa facilidade, algumas de nossas peças...
Sabem como isso está se tornando possível? Esses fantásticos profissionais estão aprendendo a enumerar as "interfaces" de nossos corpos. Uma vez enumeradas e compreendidas, se comunicar com nosso corpo através delas se torna uma tarefa trivial.
Pensem nisso... E pensem também no quão fácil é sua tarefa de criar um software usando esses princípios...