Software Design Patterns In the riveting context of Logging

No matter what anyone says... Everyone is a logger

The Lynch Me Pattern How a lot of us log

The Lynch Me Pattern Write this line at your own peril Doom FORCED logging How a lot of us log Dependency Injection

Never force a log! Logging should ALWAYS be optional

Design Pattern #1 The Decorator Pattern

Design Pattern #1 The Decorator Pattern 1 Remove the Logger

Design Pattern #1 The Decorator Pattern 1 Remove the Logger

Design Pattern #1 The Decorator Pattern 1 Remove the Logger 2 Place our http client as a property of a 'Decorator' object

2 Place our http client as a property of a 'Decorator' object Design Pattern #1 The Decorator Pattern The HttpClientService object

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()

3 Forward all method calls to the decorated object with __call() Design Pattern #1 The Decorator Pattern

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

4 Put the logging in the decorator instead Design Pattern #1 The Decorator Pattern

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

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

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

Design Pattern #2 The Observer Pattern

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

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

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

Design Pattern #1 The Observer Pattern 2 Implement \SplObserver, \SplSubject and required methods \SplSubject (the client) \SplObserver (the logger)

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!

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

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

Logging Don't force it, anywhere! Be a good logger Record inputs and outputs only ---> Decorator Record business logic results ---> Observer

Follow and/or stalk @J7mbo