update

Readwise/The Composition Over Inheritance Principle¶.md

@@ -30,3 +30,24 @@ And so the subclass explosion is avoided! Logger objects and adapter objects can
 
 The Bridge Pattern splits a class’s behavior between an outer “abstraction” object that the caller sees and an “implementation” object that’s wrapped inside. We can apply the Bridge Pattern to our logging example if we make the (perhaps slightly arbitrary) decision that filtering belongs out in the “abstraction” class while output belongs in the “implementation” class. [View Highlight](https://read.readwise.io/read/01j8bb0dxxf1dewfg0jyv6w8tn))
 
+---
+
+New highlights added at 2024-10-13 4:11 PM
+Instead of file output being native to the `Logger` but non-file output requiring an additional class, a functioning logger is now always built by composing an abstraction with an implementation. [View Highlight](https://read.readwise.io/read/01j8mcakzs1dpqmst4sgsxby1k))
+
+The reason we cannot stack two filters is that there’s an asymmetry between the interface they offer and the interface they wrap: they offer a `log()` method but call their handler’s `emit()` method. Wrapping one filter in another would result in an `AttributeError` when the outer filter tried to call the inner filter’s `emit()`.
+If we instead pivot our filters and handlers to offering the same interface, so that they all alike offer a `log()` method, then we have arrived at the Decorator Pattern [View Highlight](https://read.readwise.io/read/01j8r6kf6c1dp9y5sbaxss465r))
+
+Python logging module implements its own Composition Over Inheritance pattern.
+1. The `Logger` class that callers interact with doesn’t itself implement either filtering or output. Instead, it maintains a list of filters and a list of handlers.
+2. For each log message, the logger calls each of its filters. The message is discarded if any filter rejects it.
+3. For each log message that’s accepted by all the filters, the logger loops over its output handlers and asks every one of them to `emit()` the message. [View Highlight](https://read.readwise.io/read/01j8r76se8wen2j1m7g91bgp89))
+
+a logger’s messages might deserve both multiple filters *and* multiple outputs — to decouple filter classes and handler classes entirely [View Highlight](https://read.readwise.io/read/01j8r77jrx6spm326k65g9w54d))
+
+design principles like Composition Over Inheritance are, in the end, more important than individual patterns like the Adapter or Decorator. Always follow the principle. But don’t always feel constrained to choose a pattern from an official list. [View Highlight](https://read.readwise.io/read/01j8sgr5es60teb6y127ycdjnw))
+
+Sometimes, yes, you will find an existing Design Pattern that’s a perfect fit for your problem — but if not, your design might be stronger if you move beyond them. [View Highlight](https://read.readwise.io/read/01j8sgsc3731bd5qq2fxm6ww5e))
+
+I suggest that the apparent simplicity of the `if` statement forest is, from the point of view of software design, largely an illusion. [View Highlight](https://read.readwise.io/read/01j8sh7a9e0mf63x6r2fqpemh5))
+