General Responsibility Assignment Software Patterns
|
|
- Cacilda Molinari Bugalho
- 5 Há anos
- Visualizações:
Transcrição
1
2 GRASP General Responsibility Assignment Software Patterns Os padrões GRASP fornecem uma abordagem sistemática para a atribuição de responsabilidades às classes do projeto
3 GRASP Qual é a conexão entre Responsabilidades, GRASP e diagramas UML? A ocasião para considerar a atribuição de responsabilidades às classes é durante a elaboração dos diagramas de sequência
4 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 4
5
6 O Criador (Creator) Problema: Quem deve ser responsável por criar uma nova instância de uma classe? Solução: Atribua à classe B a responsabilidade de criar uma instância de A se pelo menos um desses for verdadeiro (quanto mais melhor): B contém ou agrega A B registra a existência de A B usa A B tem os dados necessários para a inicialização de A que serão passados ao construtor de A
7 Exemplo: Jogo de Banco Imobiliário Quem deve criar os objetos correspondentes às peças do tabuleiro?
8 Exemplo: Jogo de Banco Imobiliário visão estática visão dinâmica
9 Outro exemplo: um ponto de venda Cuidado com a Criação de Objetos Complexos
10 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 10
11
12 O padrão Especialista (Information Expert) Problema: Precisa-se de um princípio geral para atribuir responsabilidades a objetos Durante o projeto, em que são definidas as interações entre objetos, é preciso fazer escolhas sobre a atribuição de responsabilidades a classes. Solução Atribuir uma responsabilidade ao especialista de informação: classe que possui a informação necessária para cumpri-la; Inicie declarando claramente a responsabilidade
13 Exemplo: O Banco Imobiliário Quem deve localizar uma posição do tabuleiro dada a sua identidade?
14 Exemplo: O ponto de venda Quem deve ser responsável por conhecer o total da venda?
15 Exemplo: O ponto de venda Quem deve ser responsável por conhecer o total da venda?
16 Exemplo: O ponto de venda Quem deve ser responsável por conhecer os subtotais?
17 Exemplo: O ponto de venda Quem deve ser responsável por conhecer o preço de cada item de venda?
18 Exemplo: O ponto de venda
19 O padrão Especialista (Information Expert) Benefícios: O encapsulamento da informação é mantido uma vez que os objetos usam seus próprios dados para realizar as tarefas. Baixo acoplamento entre as classes. O comportamento do sistema é distribuído entre as classes que têm as informações, encorajando a definição de classes mais "leves", mais fáceis de entender e de manter. Contraindicações : Em algumas situações, a solução sugerida pelo especialista pode ser indesejada. (Quem deve persistir uma venda no banco?)
20 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 20
21
22 Coesão Alta Problema: Como manter os objetos focados, compreensíveis, gerenciáveis e, em consequência, com Baixo Acoplamento? Classes que fazem muitas tarefas não relacionadas são mais difíceis de entender, de manter e de reusar, além de mais vulneráveis às mudanças. Solução: Atribua responsabilidades de modo que a coesão da classe permaneça alta. Use esse critério para avaliar alternativas
23 Coesão Medida de quão relacionadas ou focadas estão as responsabilidades de um elemento. Exemplo: Cao é coesa se tem apenas operações relacionadas ao Cão (morder, correr, latir, comer) a apenas ao Cão. ~ao terá que imprimir, listar cães, etc... Alta coesão promove design modular
24 Coesão Alta
25 Alta Coesão Que classe é responsável por criar um pagamento (Payment) e associá-lo a uma venda (Sale)? Register assumiu responsabilidade por uma coisa que é parte de Sale (fazer um pagamento não é responsabilidade de registrar)
26 Alta Coesão Register delega a responsabilidade a Sale, aumentando a coesão de Register
27 Coesão Uma classe com baixa coesão sofre dos seguintes problemas: difícil de compreender difícil de reutilizar difícil de manter frágil; frequentemente tem de ser alterada
28 Coesão Como um princípio básico, uma classe com alta coesão: tem um número relativamente pequeno de métodos, a funcionalidade desses métodos é altamente relacionada, e não faz trabalho de mais.
29 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 29
30
31 Baixo Acoplamento Problema: Como prover baixa dependência entre classes, reduzir o impacto de mudanças e obter alta reutilização? Solução: Atribua as responsabilidades de modo que o acoplamento entre classes permaneça baixo. Use este princípio para avaliar alternativas.
32 Acoplamento Medida de quanto um elemento está conectado a, ou depende de outros elementos. Uma classe com acoplamento forte depende de muitas outras classes: tais classes podem ser indesejáveis O acoplamento está associado à coesão: maior coesão, menor acoplamento e vice-versa.
33 Exemplo: O Banco Imobiliário Pergunta: Por que o Tabuleiro e não um cachorro?
34 Baixo Acoplamento Ponto Chave: O Especialista favorece o Baixo Acoplamento Retornando à motivação do especialista: conduz a soluções que favorecem o baixo acoplamento. O especialista nos pede que encontremos o objeto que tem a maior parte da informação necessária para assumir a responsabilidade (por exemplo, o tabuleiro) Se pusermos a responsabilidade em algum outro lugar qualquer (por exemplo, o cachorro) o acoplamento global será maior porque mais informações terão de ser compartilhadas entre os objetos.
35 Outro Exemplo: O ponto de venda Suponha que temos de criar um objeto pagamento e associá-lo à venda. Que classe deve ser responsável por isso? 1ª alternativa 2ª alternativa
36 Acoplamento entre classes a) A ClasseA tem um atributo do tipo ClasseB
37 Acoplamento entre classes b) A ClasseA tem um método que, de alguma forma, referencia uma instância de ClasseB. Tipicamente, esta referência se dá através de um parâmetro ou variável local do tipo ClasseB ou por um objeto do tipo ClasseB retornado pela chamada de algum método
38 Acoplamento entre classes c) A ClasseA é uma subclasse de ClasseB
39 Acoplamento entre classes d) A ClasseB é uma interface e a ClasseA implementa esta interface
40 Acoplamento entre classes Discussão: Classes que, por natureza, são genéricas e que têm alta probabilidade de reutilização deveriam ter acoplamento baixo O caso extremo do baixo acoplamento é o não acoplamento: contraria o princípio da orientação a objetos: objetos conectados, trocando mensagens entre si. O acoplamento alto não é o problema em si. O problema é o acoplamento a classes que, de alguma forma são instáveis: sua interface, sua implementação ou sua mera presença.
41 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 41
42
43 O Controlador Problema: Quem deve ser o responsável por lidar com um evento de uma interface de entrada? Solução: Atribuir a responsabilidade de receber ou lidar com um evento do sistema para uma classe que representa todo o sistema (controlador de fachada front controller), um subsistema e um cenário de casos de uso (controlador de caso de uso ou sessão)
44 O Controlador Que objeto, fora da camada de apresentação, deve receber e coordenar a solicitação da execução de uma operação?
45 O princípio da separação Modelo- Vista O princípio da separação Modelo-Vista pode ser enunciado em duas partes: Não conecte diretamente objetos pertencentes à interface com o usuário (a vista) com objetos não pertencentes à interface com o usuário (IU). Não coloque lógica da aplicação (tal como o cálculo de impostos) nos métodos dos objetos da IU
46 O princípio da separação Modelo- Vista A motivação para a separação Modelo-Vista inclui: Suportar a criação de classes de negócio coesas, com foco nos processos do domínio ao invés de na interface com o usuário. Permitir o desenvolvimento separado das camadas de apresentação e negócio. Minimizar o impacto na camada de negócio das alterações nos requisitos da interface com o usuário.
47 O princípio da separação Modelo- Vista A motivação para a separação Modelo-Vista inclui: Permitir que novas vistas sejam facilmente conectadas aos objetos de negócio existentes, sem afetar a camada de negócios. Permitir a existência de múltiplas vistas simultâneas para uma mesma camada de negócios (por exemplo, a visualização de dados de vendas na forma tabular ou através de um gráfico de pizzas)
48 O objeto Controlador O objeto Controlador responde a uma questão básica no projeto de sistemas OO: Como conectar a camada de apresentação à camada da lógica do negócio?
49 O objeto Controlador O controlador é o primeiro objeto fora da camada de interface com o usuário a receber ou tratar uma mensagem para o sistema. Existem duas alternativas possíveis para o objeto controlador: Um objeto Controlador para todo o sistema Um objeto Controlador por Caso de Uso (ou por cenário de Caso de Uso)
50 Controlador Um sistema contendo operações de sistema associados com eventos do sistema
51 Controlador Os benefícios do padrão controlador são: Diminui a sensibilidade da camada de apresentação em relação à lógica de domínio Oportunidade para controlar o estado do caso de uso
52 Exemplo: Ponto de Venda
53 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 53
54
55 Polimorfismo Problema: Como tratar alternativas baseadas no tipo? Como criar componentes de software "plugáveis"? Deseja-se evitar variação condicional (if-then-else): pouco extensível Deseja-se substituir um componente por outro sem afetar o cliente Solução: Quando alternativas ou comportamentos relacionados variam com o tipo (classe), atribua as responsabilidades aos tipos usando operações polimórficas.
56 Exemplo
57 O Banco Imobiliário Como projetar para acomodar as diferentes ações baseadas no tipo da posição do tabuleiro? Um mau projeto:
58 O Banco Imobiliário O comportamento estático:
59 O Banco Imobiliário O comportamento dinâmico:
60 O Banco Imobiliário O comportamento dinâmico:
61 O Banco Imobiliário O comportamento dinâmico:
62 O Banco Imobiliário O comportamento dinâmico:
63 O Banco Imobiliário O comportamento dinâmico:
64 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 64
65
66 Pure Fabrication Problema: Que objeto deve ter a responsabilidade quando você não quer violar "Alta Coesão" e "Baixo Acoplamento", mas as soluções oferecidas pelo "Especialista" não são apropriadas? Atribuir responsabilidade apenas para as classes do domínio conceitual pode levar a situações de maior acoplamento e menor coesão. Solução: Atribua um conjunto coeso de responsabilidades a uma classe artificial que não representa um conceito no domínio da aplicação, uma classe fictícia que possibilite alta coesão, baixo acoplamento e o reuso.
67 Ponto de Venda: Salvar uma Venda no Banco de Dados O especialista nos diz para atribuir a responsabilidade à classe Venda, uma vez que ela conhece os dados da venda. Considere no entanto as seguintes implicações: Salvar um objeto no Banco de Dados implica em uma série de operações não relacionadas ao conceito de venda A classe venda tem de ser associada à interface do banco de dados relacional (JDBC, por exemplo) Várias outras classes no projeto terão de fazer a mesma coisa.
68 Pure Fabrication
69 O Banco de Dados
70 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 70
71
72 Indireção Problema: Onde colocar uma responsabilidade de modo a evitar o acoplamento direto entre duas ou mais classes? Como desacoplar objetos de modo a possibilitar o baixo acoplamento e manter alta a possibilidade de reuso? Solução: Atribua a responsabilidade a um objeto intermediário que faça a mediação entre componentes ou serviços de modo que eles não sejam diretamente acoplados O objeto intermediário cria uma camada de indireção entre os dois componentes que não mais dependem um do outro: ambos dependem da indireção
73 Indireção Exemplo: Indireção através de um adaptador
74 Indireção "A maior parte dos problemas em Ciência da Computação pode ser resolvida por um nível adicional de indireção" Velho provérbio com especial relevância para sistemas orientados a objetos "A maior parte dos problemas de desempenho pode ser resolvida removendo-se algumas camadas de indireção"
75 INVERSÃO DE CONTROLE
76 Inversão de Controle IoC Princípio de Hollywood: Não nos ligue, nós ligaremos. Dependência de componentes. também conhecida como colaboradores de objetos. O objeto que exige dependência é conhecido como objeto dependente. Frameworks é responsável pela execução da operação. Ocorre em tempo de execução. 76
77 Inversão de Controle: Motivação Cenário 1 Classe A precisa de uma referência para a Classe B. Classe B é uma classe concreta que tem um construtor padrão. Classe A possui uma instância de B. Nenhuma outra classe pode acessar uma instância da Classe B [Mal06]. public class A{ private B b; public A(){ b=new B(); } } 77
78 Inversão de Controle: Motivação Cenário 2 Objeto a possui referência para os objetos c e b. public class A{ private B b; public A(){ C c = new C(); b = new B(c); } } 78
79 Inversão de Controle: Motivação Cenário 3 A precisa de uma referência para B, e não precisa saber como B é instanciado. B pode ser uma interface, uma classe abstrata ou concreta. Antes de instanciar a classe A, precisa de uma referência para a classe B. public class A{ private B b; public A(){ } public setb(b b){ this.b=b; } } 79
80 Tipos de Inversão de Controle Inversão de Controle (IoC) possui dois tipos [Har05]: Injeção de Dependência (Dependency Injection) Procura por Dependência (Dependency Lookup) Injeção de Dependência sempre diz respeito a IoC, mas IoC nem sempre referencia Injeção de Dependência 80
81 Tipos de Inversão de Controle Inversão de Controle Procura por Dependência Injeção de Dependência Contextualized Dependency Lookup Dependency Pull Interface Setter Construtor 81
82 Tipos de Inversão de Controle Procura por Dependência: um componente deve obter uma referência para uma dependência; dois subtipos: Dependency Pull Contextualized Dependency Lookup (CDL) Injeção de Dependência: as dependências são literalmente injetadas (incluídas) três subtipos: Interface Tipo 1 Setter Tipo 2 Constructor Tipo 3 82
83 Contêineres de Inversão de Controle Spring Avalon PicoContainer HiveMind Excalibur: Fortress Resin Copland (Ruby) Mentawai 83
84 Procura por Dependência Dependency Pull As dependências são obtidas através de um registro assim que necessário; Mecanismo para encontrar componentes que gerenciam o frameworks. Procura por Dependência com Spring public static void main(string[] args) throws Exception { // get the bean factory BeanFactory factory = getbeanfactory(); MessageRenderer mr = (MessageRenderer) factory.getbean("renderer"); mr.render(); } 84
85 Procura por Dependência Contextualized Dependency Lookup (CDL) Semelhante ao Dependency Pull; Procura é executada pelo contêiner que está gerenciando o recurso e não a partir de um registro central; CDL funciona através da implementação de uma interface. Interface do Componente para CDL com Spring public interface ManagedComponent { public void performlookup(container container); } 85
86 Procura por Dependência Contextualized Dependency Lookup (CDL) Executa o método performlookup() implementado pelo componente; O componente pode procurar sua dependência utilizando a interface Container. Obtendo dependência com o CDL public class ContextualizedDependencyLookup implements ManagedComponent { private Dependency dep; public void performlookup(container container) { this.dep = (Dependency)container.getDependency ("mydependency"); } } 86
87 Dependency Injection Problema Controle convencional: o próprio objeto cria ou localiza suas dependências: acoplamento 87
88 Injeção de Dependência por meio de Construtor Dependência do componente é disponibilizada através de seu(s) construtor(es); O argumento recebido será sua dependência. Injeção de Dependência pelo Construtor com Spring public class ConstructorInjection { private Dependency dep; public ConstructorInjection(Dependency dep) { this.dep = dep; } } 88
89 Injeção de Dependência por meio de método Setter O contêiner IoC injeta um componente de dependência através de seu método set (JavaBean); O componente setter permite um conjunto de dependências que o contêiner de inversão de controle pode gerenciar. Injeção de Dependência através do método Setter com Spring public class SetterInjection { private Dependency dep; public void setmydependency(dependency dep) { this.dep = dep; } } 89
90 Injeção de Dependência por meio de Interface [Fow06] Componente de dependência através de uma interface; A interface InjectFinder será definida por qualquer um que fornecer a interface MovieFinder (no exemplo abaixo). Injeção de Dependência através de Interface. Exemplo no arcabouço Avalon public interface InjectFinder { public void injectfinder(moviefinder finder); } public class MovieLister implements InjectFinder { public void injectfinder(moviefinder finder){ this.finder = finder; } 90
91 Injeção de Dependência por meio de Interface Exemplo: Classe de Teste no Avalon: configura os componentes e os injetores. public class Tester { private Container container; private void configurecontainer(){ container = new Container(); registercomponents(); registerinjectors(); container.start(); } } 91
92 Injeção de Dependência por meio de Interface É preciso registrar os injetores que irão injetar os componentes dependentes; Cada interface de injeção precisa de algum código para injetar o objeto dependente; No código abaixo, registram-se os objetos injetores no contêiner: private void registerinjectors(){ container.registerinjector(injectfinder.class, container.lookup( MovieFinder )); } 92
93 Injeção versus Procura O tipo de IoC é definido pelo contêiner adotado. Com Dependency Pull, é necessário: registrar dependências; obter referências das dependências; interagir com as dependências obtidas. Utilizando CDL, é preciso: que as classes implementem uma interface específica; e procure por todas dependências manualmente. Com Injeção de Dependência, as classes precisam: permitir que as dependências sejam injetadas por meio de construtores, métodos setters ou interfaces. 93
94 Inversão de Controle e Padrão Reactor Reactor: Padrão de Arquitetura [POSA 2]; Conhecido também como Dispatcher, Notifier Contexto: Aplicação orientada a eventos que processa as informações de forma síncrona e serial. Problema: aplicações devem: atender muitas requisições simultaneamente, demultiplexar e despachar as indicações de eventos às respectivas implementações de serviço. 94
95 Inversão de Controle e Padrão Reactor Define uma interface que permite que aplicações: registrem ou removam tratadores de eventos; sejam executadas no laço de eventos da aplicação. Reactor utiliza um demultiplexador síncrono de evento para aguardar pela indicação de eventos que se originam de uma ou mais fontes. Quando ocorre um evento: o demultiplexador síncrono de evento notifica o Reactor; o Reactor aciona o tratador associado, para realização do serviço solicitado. O Reactor inverte o fluxo de controle, pois é responsabilidade dele (e não da aplicação) em disparar os tratadores concretos para cada tipo de evento. 95
96 Desvantagens na Inversão de Controle Dificuldade na integração de arcabouços: quando dois ou mais frameworks chamam simultaneamente o código da aplicação, cada qual pressupondo seu próprio fluxo de controle; Dificuldade na depuração do código e compreensão do fluxo: o controle é alternado entre o código da aplicação e o código do frameworks. 96
97 Injeção de Dependências (Inversão de Controle) Um dos benefícios de usar interface Em vez de Use
98 Injeção de Dependências (Inversão de Controle) Se A depende de InterB, fica fácil testar ou media A usando uma implementação/simulação de B para testes Interfaces devem ser pequenas Um objeto pode implementar várias interfaces Facilita a evolução (interfaces grandes publicam um contrato grande que não pode ser revogado. Planeje interfaces em todos os objetos Principalmente nos que oferecem serviços, singleton, etc..
99 Exemplo: controle convencional Linha 9: dependência fortemente acoplada Difícil de testar objeto sem testar dependência 99
100 A dependência 100
101 Diminuindo o acoplamento Melhor forma de eliminar o acoplamento é usar interfaces Implementação é dependente da interface Cliente depende da interface, não mais da implementação 101
102 Solução Em vez do programador buscar ou criar sua própria certificação, ela é atribuída a ele Para isto, deve haver método para criar a associação 102
103 Inversão de Controle 103
104 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 104
105 Protected Variants Problema: Como projetar objetos, subsistemas e sistemas para que as variações ou instabilidades nesses elementos não tenha um impacto indesejável nos outros elementos? Solução: Identificar pontos de variação ou instabilidades potenciais Atribuir responsabilidades para criar uma interface estável em volta desses pontos. Encapsulamento, interfaces, polimorfismo, indireção e padrões: máquinas virtuais e brokers são motivados por este princípio Evite enviar mensagens a objetos muito distantes
106 Aspectos Adicionais
107 Aspectos: separação de interesses A separação de interesses é objetivo essencial do processo de decomposição da solução de um problema Decomposição deve continuar até que cada unidade da solução possa ser compreendida e construída Cada unidade deve lidar com apenas um interesse Separação de interesses eficiente promove o código de melhor qualidade Maior modularidade Facilita atribuição de responsabilidades entre módulos Promove o reuso Facilita a evolução do software Viabiliza a análise do problema dentro de domínios específicos 107
108 Tipos de interesse Usando linguagem OO, pode-se representar de forma eficiente e modular as classes e procedimentos Outros interesses são implementados como partes de classes e partes ou composição de procedimentos 108
109 Scattering e tangling 109
110 Inclusão de nova funcionalidade Também sujeita a scattering e tangling Funcionalidade espalhada por várias classes (funcionalidade consiste de métodos contidos em várias classes) Funcionalidades misturadas com outros recursos (não é representado por uma entidade separada) 110
111 Como reduzir tangling e scattering Criar subclasse que implemente recursos, sobreponha métodos, etc. Problema: classes cliente têm que ser alteradas para que saibam como criar a nova subclasse: VeiculoCarga v = // new VeiculoCarga(); new VeiculoCarga2(); Design patterns como factory method resolveriam o problema VeiculoCarga v = VeiculoCarga.create(); mas sua interface precisaria ser planejada antes. 111
Padrões de Projeto de Software
Padrões de Projeto de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático Padrões Básicos Information Expert Creator High Cohesion Low Coupling Controller Padrões Avançados
Leia maisAnálise e Projeto Orientados por Objetos
Análise e Projeto Orientados por Objetos Aula 03 Padrões de Projeto GRASP Edirlei Soares de Lima Padrões de Projeto de Software Problemas no desenvolvimento de software se repetem...
Leia maisGRASP. Nazareno Andrade (baseado em Hyggo Almeida e Jacques Sauvé)
GRASP Nazareno Andrade (baseado em Hyggo Almeida e Jacques Sauvé) O que vimos na última aula? Introdução a padrões O que são? Por que utilizá-los? Padrões GRASP O que são? Quais serão apresentados na disciplina?
Leia maisIntrodução a Padrões, GRASP. Nazareno Andrade (baseado no material de Hyggo Almeida e Jacques Sauvé)
Introdução a Padrões, GRASP Nazareno Andrade (baseado no material de Hyggo Almeida e Jacques Sauvé) O que vimos na última aula? Processo de Desenvolvimento de Software Visão geral de processo Processos
Leia maisGRASP: PADRÕES PARA ATRIBUIÇÃO DE RESPONSABILIDADES. SSC 124 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa
GRASP: PADRÕES PARA ATRIBUIÇÃO DE RESPONSABILIDADES SSC 124 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2016 1 RESPONSABILIDADE Responsabilidade um contrato ou
Leia maisPadrões de Projeto de Software
Padrões de Projeto de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Introdução O que é? Como descrever? Principais Padrões de Projetos Unidade 2 Padrões GoF PADRÕES CRIAÇÃO Abstract Factory
Leia maisPadrões GRASP. Leonardo Gresta Paulino Murta
Padrões GRASP Leonardo Gresta Paulino Murta leomurta@ic.uff.br Introdução Estilo MVC Padrões Expert Creator Controller Low Coupling High Cohesion Polymorphism Pure Fabrication Indirection Don t Talk to
Leia maisInjeção de Dependências e Spring
Injeção de Dependências e Spring Daniel Cukier Prof. Fabio Kon IME-USP Conteúdo Exemplo Melhor maneira de aprender Injeção de Dependência (DI) Spring Service Locator Daniel Cukier - IME/USP 2/29 Exemplo
Leia maisProjeto Orientado a Objetos
Projeto Orientado a Objetos Ivan Mathias Filho Toacy Cavalcante de Oliveira Design Orientado a Objetos Após a identificação dos requisitos e a criação do modelo de domínio, devemos adicionar os métodos
Leia maisSingleton e Adapter. Professor: Nazareno Andrade (baseado no material de Hyggo Almeida e Jacques Sauvé)
e Adapter Professor: Nazareno Andrade (baseado no material de Hyggo Almeida e Jacques Sauvé) O que vimos na última aula? Factory Method Abstract Factory 2 O que veremos hoje? (padrão de criaçã) Adapter
Leia maisModelo do Mundo Real. Abstração. Interpretação
Modelo do Mundo Real Mundo Real Abstração Interpretação Sistema de Software Modelo Algoritmo Abstração: O modelo precisa capturar apenas as características do mundo real que são importantes para o sistema
Leia maisPadrões de Projeto. Conteúdo. Objetivos
Padrões de Projeto Conteúdo O que são Padrões de Projeto? Para que servem? Vantagens/Desvantagens, Pontos Fortes/Fracos Exemplos e Alternativas Objetivos Conhecer diferentes padrões; Entender sua utilidade;
Leia maisPROJETO DE ARQUITETURA (PARTE 2)
PROJETO DE ARQUITETURA (PARTE 2) Projeto Detalhado de Software (PDS) Profa. Cynthia Pinheiro Antes de mais nada... 5ª Lista de Exercícios Já está disponível no site a 5ª Lista de Exercícios Entrega: dia
Leia maisAula 12: Princípios da Coesão de Pacotes
Aula 12: Princípios da Coesão de Pacotes Programação Modular Jefersson Alex dos Santos (jefersson@dcc.ufmg.br) Roteiro Projeto de classes Modularização fundamental para garantir a qualidade de software
Leia maisConteúdo. 1. Introdução. 2. Levantamento de Requisitos. 3. Análise Orientada a Objetos. 4. Projeto Orientado a Objetos 5. UML. 6.
Conteúdo 1. Introdução 2. Levantamento de Requisitos 3. Análise Orientada a Objetos 4. Projeto Orientado a Objetos 5. UML 6. Métodos Ágeis Projeto Orientado a Objetos Definição das Operações Responsabilidade
Leia maisINF1013 MODELAGEM DE SOFTWARE
INF1013 MODELAGEM DE SOFTWARE Departamento de Informática Ivan Mathias Filho ivan@inf.puc-rio.br Programa Capítulo 4 Design Baseado em Responsabilidades 1 Programa Capítulo 4 Design Baseado em Responsabilidades
Leia maisPadrões para atribuir responsabilidades: Expert
Padrão para atribuir responsabilidades: Expert Introdução Um sistema OO é composto de objetos que enviam mensagens uns para os outros Uma mensagem é um método executado no contexto de um objeto Escolher
Leia maisPROJETO ARQUITETURAL PARTE II: PADRÕES DE PROJETO. Projeto de Programas PPR0001
PROJETO ARQUITETURAL PARTE II: PADRÕES DE PROJETO Projeto de Programas PPR0001 QUALIDADE DO PROJETO 2 3 Qualidade do Projeto de Software Modularidade: gerar particionamento em elementos que executam funções
Leia maisFactory Pattern. SISMO - Sistemas e Mobilidade Junho de Departamento de Informática / UFMA
Factory Pattern SISMO - Sistemas e Mobilidade http://www.sismo.deinf.ufma.br Departamento de Informática / UFMA Junho de 2008 Do que vamos tratar? Criação de objetos não é simplesmente usar o operador
Leia maisHerança. Universidade Católica de Pernambuco Ciência da Computação. Prof. Márcio Bueno.
Universidade Católica de Pernambuco Ciência da Computação Prof. Márcio Bueno poonoite@marciobueno.com Fonte: Material da Profª Karina Oliveira Possibilita o reuso de classes (código-fonte) Usar quando:
Leia maisUNIVERSIDADE FEDERAL DE MATO GROSSO DO SUL SISTEMAS DE INFORMAÇÃO - CÂMPUS DE COXIM FUNDAMENTOS EM ORIENTAÇÃO A OBJETOS
Data final de entrega 16/09/2014, até às 23h59min Enviar o arquivo de respostas em formato PDF e o arquivozip com códigos fontes para o e-mail motafernandomaia@gmailcom, insira no assunto do e-mail [Lista
Leia maisProgramação Orientada a Objetos. Vagner Luz do Carmo - Vluzrmos
Programação Orientada a Objetos Vagner Luz do Carmo - Vluzrmos Questão 1 Dada a seguinte classe na linguagem JAVA: public class Carro { public String retornacor(){ ; return Azul ; private String retornachassi(){
Leia maisPROJETO DE ARQUITETURA
PROJETO DE ARQUITETURA Projeto Detalhado de Software (PDS) Profa. Cynthia Pinheiro Antes de mais nada... Próximas aulas: Seminários de Padrões de Projeto GoF 1º Dia: 10/11/2017, 08h 10h, Sala 04 2º Dia:
Leia maisANÁLISE E PROJETO ORIENTADO A OBJETO (Parte 3)
ANÁLISE E PROJETO ORIENTADO A OBJETO (Parte 3) Profª Andrea Padovan Jubileu Desenvolvimento Iterativo de Software (LARMAN, 2007) Desenvolvendo Software com UML 2.0 (MEDEIROS, 2004) Modelo de Projeto O
Leia maisAbstract Factory. Prover uma interface para criar uma família de objetos relacionados ou dependentes sem especificar suas classes concretas
Objetivo Prover uma interface para criar uma família de objetos relacionados ou dependentes sem especificar suas classes concretas Também chamado de Kit Resumo Parece semelhante ao padrão Factory Method,
Leia maisEstilo: BlackBoard. BlackBoard = repositório de dados compartilhados
Estilo: BlackBoard Útil para problemas no qual não há uma solução determinística Uma coleção de programas independentes que trabalham cooperativamente em uma estrutura de dados comum (blackboard) Vários
Leia maisInterfaces. Universidade Católica de Pernambuco Ciência da Computação. Prof. Márcio Bueno.
Interfaces Universidade Católica de Pernambuco Ciência da Computação Prof. Márcio Bueno poonoite@marciobueno.com Fonte: Material da Profª Karina Oliveira Interfaces É utilizada para agrupar conceitos em
Leia maisLaboratório de programação II
Laboratório de programação II Herança e Polimorfismo Edson Moreno edson.moreno@pucrs.br http://www.inf.pucrs.br/~emoreno Herança Mecanismo da Orientação a Objeto que permite criar novas classes aproveitando
Leia maisPadrões de Projeto. Padrões de Projeto. Além dos 23 Padrões GoF. Os 23 Padrões de Projeto. Documentação de um Padrão. Classificação dos Padrões
DCC / ICEx / UFMG Padrões de Projeto Padrões de Projeto Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Um padrão é uma descrição do problema e a essência da sua solução Documenta boas soluções para
Leia maisUML & Padrões Aula 7. UML & Padrões - Profª Kelly C C Silva
UML & Padrões Aula 7 UML & Padrões - Profª Kelly C C Silva Divisão das classes do Modelo de Análise Jacobson propõe a divisão das classes do Modelo de Análise de acordo com os seguintes estereótipos: entidades
Leia maisInterface vs. Implementação Herança vs. Composição
Interface vs. Implementação Herança vs. Composição O que vimos na última aula? Padrões GRASP Expert Creator Low Coupling High Cohesion 2 O que veremos hoje? Interface e Polimorfismo Interface como uma
Leia maisCapítulo 2. Orientação a Objetos
Capítulo 2 Orientação a Objetos Princípios da Orientação a Objetos Os princípios da orientação a objetos afetam todo o processo de desenvolvimento de software: Seres humanos pensam em termos de substantivos
Leia maisProgramação Orientada a Objetos. Prof. MsC Sílvio Bacalá Júnior
Programação Orientada a Objetos Prof. MsC Sílvio Bacalá Júnior Princípios básicos de OO Abstração Encapsulamento Modularidade Herança 2013 POO - Bacalá 2 Abstração Concentração nas características essenciais,
Leia maisDesenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto
Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2006 Profa. Dra. Itana Gimenes RUP: Projeto Artefatos Modelo de Projeto: Lista de classes de
Leia maisRede de computadores Cliente- servidor. Professor Carlos Muniz
Rede de computadores Professor Carlos Muniz Definição Cliente-servidor é um modelo computacional que separa clientes e servidores, sendo interligados entre si geralmente utilizando-se uma rede de computadores.
Leia maisRecapitulando. Construtores: (Overload assinatura) public Circle() {...} public Circle(double x, double y, double r) {... }
Recapitulando Orientação a objetos: programas organizados em torno da definição de classes, instanciação de objetos e troca de mensagens. Declaração de variáveis de referencia: Circle c; Criação/instanciação
Leia maisDaniel Wildt
Orientação a Objetos 1 Daniel Wildt http://danielwildt.blogspot.com Agenda 2 Orientação a Objetos Classe x Objeto Representação classe Atributos / operações Construtores e Destrutores Liberando memória
Leia maisEngenharia de Software. Projeto de Arquitetura
Engenharia de Software Projeto de Arquitetura O que já vimos? Introdução a Engenharia de Software Processos de Software Desenvolvimento Ágil de Software Engenharia de Requisitos Modelagem de sistemas (outra
Leia maisIntrodução a Programação Orientada a Aspectos
Introdução a Programação Orientada a Aspectos Parte 1 - Orientação a objetos Um objeto é um componente de software - uma parte de um sistema que exibe certas características específicas. A seguir são algumas
Leia maisDCC004 - Algoritmos e Estruturas de Dados II
Conceito de especificação de software Renato Martins Email: renato.martins@dcc.ufmg.br https://www.dcc.ufmg.br/~renato.martins/courses/dcc004 Material adaptado de PDS2 - Douglas Macharet e Flávio Figueiredo
Leia maisModulo II Padrões GRASP
Modulo II Padrões GRASP Professores Eduardo Bezerra edubezerra@gmail.com Ismael H F Santos ismael@tecgraf.puc-rio.br April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 1 Ementa Padrões de Projeto
Leia maisVisibilidade e Encapsulamento
Visibilidade e Encapsulamento Professor: Ricardo Luis dos Santos IFSUL 2016 Agenda Pacotes Visibilidade Encapsulamento Hands-On 2 Pacotes Em Java, a visibilidade ou grau de acesso a um determinado atributo
Leia maisJava Standard Edition (JSE)
Java Standard Edition (JSE) Capítulo 05. Encapsulamento, Modificadores de acesso e atributos de classe Esp. Márcio Palheta MSN: marcio.palheta@hotmail.com 1 Agenda Revisão da aula anterior; Motivação Organização;
Leia maisParadigmas de Linguagens de Programação. Suporte para Programação Orientada a Objeto
Suporte para Programação Orientada a Objeto Cristiano Lehrer Categoria das Linguagens que Suportam POO Suporte a POO acrescentado a uma linguagem já existente: C++ (também suporta programação procedural
Leia maisINF1636 PROGRAMAÇÃO ORIENTADA A OBJETOS
INF1636 PROGRAMAÇÃO ORIENTADA A OBJETOS Departamento de Informática PUC-Rio Ivan Mathias Filho ivan@inf.puc-rio.br Programa Capítulo 17 Padrões de Design Singleton Facade Factory Method Observer Strategy
Leia maisClasse Abstrata e Interface
Orientação a objetos com Java Classe Abstrata e Interface Byron Leite byron.leite@gmail.com 1 Herança Agenda Geral Parte 04 Encapsulamento Pacotes Modificadores de Acesso private, default, protected, public
Leia maisA B Classe Genérica D A C. Classe Especializada. Classe Especializada. Características Herdadas
Herança e Polimorfismo Prof. Bruno Gomes bruno.gomes@ifrn.edu.br Programação Orientada a Objetos Revisando -Herança Estrutura Hierárquica e modular Projeção de classes genéricas que podem ser especializadas
Leia maisEncapsulamento e Métodos (Construtores e Estáticos) João Paulo Q. dos Santos
Encapsulamento e Métodos (Construtores e Estáticos) Sobrecarga de Métodos João Paulo Q. dos Santos joao.queiroz@ifrn.edu.br Roteiro Conceitos sobre Encapsulamento; Variável this; Métodos Construtores;
Leia maisLEIC-T LERC MEIC-T 2011/2012 1º Semestre Programação com Objetos 2012/01/07 11h00m 3/10
2/10 1.1. (1.5 val.) Os mecanismos de herança entre classes e de composição de objetos são, por vezes, apresentados como alternativos, face à disponibilização de funcionalidade a uma classe. Compare-os,
Leia maisUML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos
UML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos joao.queiroz@ifrn.edu.br Roteiro A importância da UML para projetar sistemas. Principais características do diagrama de classes e de sequência.
Leia maisProgramação Orientada a Objetos. Professor: André Luis Meneses Silva br.geocities.com/programacao2ufs
Programação Orientada a Objetos Professor: André Luis Meneses Silva andreluis.ms@gmail.com br.geocities.com/programacao2ufs [ Conteúdo ] Objeto Mensagens Classe Encapsulamento Visibilidade Membros de Instância
Leia maisOs princípios do desenho orientado a objetos
Os princípios do desenho orientado a objetos Os princípios do desenho orientado a objetos Encapsulamento e congeneridade Domínios, grau de dependência e coesão Os perigos da herança e do polimorfismo Encapsulamento
Leia maisFrameworks. Viviane Torres da Silva
Frameworks Viviane Torres da Silva viviane.silva@ic.uff.br http://www.ic.uff.br/~viviane.silva/es1 Frameworks Motivação Definição Classificação Características Propriedades Técnicas de Customização Frameworks
Leia maisPCS3413 Engenharia de Software e Banco de Dados
PCS3413 Engenharia de Software e Banco de Dados Aula 23 Escola Politécnica da Universidade de São Paulo 1 Acoplamento! Indica dependência entre classes.! Deve ser o menor possível.! Direcionar associações
Leia maisLinguagens de Programação Aula 12
Linguagens de Programação Aula 12 Celso Olivete Júnior olivete@fct.unesp.br Na aula passada Implementando subprogramas 2 Na aula de hoje Suporte para a programação orientada a objetos 3 Roteiro Introdução
Leia maisPolimorfismo. O que é polimorfismo?
O que é polimorfismo? Polimorfismo Significa que variáveis podem referenciar mais do que um tipo. Não é um conceito novo e várias linguagens de programação aplicam. Funções são polimórficas quando seus
Leia maisDIAGRAMA DE COMUNICAÇÃO
Universidade de São Paulo, Instituto de Ciências Matemáticas e de Computação DIAGRAMA DE COMUNICAÇÃO SSC 621: Análise e Projeto Orientados a Objetos Prof. Dr. Lucas Bueno R. Oliveira 2º Semestre 2015 O
Leia maisINF011 Padrões de Projeto. 05 Factory Method
INF011 Padrões de Projeto 05 Factory Method Sandro Santos Andrade sandroandrade@ifba.edu.br Instituto Federal de Educação, Ciência e Tecnologia da Bahia Departamento de Tecnologia Eletro-Eletrônica Graduação
Leia maisCreational Patterns Factory method
Objetivo do Factory method é definir qual será a subclasse que utilizada um cliente. Permite que o sistema funcione sem o conhecimento prévio das subclasses. Assim um framework pode ser construído apenas
Leia maisPadrão de projeto de software
Padrão de projeto de software Paulo Venancio Lopes e Daniel Sguillaro Nome Roupa Suja Se Lava Em Casa. Intenção Dar maior capacidade e flexibilidade ao conceito de entidade (no contexto de persitência
Leia maisDefinindo um padrão para arquitetura Web
Definindo um padrão para arquitetura Web Padrões de Projeto Soluções reutilizáveis para situações ou problemas encontrados comumente em desenvolvimento de software orientado a objetos. Livros Design Patterns:
Leia maisJava para Desktop. Programação Orientada à Objetos 2 JSE
Java para Desktop Programação Orientada à Objetos 2 JSE Encapsulamento significa "ocultar informações, ele define que cada objeto contém todos os detalhes de implementação necessários sobre como ele funciona
Leia maisVisões Arquiteturais. Visões Arquiteturais
Visões Arquiteturais Separar diferentes aspectos em visões separadas com o objetivo de gerenciar complexidade. Cada visão descreve diferentes conceitos da Engenharia. Visões permitem reduzir a quantidade
Leia maisIntrodução aos Padrões de Projeto. Sylvio Barbon Jr
Introdução aos Padrões de Projeto Sylvio Barbon Jr 25 février 2016 Introdução Disciplina Engenharia de Software : São Tratados principalmente os tesmas : Metodologia : No desenvolvimento
Leia maisSoluções reutilizáveis para situações ou problemas encontrados comumente em desenvolvimento de software orientado a objetos.
Padrões de Projeto O que são? Soluções reutilizáveis para situações ou problemas encontrados comumente em desenvolvimento de software orientado a objetos. Livros Design Patterns: Elements of Reusable Object-
Leia maisAnálise e Projeto de Software
Análise e Projeto de Software Proj. Desenvolvimento de Software Prof. Cleverton Hentz cleverton.hentz@ifrn.edu.br 8 de junho de 2017 Material Apresentado Sumário de Aula 1 Introdução 2 Estruturação do
Leia maisIntrodução à Análise e Projeto de Sistemas
Introdução à I. O Que vamos fazer na Disciplina? Saber uma linguagem de programação orientada a objeto (OO) não é suficiente para criar sistemas OO Tem que saber Análise e Projeto OO (APOO) Isto é, Análise
Leia maisEngenharia de Software
Engenharia de Software Design Principles Representando SW em UML OO em C Pattens úteis para embedded Rodrigo M A Almeida Design Principles Design Principles são guias para decompor as funcionalidades e
Leia maisC com introdução a OO
... Centro Integrado de Tecnologia da Informação C com introdução a OO ... Centro Integrado de Tecnologia da Informação Aula 9 Ronald Dener - Instrutor Matheus Soares - Monitor 17 / outubro 17 / outubro
Leia maisProjeto de software Estrutura do software e arquitetura SWEBOK
Projeto de software Estrutura do software e arquitetura SWEBOK SWEBOK Design Patterns Maneira testada ou documentada de alcançar um objetivo qualquer Padrões são comuns em várias áreas da engenharia Design
Leia maisIteradores. Iteradores. Isabel Harb Manssour. Roteiro. Coleções
Implementação de Genéricos, Iteradores Isabel Harb Manssour Porto Alegre, maio de 2006 Roteiro Implementação de Genéricos Coleções Conceito de Genérico Implementação Iteradores Conceito Utilização ForEach
Leia maisPadrões de Projeto de Software
Padrões de Projeto de Software Lista de Exercícios AV1 01 Luiz Leão luizleao@gmail.com http://www.luizleao.com Questão 1 Dentre as alternativas abaixo identifique a que NÃO define uma situação em que deve
Leia maisAula 4 Encapsulamento e Relacionamento Cleverton Hentz
Aula 4 Encapsulamento e Relacionamento Cleverton Hentz Sumário } Encapsulamento } Propriedades } Relacionamentos } Composição } Herança 2 O que é encapsulamento? } O que vocês entendem por encapsular?!
Leia mais3 Ferramenta Proposta 3.1. Objetivos
3 Ferramenta Proposta 3.1. Objetivos O objetivo deste trabalho é a criação de um framework de testes que incorpore algumas das novas idéias encontradas na literatura. Sua principal característica deve
Leia maisModificadores de acesso e atributos de classe
Modificadores de acesso e atributos de classe Material baseado na apostila FJ-11: Java e Orientação a Objetos do curso Caelum, Ensino e Inovação, disponível para download em http://www.caelum.com.br/apostilas/
Leia maisSingleton. Como a maioria dos programadores organizaria o código para acessar informação de configuração? Eis um exemplo:
Introdução Como a maioria dos programadores organizaria o código para acessar informação de configuração? Eis um exemplo: public class Config { public static final String DEFAULT_READ_COMMUNITY_NAME =
Leia maisPadrões Fábrica. Simple Factory Factory Method
Universidade Federal de Uberlândia Faculdade de Computação Disciplina: POO2 Prof. Fabiano Azevedo Dorça Padrões Fábrica Simple Factory Padrões Fábrica Padrão Simple Factory: fornece interfaces para criar
Leia maisARQUITETURA E DESENHO
ARQUITETURA E DESENHO DE SOFTWARE CMP 1063 Prof. Me. Fábio Assunção Parte 2 DESENHO DE SOFTWARE Espaço do problema Espaço da solução. Interpretação não literal. Orientação à escrita. Orientação à diagramação.
Leia maisOrientação a Objetos Parte I. Introdução a POO (Programação Orientada a Objetos)
Orientação a Objetos Parte I Introdução a POO (Programação Orientada a Objetos) Histórico Gerações de Linguagens de Programação Primeira Geração: Linguagem de máquina Segunda Geração: Linguagem de montagem
Leia maisTelevisao tamanho tela emitirsom. conectarperifericos
1 - Introdução a Programação Orientada a Objeto Para tentar solucionar o problema do baixo reaproveitamento de código, surgiu a idéia da Programação Orientada a Objeto (POO). A POO não é nova, sua formulação
Leia maisArquitetura de software
Arquitetura de software Problema: vamos implementar um clone do compraentrega.com.br Mantém preços atualizados Recebe encomendas e pagamento Recomenda itens a usuários Por onde começamos? Arquitetura =
Leia maisPadrões para atribuir responsabilidades: Baixo Acoplamento
Problema Padrão para atribuir responsabilidades: Baixo Acoplamento Como minimizar dependências e maximizar o reuso? O acoplamento é uma medida de quão fortemente uma classe está conectada, possui conhecimento
Leia maisEngenharia de Software II
Faculdade de Ciências e Tecnologia Departamento de Matemática e Computação Bacharelado em Ciência da Computação Engenharia de Software II Aula 01 (rogerio@fct.unesp.br) Bibliografia Básica PRESSMAN, R.
Leia maisDiagrama de Comunicação. SSC 526 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa
Diagrama de Comunicação SSC 526 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2013 1 2 O que já foi visto até agora Casos de Uso Completo Abstrato Diagrama de Casos
Leia maisUniversidade Federal de Uberlândia Faculdade de Computação Programação Orientada a Objetos II Prof. Fabiano Dorça. Padrão Observer (Observador)
Universidade Federal de Uberlândia Faculdade de Computação Programação Orientada a Objetos II Prof. Fabiano Dorça Problema: Definir uma dependência um-para-muitos entre objetos, de forma quando o estado
Leia maisObjetivos. Explorar os conceitos fundamentais acerca do uso herança na linguagem Java
Objetivos Explorar os conceitos fundamentais acerca do uso herança na linguagem Java Como a herança reutiliza código, vantagens e desvantagens, o problema weak base-class, acoplamento com herança, o uso
Leia maisCurso Superior de Banco de Dados
Curso Superior de Banco de Dados Disciplina: Spring Prof. Emanuel Mineda Carneiro emanuel.mineda@fatec.sp.gov.br São José dos Campos - SP Dependências do Jeito Antigo Injeção de Dependência Inversão de
Leia maisProgramação com Objectos. 2º Teste 2015/2016 1º Semestre
1/7 2015/2016 1º Semestre 13 de Janeiro de 2016, 18:30 (120 minutos) 2º Teste Nome: Número: Primeira Parte (3 valores) PERGUNTA RESPOSTA Segunda Parte (7 valores) PERGUNTA 1.1 2.1 1.2 2.2.1 1.3 2.2.2 1.4
Leia maisRPC e RMI. Sistemas Distribuídos. Mauro Lopes Carvalho Silva. Professor EBTT DAI Departamento de Informática Campus Monte Castelo
Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do Maranhão Objetivos Nesta aula
Leia maisProf. Me. Sérgio Carlos Portari Júnior
Prof. Me. Sérgio Carlos Portari Júnior Ambientes que visam desenvolver aplicações que precisam de um processamento paralelo e distribuído deverão saber lidar com algumas dificuldades. Isto decorre da heterogeneidade
Leia mais4 Conceito de Herança
4 Conceito de Herança Hierarquia de classes e mecanismo de ligação Herança Uma classe pode herdar operações de uma superclasse e as suas operações podem ser herdadas por subclasses. O mecanismo de herança
Leia maisProgramação Orientada a Objectos - P. Prata, P. Fazendeiro. Hierarquia de classes e mecanismo de ligação
4 Conceito de Herança Hierarquia de classes e mecanismo de ligação Herança Uma classe pode herdar operações de uma superclasse e as suas operações podem ser herdadas por subclasses. O mecanismo de herança
Leia maisLinguagem de Programação Orientada a Objeto Abstração - Encapsulamento
Linguagem de Programação Orientada a Objeto Abstração - Encapsulamento Professora Sheila Cáceres Variáveis locais Campos são um tipo de variável. Eles: armazenam valores por toda a vida de um objeto; e
Leia maisMatéria Introdutória. Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri
Matéria Introdutória Banco de Dados Motivação Necessidade de armazenar grandes quantidades de dados Necessidade de acessar as informações de maneira eficiente e segura Evolução histórica: desenvolvimento
Leia maisLinguagem de programação Programação Orientada a objetos
Instituto Federal de Minas Gerais Campus Ponte Nova Linguagem de programação Programação Orientada a objetos Professor: Saulo Henrique Cabral Silva Paradigma da orientação a objetos Paradigma = forma de
Leia maisHerança. Prof. Fernando V. Paulovich 23 de agosto de 2010
Herança SCC0604 - Programação Orientada a Objetos Prof. Fernando V. Paulovich http://www.icmc.usp.br/~paulovic paulovic@icmc.usp.br Instituto de Ciências Matemáticas e de Computação(ICMC) Universidade
Leia maisExemplos de Estilos Arquiteturais. Estilos Arquiteturais. Estilos Arquiteturais. Estilo: Pipe e Filtros
Estilos Arquiteturais Em geral sistemas seguem um estilo, ou padrão, de organização estrutural Os estilos diferem: nos tipos de componentes que usa na maneira como os componentes interagem com os outros
Leia maisProgramação com Objectos 2º Teste Tipo 1º Semestre (120 minutos)
1/8 Programação com Objectos 2º Teste Tipo 1º Semestre (120 minutos) Nome: Primeira Parte (7 valores) PERGUNTA NOTA 1.1.1 1.1.2 1.1.3 1.2 1.3 1.4 Segunda Parte (3 valores) PERGUNTA RESPOSTA 2.1 2.2 2.3
Leia maisPOO29004 Programação Orientada a Objetos
POO29004 Programação Orientada a Objetos Classe abstrata, interface e polimorfismo Prof. Emerson Ribeiro de Mello Instituto Federal de Santa Catarina IFSC campus São José mello@ifsc.edu.br http://docente.ifsc.edu.br/mello/poo
Leia maisEngenharia de Software
UNIVERSIDADE DE LISBOA INSTITUTO SUPERIOR TÉCNICO Engenharia de Software LEIC/LETI, 3 o Ano, 2 o Semestre 2 o Teste, 8 de Junho de 2016 Nome: Número: Este teste tem um conjunto de 10 perguntas de escolha
Leia mais