Engineering

Olá, leitores! De todos os Design Patterns abordados até o momento, talvez o Observer seja um dos mais fáceis, tanto de compreender, quanto de implementar. Veremos que a sua proposta é bem interessante em relação à comunicação entre objetos. Durante o artigo, é possível que vocês lembrem ou identifiquem situações em que este padrão de projeto cairia bem. Sem mais delongas, apresento-lhes o Observer!

Saudações, caros leitores! Como bons programadores, sabemos que, em muitas ocasiões, é preciso salvar o estado atual de um objeto ou entidade antes de realizar uma operação, de forma que possamos restaurá-lo caso necessário. Um bom exemplo é o controle de transação de banco de dados – quando um erro ocorre, executamos um rollback na operação, restaurando o estado anterior de uma tabela. Esse procedimento de armazenamento e restauração de estados é basicamente o objetivo do Design Pattern deste artigo, chamado Memento.

Boa noite, pessoal! Em algumas ocasiões, um intermediário para coordenar as mensagens e interações entre objetos pode parecer uma solução adequada para evitar a forte dependência entre eles. Com o Mediator, essa solução é factível. Veremos, neste artigo, o conceito, propósito e uma aplicação prática deste padrão de projeto, mas, de antemão, já esclareço: o Mediator é bem fácil de compreender. 😉

Olá, leitores, estou de volta! 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!

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!