Utilizando Classe no Access - Orientação a Objetos
Utilizando Classe no Access – Orientação a Objetos
Para vencer esta dificuldade começaram a ser desenvolvidas as linguagens de alto nível, mais próximas da linguagem humana, cuja sintaxe de comandos são palavras, inteiras ou abreviadas, em inglês. Até aí os programas eram desenvolvidos de forma linear, um comando depois do outro, e assim eram executados. Era a programação linear.
Com o aumento da complexidade dos softwares, pesquisadores começaram a se preocupar com a estrutura dos programas, de forma que ficasse mais fácil criar programas ainda mais complexos, pois a programação linear era muito difícil de ser corrigida, já que o programador freqüentemente se perdia em meio aos desvios e loops existentes. A partir do aperfeiçoamento e adequação das linguagens de alto nível, tornou-se possível desenvolver programas baseados em funções agrupadas em módulos, onde cada módulo era responsável por determinadas funções, e o conjunto de módulos formava o sistema completo. Eis que surge a programação estruturada. Este tipo de abordagem seguiu dois caminhos principais, a programação orientada a funções, onde a base do projeto do software eram os processos necessários à execução das tarefas, e a programação orientada a dados, no qual o projeto do sistema era baseado no modelo de dados. Alguns autores acreditam que a abordagem nos dados é melhor, pois funções são baseadas nas regras do negócio, e regras mudam constantemente, já os dados sofrem muito menos alterações no mesmo período de tempo, por isso apresentam maior consistência.
O paradigma estruturado resolveu grande parte dos problemas por um bom período. As críticas apareceram quando desenvolvedores do mundo todo perceberam que ainda era muito difícil realizar manutenção ou extensão dos softwares estruturados. Não se chega a um consenso sobre o motivo, alguns afirmam que isto se deve à falta de documentação, outros alegam falta de preocupação com a análise e o projeto. Contudo, todos concordam que ele não conseguia atender à crescente demanda por sistemas de grande complexidade, e que exigiam prazos reduzidos para conclusão, além de possibilitar a manutenção e a extensão de pontos específicos do sistema sem que isto afetasse tanto os outros componentes. Em grande parte dos sistemas estruturados, seria mais fácil recomeçar do zero do que realizar uma alteração bem sucedida.
A proposta que alcançou o nível mais próximo do ideal foi a de tratar os sistemas como eles realmente são. Qualquer software é, na verdade, uma representação da realidade, e o mundo real é composto de objetos independentes que se relacionam. Os objetos possuem características e realizam ações próprias, que os diferenciam dos demais. Alguns objetos possuem características e realizam ações similares, por isso podem ser facilmente agrupados em um tipo de objeto, um modelo que serve de referência para qualquer objeto deste tipo.
A partir do estudo dos objetos surge a programação orientada a objetos, um novo paradigma cuja idéia principal é a de modelar os sistemas considerando que cada classe de objetos possui características (dados) e realizam ações (funções) próprias.
O sucesso da POO se deve ao fato de que representando o problema como objetos fica bem mais fácil analisar e compreender a complexidade de qualquer sistema, tanto os mais simples quanto os mais complexos, os quais a PE não conseguia representar com a fidelidade e a simplicidade desejadas. Na POO uma alteração realizada em uma classe geralmente não afeta o restante do software, então a manutenção ou a extensão se resume a alterar o ponto desejado.
A POO introduziu vários conceitos novos, além de utilizar alguns já existentes, mas que ganharam um novo sentido. Para compreender melhor um sistema OO é importante conhecer pelo menos alguns deles.
Objeto => qualquer indivíduo, lugar, evento, coisa ou conceito aplicável ao sistema, sobre o qual se deseja armazenar informações, ou que seja necessário ao desenvolvimento do software
Ex: Um gato é um objeto, uma televisão é um objeto, um carro é um objeto, um cliente é um objeto, um relatório é um objeto, um documento de texto é um objeto, etc.
Classe => grupo de objetos similares, utilizada para definir um objeto apenas uma vez. Imagine uma empresa com 1.000 clientes, tendo que modelar um objeto para cada cliente. Ao invés disso modelamos uma classe Cliente, que é a base para a criação de um objeto. A classe contém todas as informações que precisamos para construir um objeto.
Ex: Todas as características que um gato possui, e ações que ele executa são modeladas na classe. Quando criarmos o objeto gato usaremos as informações da classe para isto.
Normalmente modelamos graficamente uma classe como um retângulo dividido em três partes. A primeira contém o nome da classe, a do meio os atributos, e a inferior os métodos.
Interface => Modelo contendo os métodos obrigatórios que deverão ser implementados em uma classe. A interface não implementa nenhum dos métodos, mas contem a assinatura de cada um deles, ou seja, define os nomes, os parâmetros de entrada e os tipos de dados de retorno dos métodos que a classe deverá obrigatoriamente implementar.
Instância => É o objeto criado a partir da classe. Cada objeto criado é uma instância da classe
Abstração => Quando modelamos a classe não utilizamos, na verdade, todas as características do objeto, e sim apenas aquelas que tem alguma relação com o sistema a ser desenvolvido, ou seja, apenas aquilo que interessa. Quando escolhemos as características e ações que são importantes estamos abstraindo as informações do objeto a ser modelado.
Ex: Quando modelamos uma classe Cliente para uma farmácia não precisamos saber, por exemplo, o número do sapato ou do manequim do cliente. Já em uma loja de moda estas informações já seriam relevantes. Para decidir quais ações ou características são relevantes devemos fazer a abstração do objeto dentro daquele determinado propósito.
Atributo => São as características que o objeto possui. Para um objeto Cliente teríamos como atributos o nome, o CPF, o endereço, etc. Atributo é tudo aquilo que deva ser lembrado sobre o objeto.
Método => É tudo aquilo que o objeto é capaz de fazer. Um objeto Aluno pode, por exemplo, solicitar matrícula, realizar exame, ser reprovado, etc.
Persistência => É a capacidade de um objeto manter suas informações por tempo indeterminado. Em outras palavras um objeto é persistente quando ele foi salvo, ou gravado, em um meio físico, para que possa ser recuperado posteriormente.
Mensagem => Como no mundo real os objetos precisam da ajuda de outros objetos para realizarem suas funções. Um objeto Aluno, quando solicita trancamento de matrícula, precisa da ajuda do objeto Coordenação para realizar esta tarefa. Para que isto ocorra ele deve enviar uma mensagem ao objeto Coordenação informando seu desejo de trancar a matrícula. Na prática, a troca de mensagens se dá pelas chamadas de funções (métodos) das classes dentro do sistema.
Encapsulamento => Um dos maiores benefícios da OO é a possibilidade de escondermos do mundo externo o modo como são implementados os atributos e os métodos de uma classe. Para que um objeto solicite uma informação de outro, ou solicite a execução de uma ação, ele não precisa saber como ela se dará realmente, pois apenas o resultado interessa.
Ex: Como ilustração podemos citar o sistema de frenagem dos carros. Para que um objeto Carro freie nós sabemos que basta pisar no pedal de freio. Como estão organizadas as engrenagens, mangueiras, pastilhas e discos não interessa. O sistema de freio de um carro popular é diferente do sistema de um carro de luxo com ABS, por exemplo, mas nos dois casos o motorista não precisa saber disso para frear, basta pisar no pedal e a ação frenagem será executada, resultando na parada do carro.
Herança => Um objeto pode herdar características ou funções de outro. Em um sistema escolar encontramos a necessidade de modelar duas classes distintas, Aluno e Professor, pois cada um deles possui informações e executam ações diferentes um do outro, mas também possuem similaridades, como nome, endereço, entre outras. Para evitarmos que uma eventual alteração neste tipo de dado seja feita em mais de um local, podemos modelar uma classe chamada Pessoa, que contenha os atributos comuns a Aluno e Professor, em seguida fazemos com que Aluno e Professor herdem estas características de Pessoa. A regra também vale para quando temos uma classe que possui os mesmos atributos e executa as mesmas ações de outra, mas de uma maneira diferente. Para isto utilizamos a herança em conjunto com o polimorfismo.
Polimorfismo => Capacidade que as classes tem de possuir atributos ou métodos iguais, mas que executam suas ações de maneiras distintas, devendo ser implementadas separadamente. Conforme descrito no caso anterior, a segunda classe herda todos os atributos e métodos da primeira, e redefine os atributos e métodos próprios, mantendo o mesmo nome. Quando um objeto externo enviar uma mensagem a ação executada será aquela correspondente à classe para a qual a mensagem foi enviada. Em resumo, polimorfismo ocorre quando ações diferentes podem ser executadas a partir do mesmo comando, ou seja, quando da chamada de um mesmo método cada objeto responde a sua maneira.
Ex: Imagine os objetos piano e flauta. Os dois teriam o método tocar(), mas cada um executaria o método de maneira diferente.
Uma das principais vantagens da programação orientada a objetos é, com certeza, a possibilidade de reutilização de códigos em vários sistemas distintos. Assim como já é de praxe em outras áreas do conhecimento a padronização permite que componentes genéricos de software sejam construídos e possam ser utilizados diretamente em uma infinidade de outros sistemas. Algumas vezes a utilização direta não é possível, mas nestes casos em geral basta uma pequena adaptação. Para isto já existem soluções prontas como o conhecido padrão de projeto Adapter, que tem por finalidade acoplar dois ou mais diferentes objetos de software. Além do padrão de adaptação existem diversos outros que atendem às mais diversas finalidades dentro da modelagem e programação de objetos.
Com a criação de padrões internacionais, como no caso da OO, ocorre uma maior facilidade de envolvimento entre desenvolvedores do mundo todo, acelerando tanto o desenvolvimento de sistemas complexos quanto a disseminação de novas técnicas para solução de problemas até então obscuros.
Uma outra vantagem dos sistemas OO é que, em geral, "possuem uma divisão de código um pouco mais lógica e melhor encapsulada do que a empregada nos sistemas não orientados a objetos, o que torna a manutenção e extensão do código mais fácil e com menos riscos de inserção de bugs. Também é mais fácil reaproveitar o código." (David, 2007)
Ainda segundo David (2007), é mais fácil gerenciar o desenvolvimento deste tipo de software quando temos uma equipe grande. Podemos fazer uma especificação UML antes de iniciar o desenvolvimento do software em si, e em seguida dividirmos o sistema em classes e pacotes, e cada membro da equipe pode ficar responsável por desenvolver uma parte do sistema. Com isto o software ganha uma sobrevida maior que os sistemas estruturados, pois a sua manutenção e até mesmo a sua extensão tornam-se mais fáceis de se implementar.
O maior dos entraves para a adoção da OO nos sistemas atuais está no aprendizado dos conceitos referentes à metodologia, que são complexos e requerem maturidade e massificação de conhecimento do indivíduo.
A correta aplicação dos conceitos requer bastante prática e esforço mental para assimilação e abstração das características do mundo real, o que muitos não estão dispostos a enfrentar. Ao contrário da programação procedural tradicional, na qual "basta decorar meia dúzia de comandos e você já consegue fazer um programa simples", de acordo com David (2007). Na OO conceitos como herança e polimorfismo, entre outros, geralmente causam um nó na cabeça dos iniciantes.
Além do problema do aprendizado, a programação orientada a objetos exige mais do hardware, como capacidade de processamento e memória. É claro que a programação orientada a objetos não pode se comparar, em desempenho, com outros tipos de linguagens procedurais ou lineares. Porém com o avanço da tecnologia de hardware esta perda de desempenho é facilmente compensada pela velocidade e capacidade dos atuais processadores e outros dispositivos de hardware.
Devido a sua complexidade a metodologia orientada a objetos não é indicada para a produção de pequenos sistemas, pois a quantidade de trabalho inicial necessária não compensa o esforço. Porém na medida em que o software cresce as vantagens começam a aparecer. Quanto maior fica o sistema, mais a metodologia se paga, em todos os aspectos.
AMBLER, Scott W. Análise e Projeto Orientado a Objeto, volume II: seu guia para desenvolver sistemas robustos com tecnologia de objetos.
Rio de Janeiro, Infobook, 1998.
BOCTOR, David. Microsoft Office 2000 Visual Basic for Applications - Fundamentos.
São Paulo, MAKRON Books, 2001.
DAVID, Marcio Frayze. Programação Orientada a Objetos: uma introdução. 2007. Disponível em: <http://www.guiadohardware.net/artigos/programacao-orientada-objetos>
Acesso em 16 de maio de 2010.
DEBONI, José Eduardo Zindel. Modelagem orientada a objetos com a UML: técnicas de análise, documentação e projeto de sistemas. São Paulo, Futura, 2003.
Orientação a objetos. Definição e conceitos essenciais. Disponível em:
<http://pt.wikipedia.org/wiki/Orienta%C3%A7%C3%A3o_a_objetos>.
Orientação por Objetos: Vantagens e Desvantagens. 2008. Disponível em: <http://wpjr2.wordpress.com/2008/04/23/orientacao-por-objetos-vantagens-e-desvantagens/>.
clementor 12/10/2015 04:13:05
muito obriga ia tirando um zero na avaliação
Márcio Melo - Rio de Janeiro/RJ 28/05/2010 21:33:05
Gostei da introdução, temos que saber até onde podemos ir com o access, e admitir os limites em pequenas e médias aplicações, mais como deixou bem claro em grandes projetos a POO terá a vantagem das heranças e Polimorfismo, etc... quando se tratar em manutenção e continuidade. Mais tudo tem seu custo e benefício. Na verdade quanto mais evoluímos (digo nas empresas q vão se expandindo) maior a demanda em processos que sejam mais velozes e de fácil emprementos, o gerenciamento e planejamento das ações se tornam prioritários para continuar crescendo. Estarei acompanhando esse rico curso online, obrigado... Sou mais Brasil!
Plinio Mabesi - GO 28/05/2010 13:11:29
Obrigado a todos. Vejam que já saiu o segundo artigo. Semana que vem tem mais...
Torres Forte 28/05/2010 12:36:12
gostei muito... estou grato por vc esta compartilhando esse material,
vc tem esclarecido muitas duvidas ate agora...
vou acompanhar esses artigos
Valdino 27/05/2010 09:05:09
Cleber Viana será o mesmo da comunidade "Casa dos Violeiros"? Se for, não sabia de seu interesse palo Access, rsrsrs.
Quanto aos ensinamentos aqui, realmente estão de parabens. Como disse o Sampaio, nossos forums estão carentes de instruções mais detalhadas sobre o assunto.
Marcio 24/05/2010 23:31:39
meus parabens pela sua colaboração
nesse assunto muito interessante.
Plinio Mabesi - Anápolis-GO 23/05/2010 20:18:13
Obrigado a todos novamente. Eu já tenho imenso prazer em cooperar para o aprendizado dos colegas, mas quando nosso trabalho é reconhecido a recompensa é multiplicada.
Continuem conosco que a série mal começou. Nossa meta (minha e do Avelino) é entregar pelo menos um artigo da série a cada semana. Com certeza depois desta virão outras.
Gilson Tomazina - PR 21/05/2010 14:36:39
Avelino show parabens pela parceria, espero um dia poder ajudar, ser como voce, levar o conhecimento, com essa didatica simples, parabens mesmo, sucesso Plinio
CLEBER VIANA 21/05/2010 11:47:42
Parabéns pela iniciativa de ensinar aquí a POO. Esta primeira aula está "enxuta", com explicações e exemplos muito fáceis de entender para quem já vem desenvolvendo há algum tempo.
Acho que os que não utilizam a metodologia, se dedicarem, irão melhorar e muito seus sistemas.
Aos iniciantes que entenderam pouco ou nada, uma dica: Leiam de novo, tentem aplicar ... Leiam de novo e de novo... Vale a pena.
MSampaio 21/05/2010 11:34:56
Avelino, este item pelo menos para mim é o de menor exclarecimento dentro access, basta ver nos fóruns que fazendo as buscas por classes muito pouco ou nada é retornado.