Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Design Patterns - Lightning Talk

Design Patterns - Lightning Talk

A 6 minute lightning talk on two design patterns with a logging use case. Language: PHP. The main thing to take away from this is the decorator and observer patterns - the logging context is my personal opinion and mainly used to demonstrate the two patterns.

James Mallison

August 05, 2014
Tweet

More Decks by James Mallison

Other Decks in Technology

Transcript

  1. The Lynch Me Pattern Write this line at your own

    peril Doom FORCED logging How a lot of us log Dependency Injection
  2. Design Pattern #1 The Decorator Pattern 1 Remove the Logger

    2 Place our http client as a property of a 'Decorator' object
  3. 2 Place our http client as a property of a

    'Decorator' object Design Pattern #1 The Decorator Pattern The HttpClientService object
  4. Design Pattern #1 The Decorator Pattern 1 Remove the Logger

    2 Place our http client as a property of a 'Decorator' object 3 Forward all method calls to the decorated object with __call()
  5. 3 Forward all method calls to the decorated object with

    __call() Design Pattern #1 The Decorator Pattern
  6. Design Pattern #1 The Decorator Pattern 1 Remove the Logger

    2 Place our http client as a property of a 'Decorator' object 3 Forward all method calls to the decorated object with __call() 4 Put the logging in the decorator instead
  7. Design Pattern #1 The Decorator Pattern 1 Remove the Logger

    2 Place our http client as a property of a 'Decorator' object 3 Forward all method calls to the decorated object with __call() 4 Put the logging in the decorator instead
  8. Design Pattern #1 The Decorator Pattern • Object can be

    tested without mocking out a logger For the testing fanboys • Can be removed/modified without touching core code • You're not forcing anyone to log if they don't want to For normal developers For everyone • You use an industry standard pattern • You don't get hunted down and lynched
  9. Design Pattern #1 The Decorator Pattern BUT, we're only logging

    what goes in and what comes out (Request) (Response) What about anything that happens within the __call() forwarding (Business Logic) We're not actually logging anything happening inside here
  10. Design Pattern #2 The Observer Pattern 1 Add an observers

    class property to the object to be observed
  11. Design Pattern #2 The Observer Pattern 1 Add an observers

    class property to the object to be observed Two Loggers with differing implementations Response will randomly be either 'success' or 'error' Add the observers array
  12. Design Pattern #1 The Observer Pattern 1 Add an observers

    class property to the object to be observed 2 Implement \SplObserver, \SplSubject and required methods
  13. Design Pattern #1 The Observer Pattern 2 Implement \SplObserver, \SplSubject

    and required methods \SplSubject (the client) \SplObserver (the logger)
  14. Design Pattern #1 The Observer Pattern 1 Add an observers

    class property to the object to be observed 2 Implement \SplObserver, \SplSubject and required methods 3 Place notify() calls wherever you like!
  15. Design Pattern #2 The Observer Pattern 3 Place notify() calls

    wherever you like! The observer will need to call getters to get the data it needs Loops around observers, runs "update" method on each one
  16. Design Pattern #2 The Observer Pattern • Add / remove

    observer loggers, nothing changes • You're not forcing anyone to log if they don't want to For normal developers For everyone • You use an industry standard pattern • You don't get hunted down and lynched
  17. Logging Don't force it, anywhere! Be a good logger Record

    inputs and outputs only ---> Decorator Record business logic results ---> Observer