![[Delphi] Design Patterns - Iterator](https://www.andrecelestino.com/wp-content/uploads/2017/06/imagem-artigo-iterator.jpg "[Delphi] Design Patterns GoF - Iterator")
Olá, leitores, estou de volta! Peço desculpas pela ausência.
O artigo de hoje finalmente retoma a série de artigos sobre Design Patterns. Em continuidade, discutiremos sobre um padrão de projeto que é pouco conhecido na teoria, mas bastante aplicado na prática: o Iterator. Talvez você mesmo já tenha codificado este padrão sem ter ciência. Acompanhe!
![[Delphi] Design Patterns GoF - Interpreter](https://www.andrecelestino.com/wp-content/uploads/2017/02/imagem-artigo-interpreter.png "[Delphi] Design Patterns GoF - Interpreter")
Boa noite, pessoal, tudo certo?
Quando solicitamos o build de um projeto no Delphi, o compilador é acionado para interpretar as instruções do código-fonte, gerando um executável como artefato.
Imagine se existisse uma forma de interpretar regras de negócio através de uma sintaxe definida, produzindo um resultado, semelhante a um compilador? Bom, a boa notÃcia é que existe, sim! Estamos basicamente nos referindo ao objetivo do padrão de projeto Interpreter!
![[Delphi] Design Patterns GoF - Command](https://www.andrecelestino.com/wp-content/uploads/2017/02/imagem-artigo-command.jpg "[Delphi] Design Patterns GoF - Command")
Olá, leitores! Já estamos no 14º artigo sobre Design Patterns!
Dentre todos os padrões de projetos já abordados até o momento, o Command, que será visto neste artigo, foi um dos mais custosos para compreender. Não pelo propósito, mas pela arquitetura de classes que são exigidas e também pela empregabilidade em um ambiente real. Procurei ser o mais objetivo possÃvel para evitar que o artigo ficasse muito extenso. Check it out!
![[Delphi] Design Patterns GoF - Chain of Responsibility](https://www.andrecelestino.com/wp-content/uploads/2017/01/imagem-artigo-chain-of-responsibility.jpg "[Delphi] Design Patterns GoF - Chain of Responsibility")
E aÃ, pessoal, tudo bem?
O artigo de hoje marca o inÃcio dos padrões de projetos Comportamentais. Recebem este nome por propor e recomendar soluções que envolvam interações entre objetos, de forma que, mesmo que exista essa interação, eles não dependam fortemente um do outro, ou seja, fiquem fracamente acoplados. O primeiro deste padrões, muito fácil de compreender, é o Chain of Responsibility. Já ouviu falar? Não? Então acompanhe o artigo!
![[Delphi] Design Patterns GoF - Proxy](https://www.andrecelestino.com/wp-content/uploads/2017/01/imagem-artigo-proxy.jpg "[Delphi] Design Patterns GoF - Proxy")
Boa noite, meus amigos!
No artigo passado, sobre o Flyweight, citei a importância do fator de desempenho em um sistema. O artigo de hoje também está relacionado à este requisito não-funcional, porém, abordando o próximo – e último – Design Pattern da famÃlia estrutural: o Proxy! Elaborei um exemplo prático bem instrutivo para apresentar as vantagens.
Vamos nessa?