Interfaces
O princípio de herança nem sempre se aplica a todas as classes que possuem características 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 situações 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 também pode iniciar uma tarefa que verifica se todos os servidores estão online.
Perceba que você pode estar lidando aqui com objetos de duas classes diferentes: MensagemPromocional e VerificadorDeConectividade. As duas classes não possuem relação nenhuma a não ser pelo fato de que as duas serão manipuladas por um mesmo objeto Agendador.
O conceito de interfaces começa a ser entendido pelo que o próprio nome diz: Interface a forma em que a via de comunicação precisa tomar para estabelecer contato com o destinatário. 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 não for compatível 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 não citar ainda outras interfaces. Se o plug em questão não implementar a interface exigida pela tomada, ele não vai conseguir se plugar a menos que utilize um adaptador que implemente esta interface.
E através desta interface você é capaz de ligar um número variado de equipamentos que possuam plugs que a implementem. Desde forno elétrico, fogão, geladeira, televisor, aparelho de som, equipamentos de ginástica, compuadores, carregadores de celular, etc. Consegue enxergar a dimensão?
Assim também é na OOP. As classes não são obrigadas a herdarem umas das outras para serem semelhantes. Uma Interface pode ser criada, que defina todas as operações comuns que as classes que a implementem precisem ter, e então basta implementá-las nas classes para que elas possam ser plugadas por outras.
E é aí que a diversão do polimorfismo realmente começa. Digamos que você tenha uma interface ITarefaAgendada que implemente um método ExecutarTarefa. Implemente esta interface nas classes MensagemPromocional e VerificadorDeConectividade, assim ambos precisarão pussuir o método ExecutarTarefa. Imagine que o método quando o Agendador disparar, irá procurar por todas as terefas agendadas e em cada uma irá disparar o método ExecutarTarefa. Isso tudo sem saber (e nem ligar) se a tarefa é uma MensagemPromocional ou um VerificadorDeConectividade.
Agora sim, você está começando a compreender o grande universo do polimorfismo.
Tags: Conceitos · Tecnica de Programação
Polimorfismo
Polimorfismo é uma palavra complicada para um conceito simples. Não se trata de um recurso a ser implementado. Se trata de uma propriedade da linguagem de programação. O conceito é simples. Imagine: Uma classe base Cliente é extendida pela classe herdeira ClienteVirtual. O cliente base possui todas as informações concernentes a ele: endereço, telefone, pontos obtidos pelas compras feitas, etc. Já a classe herdeira, ClienteVirtual, possui os dados específicos para os cliente que farão compras pelo website: nome do usuário, senha, e-mail, etc.
Você tem clientes que fazem as compras pessoalmente no balcão, e clientes que fazem as compras pela internet. Mas e se os clientes da internet resolverem fazer uma compra no cartão? VocÊ vai pedir a ele que lhe forneça nome do usuário e senha no balcão?
A situação parece absurda pela mera simplicidade da resolução. As duas classes são parecidas, mas são duas classes, dois tipos de dados diferentes. O polimorfismo é a propriedade que uma linguagem tem de entender que, por exemplo, um clienteVirtual não deixa de ser um cliente, ou seja, continua podendo ser aceito como um simples cliente. Quando se dirige ao Balcão, o ClienteVirtual pode apresentar todos os dados que recebeu por herança do cliente, independente do Usuário e senha, pois no balcão os únicos dados que importam são os dados do cliente base.
Pode parecer óbvio agora, mas o polimorfismo é muito útil, principalmente quando entra o uso das interfaces.
Tags: Conceitos · Tecnica de Programação
Mais uma parte da série Conceitos de Orientação a Objetos, com Daniel Moreira Yokoyama:
Herança (ou derivação)
Você criou um sistema de loja virtual que vende cd’s. A orientação a objetos te permitiu criar uma classe CD, onde vocÊ agrupou todos os dados que dizem respeito aos CD’s: Título, Artista, Lista de músicas, Ano de lançamento, Gravadora, etc.
Após alguns meses no ar, seu cliente lhe diz que pretende expandir seu negócio para vender DVD’s. Isso vai exigir um esforço imenso de criar novas rotinas e novos tratamentos para cuidar de um ítem completamente novo ao sistema.
Para que se possa entender os reais motivos de tal apêlo da Orientação a Objetos em busca da reusabilidade, este cenário nos faz entender perfeitamente os problemas que a falta dela implicariam. É claro que, do ponto de vista arquitetônico, este panorama está sendo observado sob uma perspectiva inversa da ideal. Mas o ideal é algo atingido pela experiência.
Com a experiência que é adquirida ao longo do tempo usando a orientação a objetos, o profissional é capaz de, mesmo sem ter a menor idéia do plano de expanção do sistema (o cliente poderia decidir vender livros ou eletrônicos), prever que os pontos cruciais para uma possível derivação.
A derivação na OOP acontece através de herança. Uma classe herda (ou deriva) as características de uma outra, passando a conduzir todo o grupo de informações que a outra já fazia e, além disso, implementando características específicas.
No caso apresentado, poderia ser criado uma classe base produto, que possuiria o que todos os produtos de uma loja precisam ter: Preço, Descrição, código.
Uma segunda classe, CD, seria criada, herdando as características de Produto, mas implementando dados específicos do CD, como o Título, o nome do Artista, Gravadora, e ano de gravação.
Desta forma, a inclusão do novo negócio, fôsse DVD, fôsse livro, fôsse eletrônicos ou instrumentos musicais, seria bem menos trabalhosa.
A técnica de criar classes bases para derivar outras classes vêm da experiência do uso da Orientação a Objetos e da arquitetura de software. No começo é impossível não haver algum retrabalho ao notar que partes de determinadas classes seriam mais aproveitáveis se estivessem centralizados em uma classe base para ser extendido por outras classes herdeiras. Com o tempo esse tipo de percepção se torna mais fácil antes mesmo de implementar a aplicação.
Dica: Tente sempre abstrair os conceitos. Uma loja de CD é, antes de tudo, uma Loja. Se começar por aí vai entender que uma Loja vende Produtos. Um controle de estoque de Bebidas é, antes de qualquer coisa, um controle de estoque. Ao pensar desta forma você estará sempre deixando seu sistema facilmente extensível para outros tipos de expanções que seu cliente possa se interessar em fazer.
Tags: Conceitos · Tecnica de Programação
Pelo Twitter o Y. Z. MERCAN aka @eddai me contactou e hoje o ABAP101.com está no site Get Updates From Best SAP Sites.
É o ABAP101.com em águas internacionais!
Tags: Blogroll
Quanto eu começo o nosso treinamento ABAP na KA Solutions, eu já aviso que na primeira apostila não seguirei a ordem das unidades. Por questões de didática, já começo mostrando algumas características do ambiente ABAP e já começamos com um simples programa ABAP (o famoso Hello World!).
No entanto, por questões de logística, não podemos alterar radicalmente da forma como gostaríamos. Por exemplo, um assunto vital que precisa ser entendido logo no começo é dicionário de dados do ABAP.
Então aqui, vou fazer uma introdução sobre dicionário de dados.
[Read more →]
Tags: Dicionário de Dados
Agora a parte 3 da série Conceitos de Orientação a Objetos, com Daniel Moreira Yokohama:
Encapsulamento
Alguns métodos não conseguem por si só resolverem sua responsabilidade sem que algumas informações sejam previamente informadas. Uma pesquisa no Google não pode retornar valores se não receber algo por que buscar. Um pedido não é capaz de incluir produtos em si sem saber quais produtos o cliente quer adquirir. Estas informações podem ser encontradas espalhadas pelo sistema de acordo com o estado dos objetos na memória no momento em que o método é acionado. Porém, quando um método depende desse tipo de informação seu funcionamento é arriscado, pois as informações que procura podem não estar lá.
A forma mais segura de fazer com que o método funcione de forma segura é entregá-lo prontamente todas as informações que ele necessita para fazer o que precisa ser feito. Um método que envia um e-mail para o cliente, informando o status de sua compra, não tem garantias de que vá funcionar se tiver que procurar sozinho todas as informações (que cliente, qual status), ou irá funcionar com limitações pois, por mais que ele saiba procurar pelos dados em um banco, não será capaz de cumprir o mesmo propósito se em determinadas entregas a loja contratar um serviço 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 método se resolver por si só fazendo tudo o que ele tem que fazer e nada além disso. Invés de procurar pelo cliente no banco de dados, ele recebe os dados do cliente através de parâmetros e deixa que a busca pelos dados do cliente seja feita por outro objeto que possua essa responsabilidade (método).
Outra regrinha do encapsulamento, é que os objetos devem ser responsáveis por si. Soberanos na administração 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 inválido (como -1, por exemplo) o próprio objeto pessoa saiba se defender. Isto torna a inteligência do objeto centralizada em um único lugar, nele mesmo, o que fará com que sua administração seja independente dos outros objetos que compõem a arquitetura do sistema.
Exceções
Digamos então que o objeto pessoa receba um valor inválido para ser atribuído na propriedade Idade. Como tratar este problema? O Objeto pessoa pode ignorar a ordem. OU exibir uma mensagem na tela. Mas e se for imprenscindível para o objeto externo saber que a atribuição tenha ocorrido com sucesso? E se o sistema estiver rodando num serviço windows e não existir uma tela para exibir a mensagem?
O conceito de tratamento de exceções estruturadas não é necessariamente parte da orientação a objetos, mas ele foi muito bem vindo no panorama atual de desenvolvimento de software. Uma exception é uma situação inesperada que é arremeçada por um método invocado, direcionada para o método que o invocou.
Por exemplo: o motorista do caminhão não encontrou ninguém no endereço que o cliente informou, que pudesse receber a encomenda. Ele então lança a exceção para seu superior imediato, o método 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 não tiver ele repassa ela para o próximo superior da pilha. O método que o invocou. O gerente de contas da loja vai verificar que passou o endereço do cliente errado e corrigí-lo ou concluir que não possui o endereço correto e acionar o cliente para se informar a respeito.
Ao resolver o problema, todos são acionados novamente até que o motorista tente fazer uma nova entrega.
Assim funciona o tratamento de exceções na OOP. Seus métodos podem receber exceptions que descrevem situações inesperadas. Se não houver implementação de tratamento para elas, eles a lançam (throw) para o método que os chamou, até chegar no topo da pilha (no caso, o núcleo do sistema) resultando em um erro, que irá interromper todo o sistema.
Por isso é importante identificar que tipos de situações inesperadas um método pode resolver. Um método que tenta se conectar ao banco, por exemplo, pode receber uma exception dizendo que o banco não está no ar. Se o banco não está no ar, e a responsabilidade dele é se conectar ao banco, então é responsabilidade dele tratar esta exception sem repassá-la ao método que o chamou. Mas se um método que precisa enviar um e-mail receber uma exception descrevendo erro de divisão por zero, isso não é problema do método em questão. Ele não precisa tratá-lo. Ele repassa para o método que o chamou até que se torne claro para alguém (através de uma mensagem de erro no sistema) que algum método deixou de fazer o tratamento antes de chegar no método que envia os e-mails.
Tags: Conceitos · Tecnica de Programação
Segue a parte 2, da série Conceitos de Orientação a Objetos, de Daniel Moreira Yokoyama:
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ê almoça. Ou na casa de um amigo seu. Note que cadeiras possuem diversas variações de forma que é quase impossível encontrar duas cadeiras de dois ambientes distintos que sejam parecidas.
[Read more →]
Tags: Conceitos · Tecnica de Programação
Há muito tempo venho ensaiando escrever uma série de textos sobre Orientação a Objetos. Mas, um dos meus alunos de ABAP, com ampla experiência em .Net e OO, autorizou a publicar uma ótima referência conceitual sobre o tema.
Começo uma série de posts, em 6 partes, sobre conceitos de orientação a objeto. Não é nada voltado a nenhuma linguagem, mas conceitos puros.
O autor desse texto muito bom, foi um dos meus alunos da Academia ABAP, na 15a Turma na KA Solution, Daniel Moreira Yokoyama. Se você quizer entrar em contato com ele, mande um e-mail para blog arroba abap101 ponto com.
Daniel, muito obrigado pelo seu texto!
Segue abaixo, o texto na íntegra:
[Read more →]
Tags: Conceitos · Tecnica de Programação
Para treinar um pouco do inglês e relembrar da história da internet, veja essa esse vídeo. Excelente vídeo mostrando os princípios da internet, seu nascimento e evolução. Enjoy!
[Read more →]
Tags: Weekend
Já falei uma centena de vezes que aprender uma nova tecnologia sempre ajuda. Mais uma vez Rails trazendo ventos novos para o lado do ABAP, agora com o chamado ActiveRecord.
Quando estava na Accenture, trabalhando com uma iniciativa de biblioteca de componentes digitais, estávamos pensando em componentes para ABAP. Uma das coisas que sempre sonhei era um conjunto de classes onde teríamos encapsulado os comandos de SQL.
Não foi para frente a minha idéia por vários motivos, mas principalmente falta de ousadia da minha parte para fazer as classes e começar a usar.
A idéia ficou no porão do meu cérebro por muito tempo, até eu conhecer o ActiveRecord do Rails.
Tags: ABAP OBjects
