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!
Categoria: Engenharia
[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
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
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
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?