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.

Transcript

1. Software Design Patterns In the riveting context of Logging
2. No matter what anyone says... Everyone is a logger
3. The Lynch Me Pattern How a lot of us log
4. The Lynch Me Pattern Write this line at your own peril Doom FORCED logging How a lot of us log Dependency Injection
5. Never force a log! Logging should ALWAYS be optional
6. Design Pattern #1 The Decorator Pattern
7. Design Pattern #1 The Decorator Pattern 1 Remove the Logger
8. Design Pattern #1 The Decorator Pattern 1 Remove the Logger
9. Design Pattern #1 The Decorator Pattern 1 Remove the Logger 2 Place our http client as a property of a 'Decorator' object
10. 2 Place our http client as a property of a 'Decorator' object Design Pattern #1 The Decorator Pattern The HttpClientService object
11. 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()
12. 3 Forward all method calls to the decorated object with __call() Design Pattern #1 The Decorator Pattern
13. 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
14. 4 Put the logging in the decorator instead Design Pattern #1 The Decorator Pattern
15. 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
16. 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
17. 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
18. Design Pattern #2 The Observer Pattern
19. Design Pattern #2 The Observer Pattern 1 Add an observers class property to the object to be observed
20. 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
21. 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
22. Design Pattern #1 The Observer Pattern 2 Implement \SplObserver, \SplSubject and required methods \SplSubject (the client) \SplObserver (the logger)
23. 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!
24. 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
25. 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
26. Logging Don't force it, anywhere! Be a good logger Record inputs and outputs only ---> Decorator Record business logic results ---> Observer
27. Follow and/or stalk @J7mbo