If you found value in this post, consider following me on X @davidpuplava for more valuable information about Game Dev, OrchardCore, C#/.NET and other topics.
Robert C. Martin introduced the SOLID principles as guidelines in object-oriented programming to increase software maintainability and testability.
Emphasizing software design quality, they are relevant to all programmers who create and maintain sufficiently complex software systems.
In C# console applications and object-oriented programming (OOP) generally, SOLID principles provide a foundation iterative code design.
They ensure that software systems are easy to manage, extend, and refactor as system complexity increases.
That said, console applications are a special case with ignoring SOLID principles may be appropriate. The main criteria is the purpose for the console application to exist.
For example, if you write a console application as a temporary piece of functionality to produce a one time result, SOLID is probably inappropriate. This usually because time to complete the coding is more important than anything else. Any extra time analyzing design decision tradeoffs delays you delivering that temporary code.
Consider the following requirement:
Archive files over 10MB that are older than 90 days
The solution here may not even need a C# console application because you can script it with PowerShell. But for our purposes, we'll consider a C# console application.
My approach would be to open Visual Studio, write a bunch of code in Main() and run it in debug to step through and make sure it's working as expected as I step through each file to archive.
BUT, even so, anything that's temporary can become permanent.
Consider a revision to this requirement
Periodically archive files over 10MB that are older than 90 days
Well that can be as simple as using Windows Task Scheduler to your console application periodically.
Now, however, you may want to add some validation logic to make sure that the file paths are valid, or that there's enough disk space, and other things like that. Because your console applicaiton will now be running without you watching and you don't want it to misbehave.
Even writing information to a log file so you can go back and review when it executed and what it did is likely an important feature for this new "temp" (now permanent) console app. And you can start using SOLID principles as your requirements evolve.
Do you log to a file or a database or some web service? You may not know, or may not want to decide. So abstracting the logging behind an interface may be a smart move.
In summary, you need to evanulate each line of code you write and ask yourself if and how your system may change. The longer your software system evolves the more value you gain from adhering to SOLID principles.
Using SOLID principles in C# enhances code readability, reduces complexity, and facilitates easier maintenance and scalability for developers familiar with those principles. They align closely with the core concepts of OOP, making them essential in C# development, namely the polymorphic tendency to invert control of some logic.
While beneficial, SOLID principles can lead to an increase in the number of classes and interfaces, potentially complicating the project structure. Overemphasis on these principles might result in over-engineering if they are introduced without justification such as evolving requirements.
The best explanation of SOLID principles lies in understanding them as a set of practices aimed at improving software design's efficiency, maintainability, and scalability, thereby addressing common problems in software development.
One common problem it solves is the high cost of changing a long standing system due to new/modern requirements. If you're a developer, you know the feeling of wanting to make a code change to a system but feeling like there is a dead elephant pressing down on your ability to make that change. The symptom here is that you want to make a small but significant change. And you need to check a hundred other spots in the code base before you're reasonably sure you can make that change without introducing a bug.
Designing with SOLID principle can benefit your future self by isolating modules of the system so you can refactoring nearly independently from the rest of the system.
Robert C. Martin, aka Uncle Bob, a prominent figure in software engineering, promoted SOLID principles, significantly impacting the software development industry.
He has authored several books in multiple series on the topic. Uncle Bob has also recorded several lectures he's given on SOLID that you can view online.
Every developer, regardless of language or framework, benefits from understanding SOLID principles, as they provide a universal framework for creating effective, maintainable, and scalable software systems.
In my opinion, Dependency Inversion Principle is the most heavily used principle and has had the greatest impace on the industry as a whole. Inverting a dependency causes you to design behind and interface that you can then code new implementations in the future.
Almost every platform I work with now includes some kind of depency container out of the box.
Use SOLID principles as a guide rather than a strict dogma. Consider where the future developer, most often which is you, can benefit from being able to change part of a software system with minimal impact on the rest of the system.
A lot of developers and programmers have strong and extreme opinions about SOLID. But it's a tool like anything. You should study them to know when to use them as much as when not to use them.
Good luck.
If you found value in this post, consider following me on X @davidpuplava for more valuable information about Game Dev, OrchardCore, C#/.NET and other topics.