{"id":1403,"date":"2024-09-03T00:00:00","date_gmt":"2024-09-02T22:00:00","guid":{"rendered":"https:\/\/demo.sidekick.be\/itenium\/kiss-decorators\/"},"modified":"2025-11-28T13:31:42","modified_gmt":"2025-11-28T12:31:42","slug":"kiss-decorators","status":"publish","type":"post","link":"https:\/\/demo.sidekick.be\/itenium\/blog\/design\/kiss-decorators\/","title":{"rendered":"KISS and Decorators"},"content":{"rendered":"

The Implementation<\/h1>\n

A simplified version of the code would be:<\/p>\n

public interface IDoer\n{\n  void DoIt();\n}\n\n\npublic class Doer : IDoer\n{\n  public void DoIt()\n  {\n    \/\/ Actual Business Logic here\n    \/\/ But... Only happening for\n    \/\/ one case?\n  }\n}\n<\/code><\/pre>\n
And then another implementation, a decorator:<\/p>\n
public class LoopingDoer : IDoer\n{\n  private readonly IDoer _inner;\n\n  public LoopingDoer(IDoer inner)\n  {\n    _inner = inner;\n  }\n\n  public void DoIt()\n  {\n    \/\/ We were looping over something\n    \/\/ that made sense here, not just\n    \/\/ this for loop:\n    for (int i = 0; i < 10; i++)\n    {\n      _inner.DoIt();\n    }\n  }\n}\n<\/code><\/pre>\n
The Magic<\/h2>\n
To make it all work, the \u201cmagic\u201d \u2728\ud83e\udd84 Autofac<\/a> wiring:<\/p>\n
var containerBuilder = new ContainerBuilder();\ncontainerBuilder.RegisterType<Doer>().As<IDoer>();\ncontainerBuilder.RegisterDecorator<LoopingDoer, IDoer>();\n<\/code><\/pre>\n
Probably there is no one in your team who knows what this does exactly and they\u2019d have to look at a completely different location (app startup) before it makes any sense.<\/p>\n
Keep it Simple<\/h1>\n
After removing the decorator and the Autofac registration, we ended up with:<\/p>\n
public class Doer : IDoer\n{\n  public void DoIt()\n  {\n    for (int i = 0; i < 10; i++)\n    {\n      \/\/ Business Logic here\n\n      \/\/ New UseCase example\n      if (i == 0)\n      {\n        \/\/ UserStory implementation here\n      }\n    }\n  }\n}\n<\/code><\/pre>\n
Which is less code and much easier to understand, and it also made it easy, trivial even, to add the required change.<\/p>\n
Decorator Pattern<\/h1>\n
An excellent design pattern to adhere to the Open\/Closed Principle: Add functionality without modification.<\/p>\n
Intent<\/h2>\n
It\u2019s one of the Structural Patterns from the GoF<\/a>.<\/p>\n
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.<\/p>\n
Applicability<\/h2>\n
When extension by subclassing is impractical because a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination.<\/p>\n
Consequences<\/h2>\n
More flexible than static inheritance<\/em>:
 Responsibilities can be added and removed at run-time whereas inheritance requires creating a new class for each new combination.<\/p>\n
Avoids feature-laden classes<\/em>:
 Instead of trying to support all features in a complex, customizable class, you define a simple class and add functionality incrementally with Decorator objects.<\/p>\n
Lots of little objects<\/em>:
 The objects differ only in the way they are interconnected. Although easy to customize, you can no longer follow the execution flow from the source code alone and they can be hard to debug<\/strong>.<\/p>\n
Known Uses<\/h2>\n
I\/O Streams are typically implemented using Decorators and they are a really good fit for the pattern too!<\/p>\n
byte[] buffer = \"test\"u8.ToArray();\n\nusing (FileStream fileStream = new(path, FileMode.Create, FileAccess.Write))\nusing (BufferedStream bufferedStream = new(fileStream))\nusing (GZipStream gzipStream = new(bufferedStream, CompressionMode.Compress))\n{\n  gzipStream.Write(buffer, 0, buffer.Length);\n}\n<\/code><\/pre>\n
We cleanly avoid having to create a GZipBufferedFileStream<\/code> for this particular case. Having to write all these implementations would result in said explosion of subclasses and also make it difficult to keep things DRY!<\/p>\n
Conclusion<\/h1>\n
Using the decorator pattern instead of writing a simple foreach<\/code> loop; it\u2019s just adding accidental complexity<\/a>.<\/p>\n
You end up with the consequences of the design pattern (hard to learn and debug) without any of the benefits.<\/p>\n
Keep It Simple.<\/p>\n
Extras<\/h1>\n
Stuff that came into being during the making of this post<\/b><\/p>\n