Since I can remember, designing solutions to complex problems was my favorite software development-related activity. The conceptual shaping of elegant, fit-for-purpose thought constructs was always (in my case) much more pleasant than coding itself. As my work-products were (IMHO ;>) polished to the finest detail, turning them later into syntactic...
I tend to "spend" a lot of keystrokes on various aspects of technical debt and/or poor engineering practices. The list seems endless: component coupling, shallow modeling, leaky boundaries, inconsistent conventions, not-sufficiently-expressive design, incapacitated development agility, unnecessary layers of indirection, overzealous pattern usage, lava flow effect - naming...
> 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...
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...
A short post about unreasonable usage of State pattern [https://en.wikipedia.org/wiki/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)...
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...
