Aula 5
Descrevem princípios fundamentais de atribuição de responsabilidade a objetos.
Alguns padrões GRASP principais:
· Especialista
· Criador
· Coesão alta
· Acoplamento fraco
· Controlador
Especialista.
Problema: qual é o princípio mais básico para atribuir responsabilidades no projeto orientado a objetos?
Solução: Atribuir responsabilidade ao especialista da informação.
Criador.
Problema: Quem deveria ser responsável pela criação de uma nova instância de alguma classe?
Solução: atribua à classe B a responsabilidade de criar uma nova instância da classe A se uma das seguintes condições for verdadeira:
B agrega objetos de A
B contém objetos de A
B registra instâncias de objetos de A
B usa objetos de A B tem os valores iniciais que serão passados para objetos de A, quando de sua criação.
Coesão alta.
Objeto com Coesão Alta -> objetos cujas responsabilidades são altamente relacionadas e que não executa um volume muito grande de trabalho.
Acoplamento fraco O acoplamento mede o quanto um objeto está conectado a, tem conhecimento de ou depende de outros objetos
Acoplamento fraco (ou baixo) – um objeto não depende de muitos outros. (desejavél)
Acoplamento forte (ou alto) – um objeto depende de muitos outros.
Controlador.
É um objeto de interface (não interfacede usuário) responsável por tratar um evento externo (evento de sistema). Define o método para a operação de sistema.
Referências:
http://www.google.com.br/
http://www.wikipedia.org/
Material apresentado em sala.
Abraços Diogo
quinta-feira, 21 de fevereiro de 2008
quinta-feira, 14 de fevereiro de 2008
Padrões
Aula 5
O conceito de padrão de projeto foi criado na década de 70 pelo arquiteto Christopher Alexander. Em seus livros Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language, ele estabelece que um padrão deve ter, idealmente, as seguintes características:
· encapsulamento; um padrão encapsula um problema/solução bem definido. Ele deve ser independente, específico e formulado de maneira a ficar claro onde ele se aplica.
· generalidade; todo padrão deve permitir a construção de outras realizações a partir deste padrão.
· equilíbrio; quando um padrão é utilizado em uma aplicação, o equilíbrio dá a razão, relacionada com cada uma das restrições envolvidas, para cada passo do projeto. Uma análise racional que envolva uma abstração de dados empíricos, uma observação da aplicação de padrões em artefatos tradicionais, uma série convincente de exemplos e uma análise de soluções ruins ou fracassadas pode ser a forma de encontrar este equilíbrio.
· abstração; os padrões representam abstrações da experiência empírica ou do conhecimento cotidiano.
· abertura; um padrão deve permitir a sua extensão para níveis mais baixos de detalhe.
· combinatoriedade; os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos ou relacionados com padrões que endereçam problemas de nível mais baixo.
Além da definição das características de um padrão, Alexander definiu o formato que a descrição de um padrão deve ter. Ele estabeleceu que um padrão deve ser descrito em cinco partes:
nome; uma descrição da solução, mais do que do problema ou do contexto.
exemplo; uma ou mais figuras, diagramas ou descrições que ilustrem um protótipo de aplicação.
contexto; a descrição das situações sob as quais o padrão se aplica.
problema; uma descrição das forças e restrições envolvidos e como elas interagem.
solução; relacionamentos estáticos e regras dinâmicas descrevendo como construir artefatos de acordo com o padrão, freqüentemente citando variações e formas de ajustar a solução segundo as circunstâncias. Inclui referências a outras soluções e o relacionamento com outros padrões de nível mais baixo ou mais alto.
Em 1987, a partir dos conceitos criados por Alexander, os programadores Kent Beck e Ward Cunningham propuseram os primeiros padrões de projeto para a área da ciência da computação. Em um trabalho para a conferência OOPSLA, eles apresentaram alguns padrões para a construção de janelas na linguagem Smalltalk. Nos anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento desta idéias.
O movimento ao redor de padrões de projeto ganhou popularidade com o livro Design Patterns: Elements of Reusable Object-Oriented Software, publicado em 1995. Os autores desse livro são Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente "GoF". Posteriormente, vários outros livros do estilo foram publicados, como Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, que introduziu um conjunto de padrões conhecidos como GRASP (General Responsibility Assignment Software Patterns).
Referências:
http://pt.wikipedia.org/
http://www.google.com.br/
material associado na aula.
Abraços.
Diogo Viana Rabelo
O conceito de padrão de projeto foi criado na década de 70 pelo arquiteto Christopher Alexander. Em seus livros Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language, ele estabelece que um padrão deve ter, idealmente, as seguintes características:
· encapsulamento; um padrão encapsula um problema/solução bem definido. Ele deve ser independente, específico e formulado de maneira a ficar claro onde ele se aplica.
· generalidade; todo padrão deve permitir a construção de outras realizações a partir deste padrão.
· equilíbrio; quando um padrão é utilizado em uma aplicação, o equilíbrio dá a razão, relacionada com cada uma das restrições envolvidas, para cada passo do projeto. Uma análise racional que envolva uma abstração de dados empíricos, uma observação da aplicação de padrões em artefatos tradicionais, uma série convincente de exemplos e uma análise de soluções ruins ou fracassadas pode ser a forma de encontrar este equilíbrio.
· abstração; os padrões representam abstrações da experiência empírica ou do conhecimento cotidiano.
· abertura; um padrão deve permitir a sua extensão para níveis mais baixos de detalhe.
· combinatoriedade; os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos ou relacionados com padrões que endereçam problemas de nível mais baixo.
Além da definição das características de um padrão, Alexander definiu o formato que a descrição de um padrão deve ter. Ele estabeleceu que um padrão deve ser descrito em cinco partes:
nome; uma descrição da solução, mais do que do problema ou do contexto.
exemplo; uma ou mais figuras, diagramas ou descrições que ilustrem um protótipo de aplicação.
contexto; a descrição das situações sob as quais o padrão se aplica.
problema; uma descrição das forças e restrições envolvidos e como elas interagem.
solução; relacionamentos estáticos e regras dinâmicas descrevendo como construir artefatos de acordo com o padrão, freqüentemente citando variações e formas de ajustar a solução segundo as circunstâncias. Inclui referências a outras soluções e o relacionamento com outros padrões de nível mais baixo ou mais alto.
Em 1987, a partir dos conceitos criados por Alexander, os programadores Kent Beck e Ward Cunningham propuseram os primeiros padrões de projeto para a área da ciência da computação. Em um trabalho para a conferência OOPSLA, eles apresentaram alguns padrões para a construção de janelas na linguagem Smalltalk. Nos anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento desta idéias.
O movimento ao redor de padrões de projeto ganhou popularidade com o livro Design Patterns: Elements of Reusable Object-Oriented Software, publicado em 1995. Os autores desse livro são Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente "GoF". Posteriormente, vários outros livros do estilo foram publicados, como Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, que introduziu um conjunto de padrões conhecidos como GRASP (General Responsibility Assignment Software Patterns).
Referências:
http://pt.wikipedia.org/
http://www.google.com.br/
material associado na aula.
Abraços.
Diogo Viana Rabelo
quarta-feira, 13 de fevereiro de 2008
Orientação a objetos
A orientação a objetos, também conhecida como Programação Orientada a Objetos (POO) ou ainda em inglês Object-Oriented Programming (OOP) é um paradigma de análise, projeto e programação de sistemas de software baseado na composição e interação entre diversas unidades de software chamadas de objetos
Em alguns contextos, prefere-se usar modelagem orientada ao objeto, em vez de projeto.
A análise e projeto orientados a objetos têm como meta identificar o melhor conjunto de objetos para descrever um sistema de software. O funcionamento deste sistema se dá através do relacionamento e troca de mensagens entre estes objetos.
Na programação orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes no sistema de software. Cada classe determina o comportamento (definidos nos métodos) e estados possíveis (atributos) de seus objetos, assim como o relacionamento com outros objetos.
Em alguns contextos, prefere-se usar modelagem orientada ao objeto, em vez de projeto.
A análise e projeto orientados a objetos têm como meta identificar o melhor conjunto de objetos para descrever um sistema de software. O funcionamento deste sistema se dá através do relacionamento e troca de mensagens entre estes objetos.
Na programação orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes no sistema de software. Cada classe determina o comportamento (definidos nos métodos) e estados possíveis (atributos) de seus objetos, assim como o relacionamento com outros objetos.
Alguns tipos de linguagem orientada a objeto são:
· Smalltalk
· Python
· Ruby
· C++
· Object Pascal
· Java
· C#
Assinar:
Postagens (Atom)
