P. 1
Intentions & Interfaces - Making Patterns Concrete

Intentions & Interfaces - Making Patterns Concrete

|Views: 283|Likes:
Published by Best Tech Videos
The pattern movement is shifting into high gear. Not only are more patterns coming out, but they are at higher levels and have deeper meanings than ever before. Unfortunately, many developers are having problems incorporating these patterns in day-to-day development.

In this session, we will see the practical aspects of intentional, interface-based programming that are at the core of almost all advanced patterns. You will leave this session being able to write more maintainable, intention-revealing code than before.

Watch a video at http://www.bestechvideos.com/2009/04/10/making-patterns-concrete
The pattern movement is shifting into high gear. Not only are more patterns coming out, but they are at higher levels and have deeper meanings than ever before. Unfortunately, many developers are having problems incorporating these patterns in day-to-day development.

In this session, we will see the practical aspects of intentional, interface-based programming that are at the core of almost all advanced patterns. You will leave this session being able to write more maintainable, intention-revealing code than before.

Watch a video at http://www.bestechvideos.com/2009/04/10/making-patterns-concrete

More info:

Published by: Best Tech Videos on Apr 11, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/22/2012

pdf

text

original

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

May cause a collapse of application structure

Application Code Infrastructure Code

at

Co

lic
App

ion

de

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 Code

New 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 Java IFather IHusband IGoToWork IComeHome IWashTheDishes

Serializable

Custom entity validation before persistence

The old “object-oriented” way
.Validate();
bool IsValidating;

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
new

Get<IValidator<Customer>>

Validate(Customer)

Customer Validator

But that’s not Object Oriented
Is it?

Extensible and Object Oriented
.Persist(Customer)

Persistence

Service Locator
new

Get<IValidator<Customer>> 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 “preferred” Customer Adding an Order

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 void MakePreferred(); IAddOrdersToCustomer

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 void MakePreferred(); IAddOrdersToCustomer

void AddOrder(Order o);

Customer

T Inherits

MakeCustomerPreferredFetchingStrategy :
IFetchingStrategy<IMakeCustomerPreferred> string Strategy { get {

IFetchingStrategy<T>

return “UnshippedOrders, OrderLines”; } }

The extensible way
.Get<IMakeCustomerPreferred>(id)

Persistence Service Locator
new Get<IFetchingStrategy< 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

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->