MAC 413/5715 - Tópicos de Programação Orientada a Objetos

Aula 1 - 8/8/6

Conteúdo do Curso

padrões de projeto e arquiteturais (GoF, POSA)
expressões idiomáticas idioms
padrões de análise de software
Arcabouços
Programação Orientada a Aspectos
Reflexão Computacional
Programação Genérica

Metodologia de Trabalho

Aulas expositivas dadas pelo professor
Seminários apresentados pelos alunos
Discussão de textos
Exercícios em sala de aula e no laboratório
DesignFest (3 aulas)
PLoPIME (2 aulas)

Conceitos Básicos de Programação Orientada a Objetos (pré-requisitos)

objetos = estruturas de dados + código
classes (definem tipos)
herança
hierarquia de classes
herança simples vs. herança múltipla
classe abstrata vs. classe concreta
interface
UML, diagramas de:

classes
seqüência
colaboração
implantação

terminologia

método, função
chamada de função, invocação de método, envio de mensagem
subclasse, superclasse, mãe/parent, filha, subtipo, supertipo
generalização, especialização, especializar = to subclass
em C++, classe abstrata pura é *quase* uma interface

polimorfismo: capacidade de uma entidade de assumir múltiplas formas

mesmo nome de método mas com assinatura diferente
implementações diferentes para a mesma interface
paramétrico

tipos parametrizados, formas (templates), programação genérica (generic programming)
em C++: STL (Standard Template Library)
em Java: optaram por não colocar por simplicidade no início, entrou a partir do 1.5

herança de interface vs. herança de implementaçao
em Java: implements e extends
associação, agregação, composição
delegação (não é sinônimo de agregação)
sempre podemos escolher entre herança e delegação
arcabouços (frameworks) (veremos nesta disciplina)

pontos quentes (hot spots)

padrões de projeto de software (software design patterns )

Padrões Arquiteturais (POSA I, II e III)

Pattern-Oriented Software Architecture

POSA I: A System of Patterns
POSA II: Patterns for Networked and Concurrent Objects
POSA III: Patterns for Resource Management

Ao escrever um padrão, veja se você tem bem claro 3 coisas que devem estar contidas na descrição do padrão:

Contexto: uma situação que leva a um problema
Problema: um problema recorrente que acontece em determinada situação
Solução: uma solução comprovada para problema

Os padrões do POSA I se dividem em 3 grupos:

Architectural Patterns (alto nível)

Da lama à estrutura

Layers
Pipes and Filters
Blackboard

Sistemas Distribuídos

Broker

Sistemas Interativos

Model-View-Controller
Presentation-Abstraction-Control

Sistemas Adaptáveis

Microkernel
Reflection

Design Patterns (nível médio)

Decomposição Estrutural

Whole-Part

Organização de Trabalho

Master-Slave

Controle de Acesso

Proxy

Gerenciamento

Command Processor
View Handler

Comunicação

Forward-Receiver
Client-Dispatch-Server
Publisher-Subscriber

Idioms (baixo nível)

Counted Pointer

Padrão de Projeto: Publisher-Subscriber

É na verdade o Observer (293) do GoF.
O POSA o inclui para descrever variantes interessantes do padrão
Problema:

em alguns sistemas, os dados mudam em um certo lugar e vários objetos em outras partes do sistema dependem daqueles dados; é necessário então, utilizar algum mecanismo para informar os dependentes das mudanças.
poder-se-ia introduzir chamadas explícitas do objeto cujo estado mudou para os seus dependentes, mas esta solução não é flexível nem reutilizável.
precisamos de um mecanismo de propagação de mudanças que possa ser aplicado em vários contextos
A solução tem que equilibrar as seguintes forças:

um ou mais objetos tem que ser notificados sobre mudanças em um objeto
o número de dependentes não é conhecido a priori e pode até mudar dinamicamente
fazer com que os dependentes peguem o estado de tempos em tempos (polling) é muito caro
o objeto que provê o dado e aqueles que o consomem não devem ser fortemente acoplados

Solução:

O objeto que contém o dado que interessa é chamado de Publisher (subject no GoF)
Os objetos dependentes são chamados de Subscribers (observers no GoF)
O publisher mantém uma lista dos objetos registrados que são aqueles interessados em receber notificações sobre as mudanças.
O publisher oferece uma interface para manifestação de interesse (subscribe interface)
Quando o estado do publisher muda, ele envia uma notificação para todos os objetos que manifestaram interesse.
Ao receber uma notificação, o subscriber decide se solicita a informação ao publisher ou não.

Há vários graus de liberdade ao implementar o padrão:

pode-se utilizar classes abstratas para implementar o comportamento básico do padrão
o publisher pode decidir quais partes do seu estado interno serão notificadas
o publisher pode decidir enfileirar as mudanças de estado antes de enviar as notificações
um objeto pode se inscrever em vários publishers
um objeto pode ser simultaneamente publisher e subscriber
inscrição e notificação pode ser filtrada de acordo com o tipo de evento gerado, ou tipo de dado que foi alterado
o publisher pode enviar junto com a notificação informações sobre o que mudou, ou não
Dois extremos:

modelo push (pouca flexibilidade mas possivelmente melhor uso da banda)
modelo pull (mais flexibilidade mas maior número de mensagens)

Referência

F. Buschmann, R. Meunier, H. Rohnert, P.Sommerlad, M. Stal Pattern-Oriented Software Architecture - A System of Patterns. John Wiley and Sons Ltd, Chichester, UK, 1996
A página do POSA na teia (mais focado no POSA II).
Resumo do POSA I na teia
www.posa3.org

Próxima Aula

Página de MAC 413/5715

Página do Fabio

Página do DCC