A Origem da OOP

A Programao Orientada a Objetos se originou da evoluo natural

da programao procedural.
O primeiro modelo de programao era o sequncial, onde o fluxo
possua um comeo, meio e fim definidos, e o processador recebia
cada instruo sequencialmente at encontrar o fim do programa onde
ele simplesmente parava.
Da necessidade de manipular este fluxo, iniciou-se os primeiros
recursos de desvio como os laos (loops) e o desvio condicional (if),
no entanto, j era notvel a limitao destes recursos.
O primeiro grande problema eram os trechos de cdigo que se
repetiam absurdamente nos desenvolvimento de sistemas. Para isto,
foi criado um novo conceito de desenvolvimento, que quebrava um
programa em vrios outros menores, cada um resolvendo um
pequeno problema que fazia parte de um todo. No pra menos que
relacionam a programao procedural (ou estruturada) com o mantra:
Dividir e Conquistar, baseado na Arte da Guerra de Sun Tzu. Pois a
programao estruturada foi um conceito rapidamente aceito pelos
desenvolvedores da poca, prontos para construir seus pequenos
programas e consum-los diversas vezes no programa principal,
eliminando inmeros trechos de cdigo que se repetiriam ao longo dos
seus algoritmos.
Este conceito de reusabilidade acabou por ser cada vez mais
explorado. O reso de cdigo implementado na programao
estruturada usado at hoje, na orientao a objetos, atravs dos
mtodos, que encapsulam um comportamento ntegro e podem ser
disparados inmeras vezes por diversos outros objetos. Mas a
reusabilidade em si ainda era um mero rascunho. J era possvel

reutilizar trechos de algoritmos, mas como reutilizar estado? E separar

estados distintos de entidades semelhantes?
Foi ento que o paradigma dos Objetos foi apresentado.
O Paradigma dos Objetos
Encontre uma foto qualquer, de famlia, de paisagem, de uma rua
movimentada. No importa. Pegue uma qualquer e observe-a
atentamente.
S de olhar para uma foto, seu crebro j capaz de identificar, sem
muito esforo, pessoas, carros, rvores, edifcios, postes, lojas,
caixas-de-correio, etc. No importa se na teoria a foto seja apenas um
pedao de papel com milhares de pequenos pontos coloridos que
formam figuras. Para o seu crebro, a foto apresenta um composto de
objetos facilmente identificveis.
Na orientao orientada a Objetos, o princpio o mesmo. Seu
programa olha para a memria do computador e identifica objetos:
Produtos, clientes, Pedidos, entregas, notas fiscais. Objetos
espalhados que interagem entre si atravs de mtodos e encapsulam
estado prprio, que o torna independente de seus semelhantes. Olhar
para este panorama faz com que seu sistema tire uma foto
instantanea de tudo o que est acontecendo e orquestre a
interatividade entre todos os elementos para que seu funcionamento
seja eficaz.
Classes
Procure olhar novamente para uma foto qualquer. Como pode ser que
voc seja capaz de reconhecer cada objeto que voc v nela? Pegue
uma cadeira e observe. Tente comparar com uma outra cadeira
qualquer que voc tenha, por exemplo, na sua casa. Ou no

restaurante onde voc almoa. Ou na casa de um amigo seu. Note

que cadeiras possuem diversas variaes de forma que quase
impossvel encontrar duas cadeiras de dois ambientes distintos que
sejam parecidas.
A maioria das cadeiras s so semelhantes quando se encontram num
mesmo escritrio ou ao redor de uma mesma mesa. No entanto, por
mais diferentes que elas possam ser entre si (se tem apoio de braos,
se possuem 4 pernas ou apenas uma central que se divide em vrias
ao chegar no cho, ou apenas uma armao de ferro que a sustenta,
se tem rodinhas, se gira, se reclinvel ou no, se ajusta a altura ou
no, enfim todas as variaes possveis se tratando de cadeiras)
ainda assim voc sempre a reconhecer como uma cadeira, assim
como ser capaz de identificar cada um dos objetos na foto que viu
anteriormente.
O crebro capaz de fazer este reconhecimento por que, em algum
momento antes, quando o memos objeto era uma novidade para ele,
ele foi capaz de classific-lo. Quando estamos conhecendo o mundo
ao nosso redor, nosso crebro identifica tudo o que capaz de
identificar e classifica aquilo como algo reconhecvel atravs de
determinadas caractersticas. Em algum momento na sua vida, voc
reparou que tudo aquilo que seja composto por um sustento, um
acento e um encosto, uma cadeira. E, a partir da, sempre que viu
uma cadeira, independente do quo diferente ela fsse daquela
primeira, voc soube reconhecer que ela era uma.
Se lhe for pedido que pegue um papel e uma caneta, e desenhe uma
cadeira, independente de qualquer tcnica que voc utilize para
desenh-la, se ir caprichar ou faz-la s pressas, com certeza voc
ir traar, no mnimo, um sustento, um acento e um encosto. Da
mesma forma, voc consegue reconhecer uma pessoa quando ela foi
desenhada usando apenas riscos simples e um crculo na cabea e,

finalmente, consider-la como semelhante a uma pessoa real, ainda

que diferente.
Na programao orientada a objetos, voc cria classes que diro ao
seu sistema como cada um dos objetos devem ser. A classe Cliente
ter atributos do cadastro do cliente, seu endereo, seus pedidos, seu
contato. Todas estas informaes so teis para dizer ao seu sistema
como um cliente deve se parecer, para que, quando ele veja um objeto
com estas caractersticas, ele possa dizer: Isto um cliente. A classe
no composta por um objeto, mas define o que o objeto vai ser. Ela
aquele conceito dentro do seu crebro de como uma cadeira deve
se parecer, para que quando voc veja uma, seja capaz de diferencila de um banco, uma cama, um carro ou um elefante.
Atributos (ou propriedades)
Os objetos possuem atributos que definem seu estado. Informaes
como pso, cr, data de fabricao, data de vencimento, valor, idade,
sexo, nome, e-mail, telefone, prazo de entrega, e tantas outras,
atribuem caractersticas aos seus objetos de acordo com suas
classes, definindo o estado em que eles se encontram num
determinado momento.
O estado de um objeto pode ou no ser alterado conforme o tempo
passa. Mas, em qualquer instante, apenas um s.
Mtodos
Os objetos tambm interagem entre si, enviando e recebendo
mensagens e respostas. Eles manifestam essa interatividade atravs
da invocao de mtodos que definem e implementam uma
determinada responsabilidade que um objeto tem. Um aparelho de
som tem a responsabilidade de tocar uma msica, desde que receba o
comando para isto, o comando est definido em um boto, e a

implementao desta responsabilidade est situada em seus

componentes eletrnicos. Assim, quando o usurio aperta o boto
definido, ele espera que o aparelho de som comece a tocar msica.
Observe que um aparelho de som tambm vem equipado com outros
botes, que representam a definio de outras responsabilidades,
como parar de tocar, comear a gravar, alterar o controle de volume,
mudar a estao de rdio ou procurar por trilhas em uma mdia de CD.
Cada uma destas responsabilidades compem toda a utilidade do
Aparelho de som, ou seja, ao definir um problema complexo (Construir
um aparelho de som), dividiram-no em problemas menores (Tocar
radio, tocar Cd, Gravar, mudar de estao, mudar o volume, parar de
tocar) que definiu seus mtodos bsicos.
Aqui vale a pena lembrar novamente de como a OOP uma evoluo
da programao estruturada.
Pois assim que se deve tentar entender como definir quais mtodos
os seus objetos devero ter antes de implement-los na sua classe.
Voc define suas responsabilidades. Um cliente efetua compras, um
pedido precisa incluir produtos, precisa emitir uma nota, precisa ser
entregue.
Encapsulamento
Alguns mtodos no conseguem por si s resolverem sua
responsabilidade sem que algumas informaes sejam previamente
informadas. Uma pesquisa no Google no pode retornar valores se
no receber algo por que buscar. Um pedido no capaz de incluir
produtos em si sem saber quais produtos o cliente quer adquirir. Estas
informaes podem ser encontradas espalhadas pelo sistema de
acordo com o estado dos objetos na memria no momento em que o
mtodo acionado. Porm, quando um mtodo depende desse tipo

de informao seu funcionamento arriscado, pois as informaes

que procura podem no estar l.
A forma mais segura de fazer com que o mtodo funcione de forma
segura entreg-lo prontamente todas as informaes que ele
necessita para fazer o que precisa ser feito. Um mtodo que envia um
e-mail para o cliente, informando o status de sua compra, no tem
garantias de que v funcionar se tiver que procurar sozinho todas as
informaes (que cliente, qual status), ou ir funcionar com limitaes
pois, por mais que ele saiba procurar pelos dados em um banco, no
ser capaz de cumprir o mesmo propsito se em determinadas
entregas a loja contratar um servio de frete terceirizado que
administra o status separadamente.
Encapsulamento um conjunto de pequenas regras que tornam seus
objetos mais ntegros. E uma destas regras a de deixar o mtodo se
resolver por si s fazendo tudo o que ele tem que fazer e nada alm
disso. Invs de procurar pelo cliente no banco de dados, ele recebe os
dados do cliente atravs de parmetros e deixa que a busca pelos
dados do cliente seja feita por outro objeto que possua essa
responsabilidade (mtodo).
Outra regrinha do encapsulamento, que os objetos devem ser
responsveis por si. Soberanos na administrao de si mesmos. Por
exemplo, se um objeto pessoa tem um atributo idade, o objeto pessoa
deve saber administrar essa propriedade para que, se um objeto
externo tente atribuir um valor invlido (como -1, por exemplo) o
prprio objeto pessoa saiba se defender. Isto torna a inteligncia do
objeto centralizada em um nico lugar, nele mesmo, o que far com
que sua administrao seja independente dos outros objetos que
compem a arquitetura do sistema.
Excees

Digamos ento que o objeto pessoa receba um valor invlido para ser
atribudo na propriedade Idade. Como tratar este problema? O Objeto
pessoa pode ignorar a ordem. OU exibir uma mensagem na tela. Mas
e se for imprenscindvel para o objeto externo saber que a atribuio
tenha ocorrido com sucesso? E se o sistema estiver rodando num
servio windows e no existir uma tela para exibir a mensagem?
O conceito de tratamento de excees estruturadas no
necessariamente parte da orientao a objetos, mas ele foi muito bem
vindo no panorama atual de desenvolvimento de software. Uma
exception uma situao inesperada que arremeada por um
mtodo invocado, direcionada para o mtodo que o invocou.
Por exemplo: o motorista do caminho no encontrou ningum no
endereo que o cliente informou, que pudesse receber a encomenda.
Ele ento lana a exceo para seu superior imediato, o mtodo que o
invocou, seu supervisor. O supervisor olhar para a exception e ver
se trata-se de um problema que ele tenha autonomia para resolver. Se
no tiver ele repassa ela para o prximo superior da pilha. O mtodo
que o invocou. O gerente de contas da loja vai verificar que passou o
endereo do cliente errado e corrig-lo ou concluir que no possui o
endereo correto e acionar o cliente para se informar a respeito.
Ao resolver o problema, todos so acionados novamente at que o
motorista tente fazer uma nova entrega.
Assim funciona o tratamento de excees na OOP. Seus mtodos
podem receber exceptions que descrevem situaes inesperadas. Se
no houver implementao de tratamento para elas, eles a lanam
(throw) para o mtodo que os chamou, at chegar no topo da pilha (no
caso, o ncleo do sistema) resultando em um erro, que ir interromper
todo o sistema.

Por isso importante identificar que tipos de situaes inesperadas

um mtodo pode resolver. Um mtodo que tenta se conectar ao
banco, por exemplo, pode receber uma exception dizendo que o
banco no est no ar. Se o banco no est no ar, e a responsabilidade
dele se conectar ao banco, ento responsabilidade dele tratar esta
exception sem repass-la ao mtodo que o chamou. Mas se um
mtodo que precisa enviar um e-mail receber uma exception
descrevendo erro de diviso por zero, isso no problema do mtodo
em questo. Ele no precisa trat-lo. Ele repassa para o mtodo que o
chamou at que se torne claro para algum (atravs de uma
mensagem de erro no sistema) que algum mtodo deixou de fazer o
tratamento antes de chegar no mtodo que envia os e-mails.
Polimorfismo
Polimorfismo uma palavra complicada para um conceito simples.
No se trata de um recurso a ser implementado. Se trata de uma
propriedade da linguagem de programao. O conceito simples.
Imagine: Uma classe base Cliente extendida pela classe herdeira
ClienteVirtual. O cliente base possui todas as informaes
concernentes a ele: endereo, telefone, pontos obtidos pelas compras
feitas, etc. J a classe herdeira, ClienteVirtual, possui os dados
especficos para os cliente que faro compras pelo website: nome do
usurio, senha, e-mail, etc.
Voc tem clientes que fazem as compras pessoalmente no balco, e
clientes que fazem as compras pela internet. Mas e se os clientes da
internet resolverem fazer uma compra no carto? Voc vai pedir a ele
que lhe fornea nome do usurio e senha no balco?
A situao parece absurda pela mera simplicidade da resoluo. As
duas classes so parecidas, mas so duas classes, dois tipos de
dados diferentes. O polimorfismo a propriedade que uma linguagem
tem de entender que, por exemplo, um clienteVirtual no deixa de ser
um cliente, ou seja, continua podendo ser aceito como um simples

cliente. Quando se dirige ao Balco, o ClienteVirtual pode apresentar

todos os dados que recebeu por herana do cliente, independente do
Usurio e senha, pois no balco os nicos dados que importam so os
dados do cliente base.
Pode parecer bvio agora, mas o polimorfismo muito til,
principalmente quando entra o uso das interfaces.
Interfaces
O princpio de herana nem sempre se aplica a todas as classes que
possuem caractersticas comuns. Uma pessoa capaz de Andar,
assim como um carro capaz de andar. Nem por isso eles fazem
parte de algum material comum. No seu sistema voc pode ter que se
deparar com situaes parecidas.
Voc pode, por exemplo, criar um agendador de tarefas programadas
que servir para mandar uma mensagem por e-mail diariamente para
todos os clientes da loja. De forma semelhante, diariamente ele
tambm pode iniciar uma tarefa que verifica se todos os servidores
esto online.
Perceba que voc pode estar lidando aqui com objetos de duas
classes diferentes: MensagemPromocional e
VerificadorDeConectividade. As duas classes no possuem relao
nenhuma a no ser pelo fato de que as duas sero manipuladas por
um mesmo objeto Agendador.
O conceito de interfaces comea a ser entendido pelo que o prprio
nome diz: Interface a forma em que a via de comunicao precisa
tomar para estabelecer contato com o destinatrio. Uma tomada
comum possui uma interface que vai determinar o tipo de plug que um
fio deve possuir caso queira instalar-se nela. Se o plug no for
compatvel com a interface da tomada, ele vai precisar ser adaptado.
Existe a interface de dois pinos, a interface de duas placas de cobre, e
a interface 2p+T que inclui um terceiro pino para o fio-terra, para no
citar ainda outras interfaces. Se o plug em questo no implementar a

interface exigida pela tomada, ele no vai conseguir se plugar a

menos que utilize um adaptador que implemente esta interface.
E atravs desta interface voc capaz de ligar um nmero variado de
equipamentos que possuam plugs que a implementem. Desde forno
eltrico, fogo, geladeira, televisor, aparelho de som, equipamentos de
ginstica, compuadores, carregadores de celular, etc. Consegue
enxergar a dimenso?
Assim tambm na OOP. As classes no so obrigadas a herdarem
umas das outras para serem semelhantes. Uma Interface pode ser
criada, que defina todas as operaes comuns que as classes que a
implementem precisem ter, e ento basta implement-las nas classes
para que elas possam ser plugadas por outras.
E a que a diverso do polimorfismo realmente comea. Digamos
que voc tenha uma interface ITarefaAgendada que implemente um
mtodo ExecutarTarefa. Implemente esta interface nas classes
MensagemPromocional e VerificadorDeConectividade, assim ambos
precisaro pussuir o mtodo ExecutarTarefa. Imagine que o mtodo
quando o Agendador disparar, ir procurar por todas as terefas
agendadas e em cada uma ir disparar o mtodo ExecutarTarefa. Isso
tudo sem saber (e nem ligar) se a tarefa uma
MensagemPromocional ou um VerificadorDeConectividade.
Agora sim, voc est comeando a compreender o grande universo do
polimorfismo.