Concepts on Artur Rios Lab

What Is the Dependency Inversion Principle? Policy, Detail and Who Owns the Interface

Wed, 21 Oct 2026 00:05:00 +0000

A checkout that takes a payment has to call the payment provider: there is no way around that at run time. It does not follow that the checkout’s source code has to name the provider, import its SDK, or change when the provider changes its API. The dependency inversion principle is the rule that separates those two things. It asks which way the arrows between modules should point, and its answer is that the code holding the important decisions should not depend on the code holding the details; the details should depend on it. This is part five of a series on SOLID, after the single responsibility, open-closed, Liskov substitution and interface segregation principles, and it leads into inversion of control, the mechanism most programs use to put the principle into practice. This article explains what the principle says, where it came from, why the flow of control and the direction of a dependency can point opposite ways, why the abstraction has to belong to the code that uses it, and what is not worth inverting. Every output shown here was produced by running the code on Windows 11, with Python 3.14.6, not written by hand.

What Is the Interface Segregation Principle? Fat Interfaces, Role Interfaces and the Clients That Shape Them

Wed, 21 Oct 2026 00:04:00 +0000

An invoice printer needs to read one order. In many codebases it is handed an object that can also save orders, cancel them, total the month’s revenue and export everything to a spreadsheet, because that is the interface the order store happens to have. The printer never calls those methods, but it depends on them all the same: when one of them changes, the printer is rebuilt, retested and redeployed, and anyone writing a stand-in for it in a test has to implement all five. The interface segregation principle is the rule against that arrangement, and the fourth of the five SOLID principles this series covers. This article explains what it says, where it came from, what a fat interface costs, how to split one into interfaces shaped by their clients, and where splitting stops paying. Every output shown here was produced by running the code on Windows 11, with Python 3.14.6 and with the .NET 10 SDK, not written by hand.

What Is the Liskov Substitution Principle? Subtypes, Contracts and the Promises a Base Class Makes

Wed, 21 Oct 2026 00:03:00 +0000

A function that sorts a list of shapes by area has never heard of the square. It was written against a base type, and it will be handed whatever subclasses exist now and whatever subclasses someone writes next year. Whether it keeps working depends on a promise nobody wrote down: that every one of those classes behaves the way the base type said it would. The Liskov substitution principle is that promise, made explicit. It is the third of the five SOLID principles, and this is part 3 of a series on SOLID. This article explains what the principle says, where it came from, the rules a subtype has to keep, the violations that ship inside widely used platforms, and how to repair one. Every output shown here was produced by running the code on Windows 11, with Python 3.14.6, mypy 2.4.0 and the .NET 10 SDK, not written by hand.

What Is the Open-Closed Principle? Extension, Abstraction, Plug-ins and the Expression Problem

Wed, 21 Oct 2026 00:02:00 +0000

A shop adds a new way to ship parcels. In one codebase that means opening the function that prices shipping, adding a branch to the middle of it, and re-testing everything that calls it. In another it means writing one new class in one new file, and nothing that already works is touched. The difference between the two is what the open-closed principle is about: arranging code so that new behaviour arrives as new code, rather than as edits to code that is released, tested and depended on. It is the second of the five SOLID principles, and this is part 2 of a series on them, after the single responsibility principle. This article explains what the principle means, where it came from, what it looks like in running code, why no module can be closed against every change, how the expression problem sets its limits, and when the abstraction it calls for is worth paying for. Every output shown here was produced by running the code on Windows 11, with Python 3.14.6, not written by hand.

What Is the Single Responsibility Principle? Reasons to Change, Actors and Cohesion

Wed, 21 Oct 2026 00:01:00 +0000

An online shop has an Order class. Finance uses it to book revenue, the storefront uses it to print receipts, and the platform team uses it to store orders in the database. One day the storefront asks for receipts to show prices with VAT, a developer makes the change in the obvious place, every test the storefront cares about passes, and at the end of the month finance’s revenue is twenty per cent too high. Nobody touched finance’s code. They touched code that finance shared. The single responsibility principle is the rule that would have kept those two apart, and it is the most quoted and least understood of the five SOLID principles. This is the first part of a series on SOLID: it explains what the principle says, where it came from, how the acronym itself was born, what it looks like in running code, and how far to take it. Every output shown here was produced by running the code on Windows 11, with Python 3.14.6, not written by hand.

What Is Inversion of Control? Frameworks, Callbacks, Dependency Injection and Containers

Tue, 20 Oct 2026 23:00:00 +0000

A web framework calls a function when a request arrives. A test runner finds the tests in a file and runs each one. A browser calls a handler when a button is clicked, and an application server hands a class the database connection it asked for in its constructor. In each case the code a programmer wrote does not decide when it runs or where its collaborators come from: something else does. That reversal has a name, inversion of control, and it is one of the ideas most of modern software is quietly built on. This article explains what it means, where the term came from, the forms it takes, how dependency injection and IoC containers work inside, and when the indirection is worth paying for. It closes a series on SOLID: where the dependency inversion principle says which way dependencies should point, this is the mechanism that makes them point that way at run time. Every output shown here was produced by running the code on Windows 11, with Python 3.14.6 and with the .NET 10 SDK and Microsoft.Extensions.DependencyInjection 10.0.13, not written by hand.