Compre na Amazon, Submarino ou UmLivro
Veja também os cursos de extensão a distância Engenharia de Software Moderna (48 horas) e Teste de Software (20 horas), oferecidos pelo DCC/ICEX/UFMG.
Neste artigo, respondemos perguntas sobre temas relacionados com padrões de projeto, isto é, sobre o Capítulo 6 do livro.
Segue a lista atual de perguntas:
Suponha um objeto que tenha uma interface I
.
Um proxy implementa a interfaceI
,
isto é, implementa todos os seus métodos. Normalmente, um proxy é usado
para implementar requisitos não-funcionais, tais como segurança,
persistência, distribuição, etc.
Já um adaptador implementa uma outra interface,
digamos que J
e fica responsável por adaptá-la para a
interface I
. Para ilustrar, lembre-se de um adaptador de
tomadas do padrão novo para o antigo ou vice-versa.
Suponha uma classe X:
Suponha que a implementação de X precisa usar um serviço Y, o qual possui implementações alternativas Y1, Y2, Y3, etc. Porém, X não quer se comprometer com nenhuma dessas implementações. Nesse caso, podemos usar o padrão de projeto Strategy para encapsular a implementação de Y em uma hierarquia separada de classes e para permitir que sejam criadas instâncias de X que usam determinadas classes de tal hierarquia.
Suponha agora que ao implementar X queremos definir o esqueleto
de um algoritmo Y. Ou seja, X vai implementar Y, porém de forma parcial.
Isso significa que as implementações de Y serão completadas
em
subclasses de X. Nesse caso, podemos usar o padrão de projeto
Template Method para implementar esse esqueleto de Y na
classe X.
Uma especificação é um padrão proposto por Eric Evans e Martin Fowler no seguinte artigo. Ele é também comentado no livro sobre Domain-Driven Design do Evans.
Conceitualmente, uma especificação é um predicado lógico – isto é, uma função que retorna verdadeiro ou falso – e que encapsula uma regra de negócio importante e complexa.
Uma especificação testa se um objeto está em um certo estado. Seja,
por exemplo, uma fábrica que recebe pedidos de clientes para produção de
certos itens. Suponha ainda que a regra para determinar se um
Pedido
está atrasado, em relação ao seu prazo planejado de
entrega, é complicada. Por exemplo, ela pode depender dos itens que
foram pedidos, da capacidade de produção da fábrica, do tempo que leva
para entregar o pedido para o cliente, etc. Veja ainda que essas
condições são dinâmicas, pois o estoque da fábrica muda diariamente.
Logo, podemos criar uma classe para encapsular a verificação de pedidos atrasados:
class EspecificacaoPedidosAtrasados {
boolean pedidoEstaAtrasado(Pedido p) {
// regra que verifica se "p" está atrasado
}
}
Ou seja, a regra para determinar se um pedido está atrasado é
complexa a ponto de justificar sua especificação
em uma classe a
parte. E, então, Pedido
referencia essa nova classe:
class Pedido {
...
EspecificacaoPedidoAtrasado espec = new EspecificacaoPedidoAtrasado();
...
}
Resumindo, especificação é o nome que se dá para classes que apenas
implementam métodos booleanos que testam se um dado objeto atende a uma
regra de negócio mais complexa. Logo, uma especificação torna a classe
que usa a regra de negócio (no nosso exemplo, Pedido
) mais
simples e mais leve
, isto é, com menos dependências. Fica também
mais fácil criar regras de negócio alternativas. Por exemplo, uma
segunda regra pode verificar se pedidos expressos estão atrasados.
Voltar para a página principal.