Por exemplo, podemos usar um inteiro para armazenar tempo e um método para adicionar tempos. Podemos também usar um inteiro para armazenar cores...
... podemos também aplicar o método para adicionar tempos sobre as cores...
esse engano não será encontrado antes da execução do programa, quando ele não funcionar conforme o esperado.
Em Java, criando os objetos cor e tempo, este com o método que adiciona, a linguagem não permitiria aplicar esse método sobre o objeto cor. O engano não ocorreria.
Conceitualmente, objetos são uma evolução sobre tipos abstratos de dados pois estes encapsulam dados juntos e métodos em separado, o que possibilita o engano do exemplo. Cronologicamente há quem afirme que os conceitos foram concebidos na mesma época.
Essa definição de "objeto" em linguagens de programação conserva muitas analogias com objetos do "mundo real". Instrutores de linguagens orientadas a objetos costumam aproveitar-se dessa analogia para apresentar linguagens orientadas a objetos (e assim o farei), o aprendiz deve ter em mente que isso não é necessário - é apenas um recurso didático.
A partir de agora trataremos apenas de objetos em linguagens de programação. Estes contém variáveis que geralmente armazenam características do objeto e por isso chamadas atributos e o objeto pode tanto agir quanto receber ações, codificadas em métodos.
Por exemplo, pense nos seguintes problemas:
- "Você quer comprar uma mesa de trabalho e quer escrever um programa que busca candidatas. Como representar uma mesa de trabalho nesse programa?";
- "Representar uma mesa de trabalho em um programa para um site de vendas";
- "Representar uma mesa de trabalho em um simulador gráfico de ambiente de trabalho".
Linguagens orientadas a objeto facilitam ao programador focar nos aspectos essenciais dos objetos e em O QUE ele faz, adiando a especificação sobre COMO ele faz. Em determinadas circunstâncias convém ocultar COMO o objeto faz e mostrar O QUE ele faz. Seja por esse conhecimento não ser relevante a quem vai usá-lo, seja por manter a implementação sob sigilo.
O ocultamento bem usado permite a modificação de objetos sem necessidade de alteração do código que USA esse objeto, ou seja, auxilia na construção de módulos independentes.
Da forma como um objeto (em programação) é definido, determinar que atributos e métodos tem equivale a responder às perguntas informais:
- o que (que atributos) o objeto tem?
- o que o objeto faz (ou o que fazem com o objeto, ou ainda como interagir com o objeto)?.
Em todos os exemplos apresentados aqui e em quase todos os programas deseja-se atribuir ou modificar os valores dos atributos durante a execução do programa, não durante a codificação. Isto é feito generalizando objetos em classes.
Classes são definições suficientemente genéricas dos objetos que deseja-se representar (quanto é suficiente depende da aplicação). Por exemplo, em algum dos problemas a cor do tampo não é relevante (e por isso escolhemos não representá-la), ou a cor é sempre 'azul' (podemos optar por deixar implícito ou representar como uma constante) ou pode ser importante armazená-la e modificá-la (se for um conjunto pequeno de cores, um caracter pode ser suficiente, se for toda a paleta do computador, um RGB armazenado em 24 ou 32 bits,...).
Usando o conceito de classes, objetos são instâncias, que são construídas (alocadas em memória e inicializadas) usadas e destruídas (apagadas e liberadas da memória).
Nota: Linguagens orientadas a objeto como Java não são computacionalmente mais poderosas que linguagens procedurais como Fortran, mas podem ser mais práticas para determinados usos.
----- anotações dispersas ----
São elementos característicos da orientação a objetos:
instanciação;
construtores;
herança;
- polimorfismo;
- classes abstratas e interfaces;
- vinculação tardia;
destrutores;
Uma forma de representar classes e relações entre classes é o diagrama de classes, que é um tipo de diagrama UML (Unified Modeling Language).
É possível usar as relações entre classes de forma a aproveitar certa propriedade e resolver determinados problemas. Essas soluções foram catalogadas e suas propriedades foram elicitadas em padrões de projeto (design patterns), foco da disciplina ACH2003-Computação Orientada a Objetos.
Nesta disciplina estudaremos o padrão Decorator para ilustrar um uso menos intuitivo de herança. Este padrão é muito usado nas classes de Java que fazem acesso a arquivos.
Herança "poupa" codificação - isto é "verificável" usando a interface Serializable.
Nenhum comentário:
Postar um comentário