Reproduzo, aqui, um diálogo que tive com alguns estudantes sobre orientação a objetos, quando ainda ensinava em universidade particular. Considero a leitura um bom texto introdutório ao assunto e fui tão fiel às falas quanto delas pude lembrar.
- Professor comece pelo começo: O que é programação orientada a objetos?
A resposta mais simples e objetiva e praticamente inútil: é um paradigma de linguagem de programação. Mas paradigma não é uma palavra comum, então vamos por outro lado. O outro lado, no caso, são os objetos.
Um objeto no mundo real é praticamente qualquer coisa. Uma caneta é um objeto, uma televisão é um objeto, uma mulher é um objeto, um homem é um objeto (a orientação a objetos é democrática)... no mundo real os objetos têm informações características (uma caneta tem uma cor, um tamanho) e comportamento (um aluno, a princípio, estuda, uma caneta escreve etc.). Um dado comportamento de um objeto normalmente é ativado através da interação com algum outro objeto. Por exemplo, um objeto homem interage com um objeto televisão para que este efetue o comportamento ligar, mudar canal, aumentar volume etc. O conjunto de todos esses objetos que interagem entre si formam uma espécie de sistema.
Bem, um programa orientado a objetos é um desses sistemas - uma ruma de objetos que interagem entre si. Sendo que seus objetos não são paupáveis e emocionantes como cervejas e mulheres e, vá lá, televisões. Seus objetos são módulos...pedaços de programas... variáveis, funções, se's, para's, enquanto's... essas coisas chatas que você já deve ter visto em qualquer curso de programação.
- Certo, mas como identificamos nesses pedaços de programas as informações do objeto e seu comportamento?
Informações acerca dos objetos são representadas, naturalmente, por variáveis. Comportamentos são expressos através do que você que já programa deve conhecer por funções.
- Ah... mas e o tal "paradigma", serve pra quê?
Paradigma é uma forma de pensar. O paradigma da orientação a objetos estabelece uma forma de conceber, implementar sistemas como objetos que interagem entre si. Interagir, aqui, significa ativar comportamento. Outros paradigmas estabelecem formas de implementar o mesmo sistema sob outra perspectiva. Para sistemas complexos a experiência tem mostrado que a decomposição em objetos interativos, ou seja, a implementação de funcionalidades como interações entre objetos, é mais interessante que as outras alternativas.
- E por quê?
Por uma razão bem simples. Porque a decomposição em objetos é mais fiel ao que os sistemas realmente são. Analise os potenciais sistemas em sua volta... um jogo de futebol, um programa de televisão, uma aula... não vai ser tão difícil identificar os objetos, atributos e comportamento... imagine um simples jogo de xadrez, onde podemos identificar informação (a cor e forma das peças) e comportamento (possíveis tipos de movimentos) juntos num mesmo objeto. Em outros paradigmas, informações e comportamento não estão juntos numa mesma entidade. Ou, ao menos, não precisam estar.
- E se eu quiser fazer um sistema onde eu sou um ricão com três ou quatro objetos loiras bonitas... eu vou ter que escrever um código muito parecido para cada uma delas, já que todas elas têm cabelo da mesma cor e gastam meu dinheiro da mesma forma...?
Isso é muito machista de sua parte, mas meu contrato me obriga a responder. Não haverá esse problema porque, na verdade, a gente não escreve o código das loiras em si. A gente escreve o código para um modelo de loira e criamos todos os objetos loiras a partir desse modelo. Assim, todas as loiras criadas a partir do modelo terão a mesma estrutura de informação e comportamento. Nós chamamos esses modelos de classes. Classes são modelos de software.
- Então as loiras que eu criar a partir do modelo serão todas iguais?
Não. Você define no modelo que as loiras terão duas informações, por exemplo, altura e cintura, mas isso só quer dizer que TODOS os objetos loiras criados a partir do modelo terão essas duas informações agregadas a eles, o que não significa que essas informações serão as mesmas para todas as loiras. Você pode configurar um dos objetos para ter 1,68 de altura, outro pra ter 1,80 e assim por diante. Mas todos vão ter os atributos altura e cintura, porque seguem o mesmo modelo. O mesmo raciocínio vale para o comportamento.
- Ok. A parte da informação eu entendi. Mas o comportamento, não. Eu posso atribuir valores diferentes para os atributos de cada loira. Mas como djabo eu vou configurar um comportamento??? Se eu defino no modelo o comportamento das loiras, pra mim, elas se comportarão todas do mesmo jeito.
Ponto interessante. Isso não acontece por dois motivos. Primeiro, o comportamento de um objeto loira pode variar de acordo com os atributos configurados para o objeto. Por exemplo, o comportamento vestir-se de uma loira com cintura larga provavelmente vai ser diferente do modo de vestir-se de uma loira com cintura fina. O modelo/classe loira tem que definir todas essas possibilidades do comportamento vestir-se, mas os objetos em si irão vestir-se de maneira diferente, de acordo com seus atributos, suas informações "pessoais", internas. Mas existe ainda outro ponto. Uma classe/modelo não define o comportamento de um objeto mas sim o possível comportamento de um objeto. Em outras palavras, um modelo/classe em si não executa absolutamente nada, apenas define tudo o que seus objetos podem fazer ou tudo o que sabem fazer. A ativação de um comportamento de um objeto depende da interação dele com outros objetos, muitas vezes de modelos distintos. Você pode ser, por exemplo, um objeto homem que pode ativar apenas o comportamento gastar dinheiro dos três objetos loiras bonitas que você citou. Um outro objeto homem pode interagir com esses mesmos objetos loiras e ativar outros comportamentos importantes que os objetos loiras certamente são capazes de executar.
- Gostei não, professor...
É apenas uma metáfora - sua metáfora, inclusive - mas é isso mesmo. O que os objetos são capazes de fazer é escrito no modelo, na classe. O que acontece na prática, a "execução", é determinada pela interação entre os vários objetos que compõem o sistema.
- E é essa putaria toda um sistema orientado a objetos? Todo mundo pode comer todo mundo a toda hora?
Pode ser, se o sistema implementado tiver essa característica. Mas, na prática, falando em programação e deixando as analogias de lado, as interações são mais ordenadas e previsíveis, e os objetos mais passivos. Em geral eles ficam lá, na deles, até que um elemento externo - o usuário - os perturbe. Clicar um botão "Inserir", por exemplo, é perturbar um objeto do sistema - o objeto botão. Essa perturbação vai refletir-se na execução de um comportamento do objeto botão que, por sua vez, vai ativar comportamentos de outros objetos que ele "conhece". Os objetos que o objeto botão conhece também conhecem outros objetos e vão interagir com eles e assim por diante. Podemos considerar que o conjunto de todas essas interações desencadeadas pelo clique são a execução (ou parte da execução) de uma funcionalidade do sistema...
- Tá certo, tá certo. Já posso implementar meus modelos? Como eu começo.
Calma. Nesse curso, nós vamos começar usando objetos de modelos já prontos, de classes que outros programadores implementaram. Essa é uma atividade extremamente comum, extremamente importante e, segundo alguns pesquisadores, um caminho mais fácil e efetivo para os principiantes.