Avoiding Code Anti-Patterns with SOLID

The right design principles can keep your code from quickly going stale. While there are many right ways of writing code, there are anti-patterns and code smells that constitute the wrong way of writing code.

Additionally, the community has identified several principles to keep in mind when building software that can help your code resist accumulating technical debt for as long as possible. In this chapter, we’ll cover a number of these principles, including the famous SOLID acronym, and see how they can help you build software that actively resists the gradual decline toward legacy code.

In this chapter, we’ll cover the following topics:

• Identifying anti-patterns in C# code
• Writing SOLID code
• Considering other architectural principles

Identifying anti-patterns in C# code

I’ve often found myself telling new programmers that to build good software, you have to first build a lot of really bad software and learn from it.

While this statement is somewhat in jest, there is some truth to it: almost every developer can recognize code that’s written the wrong way and discover things that make it difficult to work with, and doing so helps you write better code the next time.

When your code is bad, there’s usually a part of you that knows it. You see little things that you don’t love: duplicated pieces of code, inconsistencies in naming or parameter ordering, passing too many parameters around, methods, or even classes that are just too big to manage effectively.

These symptoms are what we commonly refer to as code smells, and we’ll revisit them later in this section.

Beyond code smells are something called anti-patterns, which is code that significantly deviates from community...

Writing SOLID code

SOLID is an acronym introduced by Michael Feathers summarizing the words of Robert C. Martin. The intent of SOLID is to provide developers with a set of principles that will guide them toward more maintainable code that resists becoming technical debt.

The five principles of SOLID code are:

• Single Responsibility Principle (SRP)
• Open-Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

In this section, we’ll cover all five of these principles.

Single Responsibility Principle

The Single Responsibility Principle (SRP) says that a class should be responsible for one thing and one thing only. Here are a few examples of classes that follow the SRP:

• A class responsible for saving application data to a specific file format
• A database access class dedicated to executing queries against a database table or set of tables
• An API controller...

Considering other architectural principles

Before we close out the chapter, let me share three brief principles that have helped me in my own journey toward good software.

Learning the DRY principle

Don’t Repeat Yourself (DRY) is an important tenant in software development. The DRY principle is oriented around making sure you don’t repeat the same patterns in code throughout your application. Code takes a while to write, read, and maintain, and bugs inevitably do occur at a certain rate per line of code. As a result, you want to strive to solve problems once in a centralized place and then reuse that solution.

Let’s look at some sample code that violates the DRY principle. This code takes in a comma-separated value (CSV) string such as "CSA1234,CMH,ORD" and translates it into a FlightInfo object:

public FlightInfo ReadFlightFromCsv(string csvLine) {
  string[] parts = csvLine.Split(',');
  const string fallback...

Summary

In this chapter, we discussed code smells and anti-patterns. The right design principles can help keep your code focused and minimal and slow the rate at which it naturally accumulates complexity. This helps keep your code in good form and resist accumulating technical debt.

The most common maxim for quality programming is SOLID, following the Single Responsibility Principle (SRP), making code open for extension while being closed to modification, the Liskov Substitution Principle (LSP) advocating for low coupling with polymorphic code, the interface segregation principle focused on several smaller interfaces over one larger interface, and the Dependency Inversion Principle (DIP) which talks about reducing coupling by having classes take in the things they need from outside of the class.

Now that we’ve established how to write SOLID code, we’ll explore some advanced testing techniques that can help test code built using these principles.

Questions

1. How does the SRP affect cohesion?
2. Which areas of your code violate the SRP or DRY?
3. What are the advantages of DI? How does it affect coupling?

Further reading

You can find more information about materials discussed in this chapter at these URLs:

• SOLID Principles in C# with Examples: https://www.c-sharpcorner.com/UploadFile/damubetha/solid-principles-in-C-Sharp/
• 15 of the Worst C# Anti-Patterns Developers Keep Using (And How to Avoid Them): https://methodpoet.com/worst-anti-patterns/
• Top 10 Dotnet Exception Anti-Patterns in C#: https://newdevsguide.com/2022/11/06/exception-anti-patterns-in-csharp/
• Using objects that implement IDisposable: https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/using-objects
• LINQ: Caveats and pitfalls: https://dev.to/samfieldscc/linq-37k3