Design Patterns
239 pág.

Design Patterns


DisciplinaEngenharia de Software I5.653 materiais57.890 seguidores
Pré-visualização50 páginas
together using boolean logic.
A specification pattern outlines a business
rule that is combinable with other business
rules. In this pattern, a unit of business logic
inherits its functionality from the abstract
aggregate Composite Specification class.
The Composite Specification class has one
function called IsSatisfiedBy that returns a
boolean value. After instantiation, the
specification is "chained" with other specifications, making new specifications easily maintainable, yet highly
customizable business logic. Furthermore upon instantiation the business logic may, through method invocation or
inversion of control, have its state altered in order to become a delegate of other classes such as a persistence
repository.
Code examples
C#
 public interface ISpecification {
 bool IsSatisfiedBy(object candidate);
 ISpecification And(ISpecification other);
 ISpecification Or(ISpecification other);
 ISpecification Not();
 }
Specification pattern 167
 public abstract class CompositeSpecification : ISpecification {
 public abstract bool IsSatisfiedBy(object candidate);
 public ISpecification And(ISpecification other) {
 return new AndSpecification(this, other);
 }
 public ISpecification Or(ISpecification other) {
 return new OrSpecification(this, other);
 }
 public ISpecification Not() {
 return new NotSpecification(this);
 }
 }
 public class AndSpecification : CompositeSpecification {
 private ISpecification One;
 private ISpecification Other;
 public AndSpecification(ISpecification x, ISpecification y) {
 One = x;
 Other = y;
 }
 public override bool IsSatisfiedBy(object candidate) {
 return One.IsSatisfiedBy(candidate) && 
Other.IsSatisfiedBy(candidate);
 }
 }
 public class OrSpecification : CompositeSpecification {
 private ISpecification One;
 private ISpecification Other;
 public OrSpecification(ISpecification x, ISpecification y) {
 One = x;
 Other = y;
 }
 public override bool IsSatisfiedBy(object candidate) {
 return One.IsSatisfiedBy(candidate) || 
Other.IsSatisfiedBy(candidate);
 }
 }
Specification pattern 168
 public class NotSpecification : CompositeSpecification {
 private ISpecification Wrapped;
 public NotSpecification(ISpecification x) {
 Wrapped = x;
 }
 public override bool IsSatisfiedBy(object candidate) {
 return !Wrapped.IsSatisfiedBy(candidate);
 }
 }
C# 3.0, simplified with generics and extension methods
 public interface ISpecification<TEntity> {
 bool IsSatisfiedBy(TEntity entity);
 }
 internal class AndSpecification<TEntity> : ISpecification<TEntity> {
 private ISpecification<TEntity> Spec1;
 private ISpecification<TEntity> Spec2;
 internal AndSpecification(ISpecification<TEntity> s1, ISpecification<TEntity> s2)
 {
 Spec1 = s1;
 Spec2 = s2;
 }
 public bool IsSatisfiedBy(TEntity candidate) {
 return Spec1.IsSatisfiedBy(candidate) && 
Spec2.IsSatisfiedBy(candidate);
 }
 }
 internal class OrSpecification<TEntity> : ISpecification<TEntity> {
 private ISpecification<TEntity> Spec1;
 private ISpecification<TEntity> Spec2;
 internal OrSpecification(ISpecification<TEntity> s1, ISpecification<TEntity> s2) 
{
 Spec1 = s1;
 Spec2 = s2;
 }
 public bool IsSatisfiedBy(TEntity candidate) {
 return Spec1.IsSatisfiedBy(candidate) || 
Spec2.IsSatisfiedBy(candidate);
 }
Specification pattern 169
 }
 internal class NotSpecification<TEntity> : ISpecification<TEntity> {
 private ISpecification<TEntity> Wrapped;
 internal NotSpecification(ISpecification<TEntity> x) {
 Wrapped = x;
 }
 public bool IsSatisfiedBy(TEntity candidate) {
 return !Wrapped.IsSatisfiedBy(candidate);
 }
 }
 public static class ExtensionMethods {
 public static ISpecification<TEntity> And<TEntity>(this ISpecification<TEntity> s1, 
ISpecification<TEntity> s2) {
 return new AndSpecification<TEntity>(s1, s2);
 }
 public static ISpecification<TEntity> Or<TEntity>(this ISpecification<TEntity> s1, 
ISpecification<TEntity> s2) {
 return new OrSpecification<TEntity>(s1, s2);
 }
 public static ISpecification<TEntity> Not<TEntity>(this ISpecification<TEntity> s) {
 return new NotSpecification<TEntity>(s);
 }
 }
Example of use
In this example, we are retrieving invoices and sending them to a collection agency if they are overdue, notices have
been sent and they are not already with the collection agency.
We previously defined an OverdueSpecification class that it is satisfied when an invoice's due date is 30 days or
older, a NoticeSentSpecification class that is satisfied when three notices have been sent to the customer, and an
InCollectionSpecification class that is satisfied when an invoice has already been sent to the collection agency.
Using these three specifications, we created a new specification called SendToCollection which will be satisfied
when an invoice is overdue, when notices have been sent to the customer, and are not already with the collection
agency.
OverDueSpecification OverDue = new OverDueSpecification();
NoticeSentSpecification NoticeSent = new NoticeSentSpecification();
InCollectionSpecification InCollection = new 
InCollectionSpecification();
ISpecification SendToCollection = 
OverDue.And(NoticeSent).And(InCollection.Not());
Specification pattern 170
InvoiceCollection = Service.GetInvoices();
foreach (Invoice currentInvoice in InvoiceCollection) {
 if (SendToCollection.IsSatisfiedBy(currentInvoice)) {
 currentInvoice.SendToCollection();
 }
}
References
\u2022\u2022 Evans, E: &quot;Domain-Driven Design.&quot;, page 224. Addison-Wesley, 2004.
External links
\u2022 Specifications [1] by Eric Evans and Martin Fowler
\u2022 The Specification Pattern: A Primer [2] by Matt Berther
\u2022 The Specification Pattern: A Four Part Introduction using VB.Net [3] by Richard Dalton
\u2022 specification pattern in flash actionscript 3 [4] by Rolf Vreijdenberger
References
[1] http:/ / www. martinfowler. com/ apsupp/ spec. pdf
[2] http:/ / www. mattberther. com/ 2005/ 03/ 25/ the-specification-pattern-a-primer/
[3] http:/ / www. codeproject. com/ KB/ architecture/ SpecificationPart1. aspx
[4] http:/ / www. dpdk. nl/ opensource/ specification-pattern-for-selection-on-lists
State pattern 171
State pattern
The state pattern, which closely resembles Strategy Pattern, is a behavioral software design pattern, also known as
the objects for states pattern. This pattern is used in computer programming to represent the state of an object. This
is a clean way for an object to partially change its type at runtime[1]:395.
Structure
State in UML[1][2]
State in LePUS3[2][3]
Example
Pseudocode
Take, for example, a drawing program. The program has a mouse cursor, which at any point in time can act as one of
several tools. Instead of switching between multiple cursor objects, the cursor maintains an internal state
representing the tool currently in use. When a tool-dependent method is called (say, as a result of a mouse click), the
method call is passed on to the cursor's state.
Each tool corresponds to a state. The shared abstract state class