005 – Conceitos Típicos de POO – Programação Orientada a Objetos

Playlist do Curso de Programação Orientada a Objetos POO

Conceitos típicos da POO

Cliente, servidor e mensagens
Da passagem de mensagens entre objetos: o cliente (um objeto) emite uma mensagem para o servidor (outro objeto) em que solicita um serviço (i.e. que uma rotina qualquer seja executada) que pode implicar a emissão/retorno de uma resposta ao cliente. Um servidor pode ser cliente de outros (sub-)servidores. Esta resposta pode ser síncrona (quando o cliente aguarda a resposta do servidor para executar qualquer outra instrução) ou assíncrona (envolvendo paralelismo de atividades).

Um exemplo simples: um instituto (cliente), solicita um buffet para uma empresa especializada (servidor). Esta empresa (agora cliente) solicita salgados e sucos de outras empresas (sub-servidores). O instituto pode ficar paralisado enquanto não chega o buffet (envio síncrono de mensagem) ou continuar suas atividades (envio assíncrono de mensagem). Neste último caso, o instituto deve ser capaz de lidar com a interrupção das atividades (ou parte delas) assim que chegar o buffet.

A existência/espera de uma resposta pode ser inerente ao modelo de envio da mensagem ou ser realizada através do disparo de uma nova mensagem pelo servidor.

Responsabilidades
A um servidor e seus métodos são atribuídas responsabilidades específicas. No exemplo anterior, a empresa de buffet não deve entregar um brinquedo, e a comida deve ser apropriada (não apenas várias barras de chocolate, por exemplo).

Uma responsabilidade que todos os servidores tem é a de manter seus dados consistentes. Idealmente, não deve ser possível tornar inconsistentes os dados de um objeto. Um objeto tem a responsabilidade de manter uma boa interface para se comunicar com outros objetos.

Outra responsabilidade genérica e usual é a de que as operações tenham um sentido razoável. Por exemplo, se um cliente envia uma mensagem que satisfaz alguma pré-condição, é obrigação do método ativado retornar um resultado que reflita a pós-condição.

Modularidade centrada nos dados
A modularidade de um programa é uma medida que reflete o quanto ele é composto por partes separadas (chamadas de módulos). Na POO, a modularidade é preferencialmente (ou basicamente) centrada das TADs, o que pode ser chamado de modularidade centrada nos dados e possui as seguintes características:

um módulo é construído encapsulando dados que representam um único conceito.
Alto grau de coesão.
A visibilidade (dos atributos e métodos) pode ser controlada.
O módulo pode ser utilizado com um tipo de dado.
Reuso
Enquanto na PE há bibliotecas de rotinas (procedure libraries), na POO há bibliotecas de classes, que podem (até certo ponto, em geral, etc) serem compreendidas com conjuntos de TADs reutilizáveis. Desafios para a reusabilidade:

Descobrimento: onde está o componente e como acessá-lo?
Entendimento: o que o componente oferece e como encaixa em um programa?
Modificação: quando e como o componente deve ser modificado?
Integração: como organizar e usar o componente em conjunto com outros componentes.
Nota: a modificação deve ser usada com cuidado. A modificação direta da rotina ou objeto implica dificuldades quando alguma versão nova da biblioteca é utilizada. Preferencialmente, as modificações devem ser feitas de forma modular, i.e. separando as contribuições locais das originais. Na POO, a herança ameniza este problema. Veja também o aberto/fechado.

Ação nos objetos
As ações devem sempre ser realizadas através de algum objeto.

‘Não pergunte o que um sistema faz, pergunte o que ele faz a que’ (Meyer[2])
Ações em geral:
implementadas por chamadas de procedimentos.
com frequência, mas não sempre, parametrizadas (com parâmetros de entrada).
Ações em objetos:
ativadas via mensagens.
uma mensagem sempre possui um objeto receptor
uma mensagem é similar a uma chamada de procedimento com ao menos um parâmetro
uma mensagem ativa uma operação (um método).
o objeto receptor identifica a operação apropriada (busca/lookup de método)