subject-oriented programming sérgio soares gente
TRANSCRIPT
Subject-Oriented Programming
Sérgio Soares
GENTe
Objetivo geral
Facilitar o desenvolvimento e a evolução de aplicações cooperantes que compartilham objetos
ou tipos! que contribuem para a execução das
operações
Deve ser possível
Desenvolver aplicações em separado e depois compô-las as aplicações não devem ter dependências explícitas
Adicionar uma nova aplicação na composição sem impacto nas demais nem nos objetos já persistentes sem precisar recompilar o sistema
Manter as vantagens de encapsulamento, information hiding, polimorfismo, e herança em todas as aplicações
Motivação
Como modelar (projetar) uma árvore?Quais seriam seus atributos?
Visão 1 - fonte de estudo
ArvorealturalarguranumeroFolhaspesoidadeespeciefamilia
Visão 2 - fonte de renda
ArvoreprecoVendametragemtempoCorte
Visão 3 - fonte de alimento
ArvoresaborvalorNuticional
Subject-Oriented ProgrammingCada visão pode ser vista como uma aplicação
cliente da definição de árvoreComo a programação orientada a objetos resolve
este problema? adicionando novas propriedades à definição de árvore
não haveria reuso (todas as propriedades em um único tipo) definindo subclasses para cada visão
as visões vêem árvores com diferentes propriedades e métodos, não faz sentido o reuso dos mesmos
Como integrar diferentes visões em um mesmo projeto?
Outros problemas de OO
Projetar classes antecipando (adivinhando) possíveis evoluções custo de planejamento/modelagem
Como obter reuso “máximo”?Tangled code
custo de manutenção e extensão
Subject-Oriented Programming Subject
coleção de classes pedaços de classes
atributos métodos
decompostos segundo um subject Regras de composição
como pedaços de aplicação (subjects) se compõe para criar uma aplicação outros subjects extender um sistema integrar sistemas
Subject-Oriented Programming
Dividir um sistema em subjects e escrever regras de composição para os mesmos
subject: A Operations: m() Classes: X with Variables: x1, x2; Mapping:Class X, Operation m() { ... }
subject: B Operations: n() Classes: X with Variables: x3; Mapping:Class X, Operation n() { ... }
Exemplo de regra de composição
Equate(App, <A,B>); compõe dois subjects. App é uma aplicação
Equate(operation App.o, <A.m, B.n>); define uma nova operação compondo duas
outras.
SOP permiteCriar extensões para e configurações de software
sem alterar o código fonte gerar várias versões de software (multiplataforma)
Customizar e integrar sistemas e componentes reusáveis
Facilitar o desenvolvimento multi-equipe com modelos de desenvolvimento dependentes ou não
Permitir o desenvolvimento descentralizado de classes (evitando conflitos)
Simplificar a codificação do uso de vários padrões de projeto!!
ExemploDesenvolvimento de duas aplicações
sistema de folha de pagamentoid, função, salário, e cidade e estado (cálculo de impostos)
sistema de localização de empregadosnome e endereço (incluindo cidade, estado, e cep)
Opções de desenvolvimento uma aplicação é uma extensão da outra as aplicações são desenvolvidas ao mesmo tempo com
alguma comunicação entre as equipesestruturas de classe, assinaturas de métodos
as aplicações são desenvolvidas ao mesmo tempo sem comunicação alguma entre as equipes
Opção 1 - extensão
Time 1 decide modelar duas classes Empregado
id, nome, função, salário, cidade e estadométodos get e setimprimir
Lista de empregadosno, proximoinseririmprimir
Time 2 baseado nas classes modeladas define sua definição das mesmas Empregado
id, nome, linha1, linha2, cidade, estado, cepmétodos get e setimprimir
Lista de empregadosno, próximo, anteriorinserirremoversetNextimprimir
Opção 1 - extensão
Opção 1 - extensão
Composição escrever regras de composição que adicionam as
novas funcionalidades definidas pelo time 2 ao sistema definido pelo time 1
Conclusões não foi necessário a comunicação entre os times não há impacto no código fonte do time 1
nada foi alterado não houve perda de tempo na modelagem do
time 1, pensando em extensões futuras
Opção 2 - composição
Time 1 modela suas classes bem como o time 2, da mesma forma mostrada na opção 1.
Objetivo: Gerar uma aplicação com ambas funcionalidades, compondo as aplicações geradas pelos times 1 e 2.
Necessidade de uma terceira entidade que escolhe quem será composto com quem Equate(App, <A,B>); permite a duplicidade de métodos
inserir, imprimir ... a terceira entidade escreve regras que
sobrescrevem uma implementação com a outraa implementação mais completa sobrescreve a menos
completa
Opção 2 - composição
Conclusões os códigos fontes das duas aplicações não
foram modificados as aplicações podem ser vendidas
separadamente ou compostas não houve custos adicionais em ambos os
times para prever extensões
Opção 2 - composição
Diferenças entre as classes modeladas nos exemplos anteriores o tipo do id do empregado é string em uma
aplicação e int em outra o nome da lista de empregados difere entre as
aplicações (EmpList e Emp_List) o mesmo acontece com o atributo nome
Objetivo: Gerar uma aplicação com ambas funcionalidades, compondo as aplicações geradas pelos times 1 e 2.
Opção 3 - diferenças mais radicais
Necessidade de uma terceira entidade que escolhe quem será composto com quem Equate(App, <A,B>); não faz mais sentido uma vez que existem nomes
diferentes que não podem mais ser “casados”A terceira entidade escreve regras que
explicitamente descrevem a correspondência entre os tipos, atributos e operações das aplicações
Opção 3 - diferenças mais radicais
default rules: NoCorrespondence, Merge
A application class employee
corresponds to
B application class employee
A application class employee instance variable state
corresponds to
B application class employee instance variable state
A application class emplist
corresponds to
B application class employee_list
Opção 3 - diferenças mais radicais
A regra não diz nada sobre os atributos em conflito e seus métodos get/set logo serão definidos em duplicidade
Definir um subject cola (glue) mantém os atributos e redefine o método get
para cada aplicação (o método set altera os dois atributos)
usa uma única instância reimplementando os métodos get/set de uma aplicação
Conclusões os códigos fontes das duas aplicações não foram
modificados as aplicações podem ser vendidas
separadamente ou compostas não houve custos adicionais em ambos os times
para prever extensões
Opção 3 - diferenças mais radicais
Referências
Homepage do projeto http://researchweb.watson.ibm.com/sop/
William Harrison and Harold Ossher, Subject-Oriented Programming - A Critique of Pure Objects, Proceedings of 1993 Conference on Object-Oriented Programming Systems, Languages, and Applications, September 1993