When you first start riding a bike, most new bike riders (usually young kids) use training wheels. After a few months or years, those training wheels aren’t needed.

Similarly, when a developer writes code, he/she probably also needs training wheels. The difference is, that with code, you will almost always need these training wheels.

Note: After 20+ years of coding, despite a Master of Computer Science, despite being a Lead developer for over a decade, I still use these.

S.O.L.I.D. Training Wheels

S = Single Responsibility Principal

• Summary: 1 piece of code has 1 responsibility. The inverse: 1 responsibility of code has 1 piece of code
• Training Wheels:
  1. Follow the 10/100 Principle
     • Do not write methods over 10 lines
     • Do not write classes over 100 lines
     • If you have to change a class that already breaks the 10/100 Principle:
       • take your code out of that class and put it in a new class first so the original class is smaller
       • Check-in this refactor without your new code
       • make your changes in the new class
       • Check-in your new code
  2. Think smaller.
     1. The smaller the responsibility, the better. Keep breaking down the responsibility until it so small you can’t split it
     2. The smaller the coding block, the more likely you will spot repetition
  3. Models already have a responsibility of being a model, and therefore should never have logic as that would be a second responsibility.
  4. Only one object per file (class, interface, struct, enum, delegate, etc.)

Note: The above are also the Don’t Repeat Yourself (D.I.Y.) training wheels

2. O = Open/Closed Principal

• Summary: If your code is marked as public, and you already have consumers the code (outside your solution), don’t break the code because it will break all the consumers code
• Training Wheels:
  • Default to private or internal. Don’t make anything public unless you are sure it needs to be public.
    • Give your unit test projects access to internals. For example, in C#, us [assembly: InternalsVisibleTo(“YourProject.Tests”)]
  • For existing code, don’t change the code signatures (the way the class, or method is defined) of anything public
  • Yes, you can add new methods and properties

3. Liskov’s Substitution Principal

• Summary: Any class that implements an interface or a base class, will work just as well as another class that implement the same interface or base class. Classes that inherit from such, also should work just as well.
• Training Wheels:
  • Implement interfaces / avoid base class inheritance
  • Choose “Has a” over “Is a”

4. Interface Segregation Principal

• Summary: Keep your interfaces small and single responsibility.
• Training Wheels:
  • See the S in Solid and the 10/100 Principle.
  • A class with a max 100 lines should result in small interfaces. Might they need to be smaller, sure, but these are just training wheels.
• It is better to have a class implement more than one interface than to have a large interface. You can also have interfaces inherit other interfaces.

5. Dependency Inversion Principal

• Summary: A class doesn’t control it’s dependencies. A class depends only a interfaces, simple models
• Training Wheels:
  • Use a Dependency Injection Container. For example, in C#, there DI container such as Autofac, Ninject, or the new one built into .Net.
  • All dependencies are injected as interfaces using constructor injection
    • i.e. Never use the ‘new’ keyword in a class that isn’t your one composition root or a DI module.
  • All interface/concrete pairs are registered with the DI Container
  • Almost never write a static. Statics are only for extremely simple utility methods, for example, in C#, very simple extension methods, such as string.Contains().
  • If you encounter a static in existing code
    • If it isn’t public, refactor it immediately to be non-static. If it is public, you can’t delete it, see the O in solid, so wrap it

6. Other Training Wheels

1. Write Unit tests
   1. Unit Test are your first chance to prove your code is S.O.L.I.D.
      1. If you follow the above training wheels especially the S and D in solid, your code will be much easier to unit test.
   2. If you don’t write Unit Tests first (see TDD), at least write them simultaneously or immediately after each small piece of code.
   3. Use a mocking framework. For example, in C# use Moq.

Why use S.O.L.I.D. training wheels while coding?

Remember, these are training wheels. Just like training wheels on a bike helps you not crash, these S.O.L.I.D. training wheels will help you not crash your code (i.e. write unmaintainable code).

If you follow these training wheels, you will be amazed how:

1. Your code is far easier to maintain.
2. Your code is far easier to keep up-to-date.
3. Your code naturally uses common design patterns even if you, the writer, haven’t learned about that design pattern yet.
4. You code is testable.
5. Other developers praise your code.