BrandGhost
Should My Method Do This? Should My Class?

Should My Method Do This? Should My Class?

04/08/2015(Updated 07/13/2026)

Whose Job Is It?

I wanted to share my experience that I had working on a recent project. If you've been programming for a while, you've definitely heard of the single responsibility principle. If you're new to programming, maybe this is news. The principle states:

That every class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class
You could extend this concept to apply to not only classes, but methods as well. Should you have that one method that is entirely responsible for creating a database connection, connecting to a web service, downloading data, updating the database, uploading some data, and then doing some user interface rendering? What would you even call that?!

The idea is really this: break down your code into separate pieces of functionality.

Easier Said Than Done... Or Is It?

The idea seems easy, right? Then why is it that people keep writing code that doesn't follow this guideline? I'm guessing it's because even though it's an easy rule, it's even easier to just... code what works.

The recent experience I wanted to share was my work on a project that has a pretty short time frame to prove it was feasible. It was starting something from scratch, so I had all the flexibility in the world to design code however I wanted to. I really made an effort to keep asking myself this one question: Whose job is it?

Every time I asked that question and found that it was not my current method's responsibility, I would ask "Is this class really responsible for that"? I'd either go make myself a new method in my class or I'd just go immediately make a new class with a single method on it. It seemed like a bit of extra overhead each time I had to do it, but was it worth it in the end?

Absolutely. After the project had proven itself and development continued on, I was easily able to refactor code (where necessary) and mock out functionality in my coded tests. Instead of trying to write test setup code that required a whack of classes I needed to initialize, I could mock out a couple of interfaces and test with ease. It was also really obvious which pieces were responsible for what functionality.

Final Thoughts

If you want to get better at following the single responsibility principle, I think it starts with one question: Whose job is it? Try it out!

Weekly Recap: SOLID Principles, C# Design Patterns, and ASP.NET Core Web APIs [Jun 2026]

This week is a full walkthrough of the SOLID principles in C# -- single responsibility, open/closed, Liskov substitution, and interface segregation -- plus design pattern guides for the mediator, iterator, and memento patterns. There's also practical ASP.NET Core Web API coverage on deploying to Azure and Docker and writing integration tests, with new videos on engineering management, plugin architecture, and tech debt.

Template Method Pattern Best Practices in C#: Code Organization and Maintainability

Explore template method pattern best practices in C# including sealed methods, hook design, testing strategies, and maintainable inheritance hierarchies.

Single Responsibility Principle C#: One Class, One Reason to Change

Learn the single responsibility principle c# with real before/after examples. Understand SRP, cohesion, coupling, and .NET 10 best practices.

An error has occurred. This application may no longer respond until reloaded. Reload