The problem scope (perceived or real)

Software coding patterns and practices are hard to enforce and many features are under pressure to constantly change making early pattern choices a trap later in a project.

Real world code often gets written iteratively without a known end state and the best guidance is itself just another abstraction of concepts like SOLID or Clean Code etc.

Even well formed code when written by a large team can have natural differences like methods signatures, outputs, performance monitoring, and logging that require 'glue' code.

One attempt at a solution

Logic Ladder (github nuget) is an attempt to isolate code into arbitrary steps (IStep<T>) with one visible/public method per class that takes in a shared TContext and returns the potentially modified version of that same TContext. It also offers some boiler plate structure for outputs and error handling that can add readability and consistency to a code base. In pursuing a 'one size fits all' approach such as this or picking any specific pattern you of course face trade offs and could argue about where certain SOLID principles aren't enforced in exchange for what achieved goals. As always choose wisely my friends :)

Usage Tips

The TContext has no generic restraints but is meant to contain NO BEHAVIOR/METHODS. Just consider it a strongly typed in memory database. Put your inputs and outputs on that object and it will be available to the steps. It's a great place to find usages in a code editor to see what is shared and to safely refactor.

Examples:

One of the least talked about benefits of unit tests is to demonstrate code.

The Ladder class is doing most of the heavy lifting.

A real world example used for a sprinkler agent