Ainda no seguimento do tópico Patterns, resolvi abordar um pouco mais os Design Patterns. Estou a ler algumas passagens do livro do GoF e aqui estão algumas impressões gerais, que podem ser interessantes.
O que é um Design Pattern?
Cristopher Alexander, um arquitecto que trouxe à tona este topico na decada de 70, no contexto da construção, dá uma definição de Patterns: "Each pattern describes a problem which occurs over and over in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it in the same way twice."
Os Patterns recorrentes pretendem resolver problemas de desenho e construir desenhos orientados a objectos mais flexiveis, elegantes, e reutilizaveis. Ajudam a construir novos desenhos baseados em experiencias anteriores de desenho e arquitecturas de sistemas.
Em geral, um pattern tem quatro elementos essenciais:
- Nome: descreve o problema de desenho, as suas soluções e consequencias, numa palavra ou duas. Dar nome a um pattern aumenta o nosso vocabulario de desenho!
- Problema: descreve quando aplicar o Pattern. Explica o problema e o seu contexto.
- Solução: descreve os elementos que constituem o desenho, as suas relações, responsabilidades e colaborações. Não descreve um desenho ou uma implementação em concreto, porque um Pattern é uma especie de template que pode ser aplicado em diferentes situações. O Pattern fornece uma descrição abstracta de um problema de desenho e como uma organização genérica dos elementos o resolve.
- Consequências: são o resultado e as vantagens de aplicar o Pattern. Dado que a reutilização é importante no desenho orientado a objectos, as consequências de aplicar um Pattern devem incluir o impacto que tem a solução.
Esta abordagem a Design Patterns (a feita no livro do GoF) descreve-os como "descrições de objectos e classes que comunicam entre si, customizados para resolver problemas de desenho genéricos num contexto especifico". No entanto, num tema tão aberto como este, as abordagens acabam por também variar. Há que escolher a mais adequada ao nosso contexto em cada momento.
Assim.....
Como escolher um Design Pattern
Há MUITOS Design Patterns catalogados, uns mais divulgados que outros. Por isso, como escolher dentre uma miriade de Patterns, a maioria deles provavelmente sendo novidade para nós? (Ok, são só umas dezenas valentes... mas pronto... :))
O GoF dá uma ajudinha, fornecendo diferentes abordagens para encontrar o Design Pattern mais adequado.
- Analiza como os Design Patterns resolvem problemas de desenho
- Percebe o objectivo do Pattern
- Estuda como os Patterns se relacionam entre si
- Estuda Patterns de objectivos similares
- Examina a causa que levou à necessidade de redesenhar
- Considera o que deve ser variável no desenho sem ter de redesenhar
Esta abordagem aos Design Patterns é naturalmente muito vocacionada ao contexto apresentado pelo GoF. Mas mesmo generalizando, há pontos em comum com as nossas realidades que podem até ser um pouco diferentes, mas às quais podemos adaptar alguns destes principios.
Espero que pelo menos sirvam como bom ponto de partida para passarmos a utilizar Patterns em geral!
Divirtam-se! :)
Tuesday, April 17, 2007
Wednesday, April 11, 2007
Patterns - Architectural, Design e outros...
Estive a preparar uma pequena apresentação sobre Patterns, um tópico alvo de algumas discussões e diferenças de opinião, já que não é ainda um conceito 'completo', está ainda em evolução e é susceptivel de diferentes abordagens!
Mas alguns (sub?) conceitos começam já a tomar forma, e é sobre esses que escolhi falar.
Cá vai então um resumo do tema.
O que são Patterns?
Há várias definições à volta desse termo.
"Uma solução para um problema num dado contexto"
"Formas de dividir um problema"
"Desenho que endereça um problema recorrente em sistemas OO"
"Orientada à resolução de problemas em design mode"
Escolhi os seguintes tópicos, que creio definem bem o que são Patterns:
- Menos focado em tencologia, e mais numa cultura de documentação e suporte de desenho
- Cada padrão é uma regra de 3 partes, que expressa a relação entre um determinado contexto, um problema e uma solução
- Um padrão faz mais do que identificar uma solução; tambem explica porque a solução é necessária!
Porque usar?
Parte do interesse em Patterns advem de "observarmos que o projecto falha, apesar de utilizar a ultima tecnologia, porque tem falta de soluções comuns!"
São "best practices"
Permitem definir regras no desenho de soluções
Fornece uma base de trabalho, onde tudo 'encaixa'
Tipos de Patterns
Devido à grande aceitação do livro do Gang of Four, os design patterns tornaram-se comuns. São OO Design Patterns (há outros tipos de patterns)
Os que escolhi:
- Architectural Patterns:
. Expressam uma organização estrutural fundamental ou um esquema para sistemas de software. . Fornecem um conjunto de subsistemas predefinidos, especifica as suas responsabilidades, e inclui regras e guidelines para organizar as relações entre eles.
- Design Patterns:
. Fornece um esquema para refinar os subsistemas ou componentes de um sistema de software, ou as relações entre eles.
Descrevem a estrutura recorrente de comunicação entre componentes que resolve um problema de desenho num dado contexto.
Anti-patterns:
Se um Pattern representa "best practices", um anti-pattern representa "lessons learned".
Duas abordagens comuns de anti-patterns:
- a que descreve uma má solução para um problema que resultou numa má situação
- a que descreve como sair de uma má situação e avançar para uma boa situação
Porque "Identificar más práticas pode ser tão valioso como identificar boas práticas".
Em Detalhe - Design Patterns:
- Definição simplista: "Um design pattern consiste em vários objectos que colaboram entre si (classes, relações, etc...). Fornecem soluções para problemas de desenho comuns. Oferecem um idioma consistente entre quem desenha e quem implementa (permitem comunicar utilizando nomes bem conhecidos para as interações de software).
- Não é código. É uma abordagem, um template, um modelo, que pode ser utilizado para resolver um problema.
- (Algoritmos nao sao Design Patterns, porque resolvem problemas computacionais e nao problemas de desenho)
- O principio basico da utilização de patterns é a reutilização.
Exemplo de um design pattern utilizado num projecto da Lucent:
Description
Name: Try All Hardware Combos
Problem: The control complex of a fault-tolerant system can arrange its subsystems in many different configurations. There are many possible paths through the subsystems. How do you select a workable configuration when there is a faulty subsystem?
Context: The processing complex has several duplicated subsystems including a CPU, static and dynamic memory, and several busses. Standby units increase system reliability. 16 possible configurations (64 in the 4 ESS) of these subsystems give fully duplicated sparing in the 5ESS. Each such configuration is called a configuration state.
Forces: You want to catch and remedy single, isolated errors. You also want to catch errors that aren't easily detected in isolation but result from interaction between modules. You sometimes must catch multiple concurrent errors. The CPU can't sequence subsystems through configurations since it may itself be faulty. The machine should recover by itself without human intervention, many high-availability system failures come from operator errors, not primary system errors. We want to reserve human expertise for problems requiring only the deepest insights.
Solution: Maintain a 16-state counter in hardware called the configuration counter. There is a table that maps that counter onto a configuration state. The 5ESS switch tries all side 0 units (a complete failure group), then all side 1 units (the other failure group), seeking an isolated failure. When a reboot fails, the state increments and the system tries to reboot again. The subsequent counting states look for multiple concurrent failures caused by interactions between system modules.
Resulting Context: Sometimes the fault isn't detected during the reboot because latent diagnostic tasks elicit the errors. The pattern Fool Me Once solves this problem. And sometimes going through all the counter states isn't enough; see the patterns Don't Trust Anyone and Analog Timer.
Rationale: The design is based on hardware module design failure rates (in Failures in a trillion (FITs)) of the hardware modules. The pattern recalls the extreme caution of first-generation developers of stored program control switching systems.
Porque é considerado um bom Pattern:
- Resolve um problema concreto
- É fundamentado e documentado
- Como a solução não é óbvia, fornece a abordagem necessária à solução do problema
- Descreve relações
- Tem uma componente humana significativa (o software é feito para humanos)
Em Detalhe - Architectural Patterns
- São padrões de software que oferecem soluções estáveis para problemas de arquitectura.
- Alguns exemplos de Architectural Patterns:
- Three-tier: aplicação de 3 camadas (user interface, lógica de negócio e acesso a dados, e camada de dados)
- Model-View-Controller: separa o modelo de dados da user interface. Introduz um componente pelo meio, que tem a responsabilidade de controlar os dois anteriores.
- PAC / HMVC: utiliza uma estrutura hierarquica de agentes, cada um consistindo num trio de componentes (apresentação, abstracção e controle)
. PAC: os agentes comunicam entre si através do controlador
. HMVC: os agentes comunicam entre si através do controlador, e tambem através da vista e do modelo
- SOA: Service-Oriented Architecture, que utiliza loosely-coupled services para dar suporte ao negócio
- ...
Vantagens reais:
- Maior estruturação do código
- Maior escalabilidade
- Código com mais qualidade
- Tudo ‘encaixa’ no Pattern
E pronto! foram algumas dicas sobre Patterns, mas não se entusiasmem! Há muito mais sobre Patterns para alem disto!
Incluo algumas referencias que podem ser uteis e ajudar a continuar a partir daqui!
References
http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html
http://www.martinfowler.com/articles/writingPatterns.html
http://wi.wu-wien.ac.at/home/uzdun/publications/ArchPatterns.pdf
http://www.martinfowler.com/eaaCatalog/
http://hillside.net/patterns/definition.html
http://www.codefarms.com/publications/papers/patterns.html
http://www.castleproject.org/monorail/gettingstarted/firstcontroller.html
Divirtam-se! ;)
Mas alguns (sub?) conceitos começam já a tomar forma, e é sobre esses que escolhi falar.
Cá vai então um resumo do tema.
O que são Patterns?
Há várias definições à volta desse termo.
"Uma solução para um problema num dado contexto"
"Formas de dividir um problema"
"Desenho que endereça um problema recorrente em sistemas OO"
"Orientada à resolução de problemas em design mode"
Escolhi os seguintes tópicos, que creio definem bem o que são Patterns:
- Menos focado em tencologia, e mais numa cultura de documentação e suporte de desenho
- Cada padrão é uma regra de 3 partes, que expressa a relação entre um determinado contexto, um problema e uma solução
- Um padrão faz mais do que identificar uma solução; tambem explica porque a solução é necessária!
Porque usar?
Parte do interesse em Patterns advem de "observarmos que o projecto falha, apesar de utilizar a ultima tecnologia, porque tem falta de soluções comuns!"
São "best practices"
Permitem definir regras no desenho de soluções
Fornece uma base de trabalho, onde tudo 'encaixa'
Tipos de Patterns
Devido à grande aceitação do livro do Gang of Four, os design patterns tornaram-se comuns. São OO Design Patterns (há outros tipos de patterns)
Os que escolhi:
- Architectural Patterns:
. Expressam uma organização estrutural fundamental ou um esquema para sistemas de software. . Fornecem um conjunto de subsistemas predefinidos, especifica as suas responsabilidades, e inclui regras e guidelines para organizar as relações entre eles.
- Design Patterns:
. Fornece um esquema para refinar os subsistemas ou componentes de um sistema de software, ou as relações entre eles.
Descrevem a estrutura recorrente de comunicação entre componentes que resolve um problema de desenho num dado contexto.
Anti-patterns:
Se um Pattern representa "best practices", um anti-pattern representa "lessons learned".
Duas abordagens comuns de anti-patterns:
- a que descreve uma má solução para um problema que resultou numa má situação
- a que descreve como sair de uma má situação e avançar para uma boa situação
Porque "Identificar más práticas pode ser tão valioso como identificar boas práticas".
Em Detalhe - Design Patterns:
- Definição simplista: "Um design pattern consiste em vários objectos que colaboram entre si (classes, relações, etc...). Fornecem soluções para problemas de desenho comuns. Oferecem um idioma consistente entre quem desenha e quem implementa (permitem comunicar utilizando nomes bem conhecidos para as interações de software).
- Não é código. É uma abordagem, um template, um modelo, que pode ser utilizado para resolver um problema.
- (Algoritmos nao sao Design Patterns, porque resolvem problemas computacionais e nao problemas de desenho)
- O principio basico da utilização de patterns é a reutilização.
Exemplo de um design pattern utilizado num projecto da Lucent:
Description
Name: Try All Hardware Combos
Problem: The control complex of a fault-tolerant system can arrange its subsystems in many different configurations. There are many possible paths through the subsystems. How do you select a workable configuration when there is a faulty subsystem?
Context: The processing complex has several duplicated subsystems including a CPU, static and dynamic memory, and several busses. Standby units increase system reliability. 16 possible configurations (64 in the 4 ESS) of these subsystems give fully duplicated sparing in the 5ESS. Each such configuration is called a configuration state.
Forces: You want to catch and remedy single, isolated errors. You also want to catch errors that aren't easily detected in isolation but result from interaction between modules. You sometimes must catch multiple concurrent errors. The CPU can't sequence subsystems through configurations since it may itself be faulty. The machine should recover by itself without human intervention, many high-availability system failures come from operator errors, not primary system errors. We want to reserve human expertise for problems requiring only the deepest insights.
Solution: Maintain a 16-state counter in hardware called the configuration counter. There is a table that maps that counter onto a configuration state. The 5ESS switch tries all side 0 units (a complete failure group), then all side 1 units (the other failure group), seeking an isolated failure. When a reboot fails, the state increments and the system tries to reboot again. The subsequent counting states look for multiple concurrent failures caused by interactions between system modules.
Resulting Context: Sometimes the fault isn't detected during the reboot because latent diagnostic tasks elicit the errors. The pattern Fool Me Once solves this problem. And sometimes going through all the counter states isn't enough; see the patterns Don't Trust Anyone and Analog Timer.
Rationale: The design is based on hardware module design failure rates (in Failures in a trillion (FITs)) of the hardware modules. The pattern recalls the extreme caution of first-generation developers of stored program control switching systems.
Porque é considerado um bom Pattern:
- Resolve um problema concreto
- É fundamentado e documentado
- Como a solução não é óbvia, fornece a abordagem necessária à solução do problema
- Descreve relações
- Tem uma componente humana significativa (o software é feito para humanos)
Em Detalhe - Architectural Patterns
- São padrões de software que oferecem soluções estáveis para problemas de arquitectura.
- Alguns exemplos de Architectural Patterns:
- Three-tier: aplicação de 3 camadas (user interface, lógica de negócio e acesso a dados, e camada de dados)
- Model-View-Controller: separa o modelo de dados da user interface. Introduz um componente pelo meio, que tem a responsabilidade de controlar os dois anteriores.
- PAC / HMVC: utiliza uma estrutura hierarquica de agentes, cada um consistindo num trio de componentes (apresentação, abstracção e controle)
. PAC: os agentes comunicam entre si através do controlador
. HMVC: os agentes comunicam entre si através do controlador, e tambem através da vista e do modelo
- SOA: Service-Oriented Architecture, que utiliza loosely-coupled services para dar suporte ao negócio
- ...
Vantagens reais:
- Maior estruturação do código
- Maior escalabilidade
- Código com mais qualidade
- Tudo ‘encaixa’ no Pattern
E pronto! foram algumas dicas sobre Patterns, mas não se entusiasmem! Há muito mais sobre Patterns para alem disto!
Incluo algumas referencias que podem ser uteis e ajudar a continuar a partir daqui!
References
http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html
http://www.martinfowler.com/articles/writingPatterns.html
http://wi.wu-wien.ac.at/home/uzdun/publications/ArchPatterns.pdf
http://www.martinfowler.com/eaaCatalog/
http://hillside.net/patterns/definition.html
http://www.codefarms.com/publications/papers/patterns.html
http://www.castleproject.org/monorail/gettingstarted/firstcontroller.html
Divirtam-se! ;)
Subscribe to:
Posts (Atom)