Design a Logger that passes each message through a list of handlers

Design a small logging component. A `Logger` is constructed with a list of handlers, and `log(message)` passes the message through all of the handlers, one after another, in that order. Implement two handlers: - `TruncateHandler`, which shortens the message; - `StoreHandler`, which prints nothing and instead appends the message to an internal list. This was a low-level design (object-oriented design) round: the code did not have to run, and the discussion centered on how the interfaces are designed. Assume each handler receives the message as left by the previous handler, so a `StoreHandler` placed after a `TruncateHandler` stores the shortened text. The report does not give a truncation length; treat it as a parameter. ```hint One contract for every handler Decide what a handler receives and what it hands back, so that the Logger never needs to know which concrete handler it is calling. ``` ```hint Order is behavior Work out what a StoreHandler holds when it comes before a TruncateHandler and when it comes after one. ``` ### Constraints and Clarifications - Handlers run in the order in which they were passed to the constructor. - Messages are strings. - Adding a new kind of handler must not require changing `Logger`. ### Clarifying Questions - Does each handler see the previous handler's output, or does every handler receive the original message? - How should truncation behave: a fixed maximum number of characters, with or without a marker such as an ellipsis, and what happens with a limit of zero? - How do callers read what `StoreHandler` has stored, and may they modify it? - If one handler raises an exception, should the remaining handlers still run? ### What a Strong Answer Covers - A single handler abstraction that the Logger depends on, with the concrete handlers as implementations - Clear semantics for passing the message along the chain, and the effect of handler order - TruncateHandler and StoreHandler with validated parameters and edge cases (short messages, empty messages, a limit of zero) - Encapsulation of the stored messages, and protection of the handler list from outside mutation - Extension points: new handlers, filtering or stopping the chain, log levels, error isolation and thread safety ### Follow-up Questions - Add a handler that drops messages containing a given word. How does your interface let it stop the chain? - Messages now carry a level and a timestamp. What changes in the handler interface? - Two threads log through the same `StoreHandler`. What can go wrong, and how do you fix it? - How would you unit test the Logger without printing anything?