Intentions & Interfaces
Making patterns concrete
Udi Dahan – The Software Simplist
.NET Development Expert & SOA Specialist
www.UdiDahan.com
email@UdiDahan.com

Books, and books, and books, and books…

Flexibility brings many benefits

Preventing rigidity from creeping in

Existing solutions
Strategy Pattern
Visitor Pattern

Visitor pattern
Requires a method for
each ConcreteElement

Strategy pattern
Requires all classes to
contain a strategy

Application Code
May cause a collapse of
application structure
Infrastructure Code
at Co
ion de
lic
App Infrastructure Code

Doing too
much can hurt
ou
ren„t
onna
eed
t

“Prediction is very
difficult, especially if
it's about the future.”
-- Niels Bohr
Physics Nobel prize 1922

Bolt on flexibility where you need it

Sometimes called “hooks”
Application Code
Infrastructure Code
New
New
Code
Code

Flexibility you seek?
Hmm?
Made your roles
explicit, have you?
No?
That is why you fail.

Make
Roles
Explicit

Some well known interfaces
ISerializable IFather
IHusband
Java Serializable
IGoToWork
IComeHome
IWashTheDishes

Custom entity validation before persistence

The old “object-oriented” way
bool IsValidating;
.Validate();
Customer .Validate();
* Address
.Validate();
Order
But what if we start here?
Persistence

It looks like our
objects have
too many roles
to play

Make roles explicit

Add a marker interface here,
and an interface there….
IEntity
where T : IEntity
IValidator<T>
ValidationError Validate(T entity);

The first part is trivial:
IEntity
Customer
Order

The second part is more interesting
IValidator<T>
ValidationError Validate(T entity);
Customer
CustomerValidator: IValidator<Customer>
ValidationError Validate(Customer entity);

Add a dash of
Inversion of Control
Service-Locator style

The extensible way
.Persist(Customer)
Persistence
Service Locator Get<IValidator<Customer>>
new
Validate(Customer)
Customer Validator

But that’s not
Object Oriented
Is it?

Extensible and Object Oriented
.Persist(Customer)
Persistence
Service Locator Get<IValidator<Customer>>
new Validate(Customer)
Customer Validator
.Validate();
Customer

And application code stays simple
Application Code
.Persist(Customer)
Infrastructure Code

Loading objects from the DB
public class Customer
{
public void MakePreferred()
{
foreach(Order o in this.UnshippedOrders)
foreach(Orderline ol in o.OrderLines)
ol.Discount(10.Percent);
}
}
Lazy Loading

Dangers of Lazy Loading
public void MakePreferred()
{
foreach(Order o in this.UnshippedOrders)
foreach(Orderline ol in o.OrderLines)
ol.Discount(10.Percent);
}
DB

Loading objects from the DB
Making a customer
Adding an Order
“preferred”
Customer
Customer
Order
OrderLine

Need Different “Fetching Strategies”
public class ServiceLayer
{
public void MakePreferred(Id customerId)
{
Customer c = ORM.Get<Customer>(customerId);
c.MakePreferred();
}
public void AddOrder(Id customerId, OrderInfo o)
{
Customer c = ORM.Get<Customer>(customerId);
c.AddOrder(o);
}
}

Make
Roles
Explicit

Use interfaces to differentiate roles
IMakeCustomerPreferred IAddOrdersToCustomer
void MakePreferred(); void AddOrder(Order o);
Customer

Application code specifies role
public class ServiceLayer
{
public void MakePreferred(Id customerId)
{
IMakeCustomerPreferred c = ORM
.Get< IMakeCustomerPreferred>(customerId);
c.MakePreferred();
}
public void AddOrder(Id customerId, OrderInfo o)
{
IAddOrdersToCustomer c = ORM
.Get< IAddOrdersToCustomer>(customerId);
c.AddOrder(o);
}
}

Extend behavior around role
IMakeCustomerPreferred IAddOrdersToCustomer
void MakePreferred(); void AddOrder(Order o);
Customer
T
MakeCustomerPreferredFetchingStrategy :
Inherits
IFetchingStrategy<IMakeCustomerPreferred>
string Strategy { get {
return “UnshippedOrders, OrderLines”; } }
IFetchingStrategy<T>

The extensible way
.Get<IMakeCustomerPreferred>(id)
Persistence
Service Locator
Get<IFetchingStrategy<
new
IMakeCustomerPreferred>>
Get strategy
MakeCustomerPreferredFetchingStrategy

And the pattern repeats…
IMessage
where T : IEntity
IMessageHandler<T>
void Handle(T message);

Once your roles
made explicit,
you have…
Extensibility and
flexibility -
simple they will be

Thank you
Udi Dahan – The Software Simplist
.NET Development Expert & SOA Specialist
www.UdiDahan.com
email@UdiDahan.com