Usando Access

Utilizando Classe no Access – Orientação a Objetos

Nota importante: para ter acesso aos vídeos e arquivos exemplos deste site, adquira um dos planos apresentados abaixo. Você pode comprar em até 2x no Cartão de Crédito, através do Paypal. 

Veja como comprar e saiba mais sobre o material oferecido,  clicando aqui.

Por: Plinio Mabesi

Desde o surgimento da computação, as técnicas de programação e desenvolvimento de sistemas sofrem modificações, geralmente para melhor, a cada período de tempo.

No início os computadores eram programados diretamente no hardware, através de fios e interruptores, que eram conectados de acordo com a ocasião. Com a evolução dos equipamentos, e o conseqüente aumento das necessidades de processamento, surgiram as primeiras linguagens de programação, ainda de baixo nível, como o Assembly, de difícil compreensão, por ser muito próximo da linguagem do computador.

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.

Conceitos Básicos

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.

Vantagens da POO

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.

Desvantagens da POO

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.

Artigos Relacionados

Utilizando Classe no Access - Introdução

Utilizando Classe no Access - Parte 1 - Orientação a Objetos

Utilizando Classe no Access - Parte 2 - Programação OO no Access/Vba

Utilizando Classe no Access - Parte 4 - As Classes Auxiliares

Utilizando Classe no Access - Parte 5 - A Classe Cliente

Utilizando Classe no Access - Parte 6 - A Classe Produto

Utilizando Classe no Access - Parte 7 - As Classes Venda e Detalhe de Venda

Utilizando Classe no Access - Parte 8 - Finalização do Sistema

Utilizando Classe no Access - Parte 9 - Genesis: A Ferramenta Case

Utilizando Classe no Access - Parte 10 - Conclusão

Como estudar com o Pesquisador de Objetos

| Home | Vídeos | Tutoriais | Dicas | Ribbons | Suporte | Downloads | Contato | Artigo |