A Origem da OOPA 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 ObjetosEncontre 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.ClassesProcure 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 diferenci-la 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.MtodosOs 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.EncapsulamentoAlguns 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.ExceesDigamos 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.PolimorfismoPolimorfismo 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.InterfacesO 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.