<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Design Patterns on Artur Rios Lab</title><link>https://lab.artur-rios.tech/tags/design-patterns/</link><description>Recent content in Design Patterns on Artur Rios Lab</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 21 Oct 2026 00:02:00 +0000</lastBuildDate><atom:link href="https://lab.artur-rios.tech/tags/design-patterns/index.xml" rel="self" type="application/rss+xml"/><item><title>What Is the Open-Closed Principle? Extension, Abstraction, Plug-ins and the Expression Problem</title><link>https://lab.artur-rios.tech/concepts/open-closed-principle/</link><pubDate>Wed, 21 Oct 2026 00:02:00 +0000</pubDate><guid>https://lab.artur-rios.tech/concepts/open-closed-principle/</guid><description>&lt;p&gt;A shop adds a new way to ship parcels. In one codebase that means opening the&#10;function that prices shipping, adding a branch to the middle of it, and&#10;re-testing everything that calls it. In another it means writing one new class&#10;in one new file, and nothing that already works is touched. The difference&#10;between the two is what the &lt;strong&gt;open-closed principle&lt;/strong&gt; is about: arranging code&#10;so that new behaviour arrives as new code, rather than as edits to code that is&#10;released, tested and depended on. It is the second of the five SOLID principles,&#10;and this is part 2 of a series on them, after&#10;&lt;a href="../single-responsibility-principle/"&gt;the single responsibility principle&lt;/a&gt;.&#10;This article explains what the principle means, where it came from, what it&#10;looks like in running code, why no module can be closed against every change,&#10;how the expression problem sets its limits, and when the abstraction it calls&#10;for is worth paying for. Every output shown here was produced by running the&#10;code on Windows 11, with Python 3.14.6, not written by hand.&lt;/p&gt;</description></item><item><title>What Is Inversion of Control? Frameworks, Callbacks, Dependency Injection and Containers</title><link>https://lab.artur-rios.tech/concepts/inversion-of-control/</link><pubDate>Tue, 20 Oct 2026 23:00:00 +0000</pubDate><guid>https://lab.artur-rios.tech/concepts/inversion-of-control/</guid><description>&lt;p&gt;A web framework calls a function when a request arrives. A test runner finds&#10;the tests in a file and runs each one. A browser calls a handler when a button&#10;is clicked, and an application server hands a class the database connection it&#10;asked for in its constructor. In each case the code a programmer wrote does not&#10;decide when it runs or where its collaborators come from: something else does.&#10;That reversal has a name, &lt;strong&gt;inversion of control&lt;/strong&gt;, and it is one of the ideas&#10;most of modern software is quietly built on. This article explains what it&#10;means, where the term came from, the forms it takes, how dependency injection&#10;and IoC containers work inside, and when the indirection is worth paying for.&#10;It closes a series on &lt;a href="../../series/solid/"&gt;SOLID&lt;/a&gt;: where the&#10;&lt;a href="../dependency-inversion-principle/"&gt;dependency inversion principle&lt;/a&gt; says which&#10;way dependencies should point, this is the mechanism that makes them point&#10;that way at run time. Every output shown here was produced by running the code on Windows 11, with&#10;Python 3.14.6 and with the .NET 10 SDK and Microsoft.Extensions.DependencyInjection&#10;10.0.13, not written by hand.&lt;/p&gt;</description></item></channel></rss>