Refactoring Messy to Testable Code in .NET (Part 4 - Factory)

In this series, we'll work through refactoring a messy .NET Core MVC web application with a lot of procedural code and no tests. When we're done, we'll have a more testable, object-oriented, extensible application, complete with unit tests and static code analysis wired up with a continuous integration loop with GitHub Actions. We'll cover topics like inversion of control via dependency injection, replacing conditionals with polymorphism, factory methods, sending messages between small objects, unit testing, naming, and much more!
What is Legacy Code?
“Code without tests is bad code. It doesn’t matter how well-written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.”
― Michael Feathers, Working Effectively with Legacy Code
Legacy code - code without tests - is everywhere. It is not unusual in practice to encounter entire applications with few or even no tests. It is perhaps just as common to find software with legacy tests that don't adequately test current software behavior.
As a professional software developer, you will inevitably work on code that is difficult to change and difficult to test. This will be because the original authors of the code (maybe even yourself) didn't understand how to write code that easy to change, didn't understand the importance of unit and integration testing, or perhaps didn't "have time" to write tests for code when it was originally written.
In this course, you'll clone a messy codebase and work step-by-step with me to get it back into shape - complete with tests, continuous integration, and static code analysis! We'll use concepts from object-oriented and functional programming to write cleaner, more testable, more modular code that is easy to change. This is much more than just "DRY" -we'll focus on concepts like:
Extensibility - we'll make it easier to implement new features
Loose coupling - we'll look at how "new is glue," "static cling," and side-effects lead to tightly-coupled software
Minimizing side effects - find out how writing more functional code can prevent unexpected behavior and decrease the chance you'll introduce bugs
Decreasing complexity - often the easiest code to write increases overall complexity - we'll look at how improving your ability to apply slightly advanced techniques can actually decrease the complexity of your application and make it much easier to reason about at different levels of abstraction
Improving naming - notoriously one of the most difficult tasks in software development - what do we call this thing?
Making smaller things - making smaller objects that inter-operate by sending and receiving messages make your codebase easier to maintain, organize, and reason about.

[@RonnyHanssen]

Why did you choose to make the OrderProcessor an abstract base class, as opposed to making it an interface?

[@WesDoyle]

Hi Ronny, I think you're right on - I could have used an interface here instead of an abstract base class, especially since the base class doesn't implement any shared behavior or virtual methods to override. I was thinking along the lines that the OrderProcessor base class might generally provide some common behavior for its subclasses - but, in this small example, it only has the one abstract member. So - good call - I could use an interface here just as well! Thanks for the message.

[@anowereng]

awesome !

[@sunnypatel1045]

Hi Wes. With your multiple if statement within the OrderProcessor. I know you put it in a factory that seems ok. There 2 ways to handle that if statement 1) have it in a switch statement
2) implement a strategy patten (Open/Close principle). I like what you doing keep it up. Im dealing with a big codebase now and with your tips it helped. Thank you for this !