Delphi

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 isso existe. Estamos basicamente nos referindo ao objetivo do padrão de projeto Interpreter!

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!

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. Acompanhe o artigo!

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?

Olá, amigos leitores! Feliz 2017! O primeiro artigo do ano, avançando na nossa temporada sobre Design Patterns, apresenta o próximo padrão de projeto estrutural, chamado Flyweight. Quebrei um pouco a cabeça para imaginar os cenários que este padrão de projeto possa ser adequado, mas, após muita leitura, consegui desvendá-lo! Confira o artigo!

Saudações, pessoal! Em algum momento, enquanto você codificava alguma funcionalidade, já identificou a necessidade de “envelopar” uma rotina complexa em apenas uma classe? Esse procedimento, também conhecido como wrapper, é basicamente o propósito do padrão de projeto que apresentarei neste artigo: o Façade. Você verá que o seu uso é relativamente comum na programação. Acompanhe!