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! ;)
2 comments:
A melhor prática de programação é apenas uma.
DONT DO SPAGHETTI CODE
Sim, esparguete, essa é a grande temática de toda a programação, não, não são os mil e um objectos e sua relações unárias, não são as suas heranças e suas cardinalidades, nem tão pouco seu tipo ou mesmo sua classe. Não. O que realmente interessa é não fazer esparguete cozido e mole, com as letras de a-z todas perdidas no meio da sopa programática.
É necessário uma receita, é necessário um chefe, e é necessário uma sentido apurado de quanto sal é preciso para dar o toque de mestre final.
Sim, é uma de um conjunto de "Best Practices". E quem sabe, um bom topico para mais um Post... ;) Obrigada pelo comentário!
Post a Comment