TL;DR Many of the most commonly used patterns & "conceptual industry standards" in software development have their roots in Object-Oriented design. However, it's time to realize that OO is not the only viable way this day, so in some cases yesterday's anti-patterns may be a preferred way to go today. Anemic Domain Model is a perfect example here - not only I wouldn't discourage using it anymore, in fact I find it well aligned with all the goodness "re-discovered" recently thanks to FP. Life can be very ironic: occasionally yesterday's patterns appear to be today's…
All posts in design patterns
We 'like' to put blame on factors that (in our opinion) lie beyond our control - stone-carved deadlines, outdated legacy, unimaginative Product Owners who always dump tech debt-related work items into abyss of Nice-To-Have. Some call it 'victimship' & it's all about giving up at the slightest indication on resistance due to bias we've developed in our past (by ourselves or just learned from others). We learn to live with issues & impediments instead of getting rid of them ("that's the way it works here ..."). What I find truly ironic is the fact that many of these problems…
A short post about unreasonable usage of State pattern - something I keep seeing every so often in code (regardless of language / platform). What's a State pattern? State pattern is a way to encapsulate state (& behaviour that depends upon it) within an object the state belongs to. It's a natural way to express physical reality (and its variability over time) in a conceptual Object-Oriented way. If you follow state pattern: 1 physical world object is usually represented by 1 entity (DDD-wise) (+ tree of dependencies, etc.) with a life-cycle that corresponds to the life-cycle of physical object; for instance: Car…
I have a weak spot for the policy design pattern since ol' good C++ times: I think it has all started when I've read one of Sutter's / Alexandrescu's books with some great examples of policies injected via template parameters. This way you could get a variable behavior without complex inheritance and excessive coupling. Today, the times of templates are long gone (trust me: C# generics are 5% of what was possible with C++ templates ...), but it doesn't mean you can't use strategy / policy design patterns anymore. Back to business: The star of the day is named "Polly". Polly…