14147503 Intentions Interfaces Making Patterns Concrete
Upcoming SlideShare
Loading in...5
×
 

14147503 Intentions Interfaces Making Patterns Concrete

on

  • 1,021 views

 

Statistics

Views

Total Views
1,021
Slideshare-icon Views on SlideShare
1,021
Embed Views
0

Actions

Likes
1
Downloads
13
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    14147503 Intentions Interfaces Making Patterns Concrete 14147503 Intentions Interfaces Making Patterns Concrete Presentation Transcript

    • 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