Vox

Leitura de 13 min

Single Responsibility Principle: A Class Should Have One, and Only One Reason to Change

Summary

In this episode, Jonathan Cottrell explores the concept of focus in software development, arguing that it’s not just a mental practice but a crucial principle for writing understandable code. He begins by drawing an analogy between human multitasking inefficiency and the need for focused code, emphasizing that code is written for humans, not computers. Computers handle context switching with minimal overhead, but humans struggle, so our code should reflect how our brains work best—by concentrating on one thing at a time.

Cottrell introduces the Single Responsibility Principle (SRP), a core tenet of the SOLID principles coined by Robert C. Martin (Uncle Bob). The formal definition states that a class should have only one reason to change, but Cottrell extends this idea to any named block of code—methods, functions, or variables. He explains that each named entity should do exactly what its name implies, avoiding multiple responsibilities that confuse future readers, including yourself.

To identify violations of SRP, Cottrell offers practical heuristics. If you find yourself adding comments to separate sections within a method (like setting up credentials, establishing a connection, and handling errors), it’s a sign the method has multiple responsibilities and should be broken into smaller, focused methods. He also references Sandy Metz’s rule of thumb to keep classes around 100 lines long, which helps scope responsibilities appropriately.

Ultimately, Cottrell stresses that applying the Single Responsibility Principle leads to more maintainable and comprehensible code. By breaking down code into smaller, single-purpose chunks, developers reduce cognitive load and make it easier for others (and their future selves) to understand and modify the codebase. This focus aligns with human cognitive limits and fosters better software design.

Recommendations

People

  • Robert C. Martin (Uncle Bob) — Credited with formally writing down the Single Responsibility Principle in the early 2000s and co-authoring the Agile Manifesto and SOLID principles.
  • Sandy Metz — Referenced for her practical advice to keep classes about 100 lines long as a heuristic to maintain single responsibility and manageable scope.

Tools

  • DigitalOcean — Sponsor of the episode; described as simple cloud hosting built for developers, offering SSD cloud servers deployable in 55 seconds with plans starting at $5/month.

Topic Timeline

  • 00:00:00 — Introduction to focus in code and human multitasking — Jonathan Cottrell introduces the episode’s theme of focus in software development. He explains that focus is crucial not just mentally but also in code, as humans are poor at multitasking and context switching. He uses the analogy of writing your name letter by letter alternating between first and last name to illustrate the overhead of switching tasks, contrasting it with computers’ efficiency.
  • 00:02:34 — Code is written for humans, not computers — Cottrell emphasizes that best practices in programming exist primarily for human understanding, not computer performance. Computers don’t care about coding styles, paradigms, or naming conventions; these abstractions are designed to help developers communicate intentions and transfer knowledge. This sets the stage for why focused code matters for maintainability and collaboration.
  • 00:04:53 — Recap and introduction to Single Responsibility Principle — After a sponsor break, Cottrell reiterates the importance of focused code for human cognition and maintainability. He introduces the Single Responsibility Principle (SRP) as a formalized concept from Robert C. Martin (Uncle Bob), part of the SOLID principles. SRP dictates that a class should have only one reason to change, but Cottrell extends it to any code block like methods or functions.
  • 00:07:11 — Practical heuristics for applying SRP — Cottrell provides rule-of-thumb techniques to identify and fix SRP violations. He suggests that if you need to comment sections within a method (e.g., for database setup, connection, error handling), it indicates multiple responsibilities that should be split into separate methods. He also mentions Sandy Metz’s guideline of keeping classes around 100 lines to limit scope and improve focus.
  • 00:08:29 — Judgment and benefits of focused code — Cottrell acknowledges that applying SRP involves personal judgment—can you understand everything a code unit does? If any part seems out of place or requires explanatory comments, it likely violates SRP. Breaking code into smaller, single-responsibility chunks reduces cognitive load and makes it more understandable, aligning with how human brains work to achieve focus in codebases.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2015-08-03T07:00:00Z
  • Duration: 00:09:52

References

Podcast Info

Transcript

[00:00:00] Hey, everyone, and welcome to Developer Tea.

[00:00:06] My name is Jonathan Cottrell, and today I’m going to be talking about focus in your code.

[00:00:13] Of course, you know, I talk about the concept of focus quite often on this show.

[00:00:18] In fact, one of the very first episodes of Developer Tea was on focus because it is so

[00:00:24] important that we develop focus so that we can actually work on something that takes

[00:00:30] a significant amount of mental energy.

[00:00:33] In that episode, I went on to discuss why focus is more important for a software developer

[00:00:39] than it would be for most other jobs that don’t require you to keep a lot of stuff in

[00:00:45] working memory.

[00:00:46] But focus isn’t just something that you practice in your own mind.

[00:00:50] The concept of focus is actually applicable to the things that you are

[00:00:54] producing.

[00:00:55] Specifically, developing a sense of focus in your code base is important for it to be

[00:01:00] able to be understood by you or other people in the future.

[00:01:04] So in this episode, I want to talk about what it means to have focused code.

[00:01:08] How do you write code that is easily understood and works the way that your brain already

[00:01:12] works?

[00:01:13] So let’s revisit the idea of distraction to talk about why focus is important.

[00:01:19] If you were, for example, to write your name on a piece of paper,

[00:01:24] first and your last name, that’s relatively easy for you to do.

[00:01:28] If you write your first name and then your last name.

[00:01:30] Now, if you were to try to write one letter each from your first name and then your last name,

[00:01:35] for example, for me, I would write J for Jonathan, then I would write C for Cottrell,

[00:01:40] and then I would write the O and then the U.

[00:01:43] If I were to do this, it’s going to take me much more time because I am having to switch

[00:01:48] contexts.

[00:01:49] My brain is not very good at switching contexts, and this is a simple proof of that.

[00:01:54] Now, there’s a lot of reasons why that particular example works so well.

[00:01:59] Some of them have to do with what we call muscle memory, but the underlying truth remains the

[00:02:04] same.

[00:02:04] It’s been studied over and over.

[00:02:06] We just aren’t very good at multitasking.

[00:02:09] Now, a computer can be quite decent at multitasking, and specifically when we talk about

[00:02:15] multitasking, we’re more talking about switching between tasks.

[00:02:19] Unlike a human, a computer doesn’t really have much overhead switching between tasks.

[00:02:23] It can do.

[00:02:24] It can do one thing and then jump to another, and it’s basically the same performance as

[00:02:28] if it were to continue doing the first thing.

[00:02:31] But we have to remember that we write code for humans.

[00:02:34] We do not write code for computers.

[00:02:37] Most of the best practices in computer science are created for humans to be able to connect

[00:02:43] the dots between each other’s code, not a computer to connect the dots.

[00:02:48] A computer doesn’t have a preference of what style of code you write.

[00:02:52] A computer doesn’t have a preference of how you write.

[00:02:54] A computer doesn’t have a preference of how you name your variables or your methods.

[00:02:57] A computer doesn’t care if you use a functional paradigm or an object-oriented paradigm.

[00:03:02] With some minor performance considerations, all of these abstractions have been created

[00:03:07] for humans.

[00:03:08] All of these abstractions are intended to give us an interface to be able to code our

[00:03:14] intentions into the computer and to be able to transfer that code between myself and another

[00:03:20] person or myself and future me.

[00:03:23] I’m going to take a quick spot.

[00:03:24] I’m going to take a sponsor break, and then I’m going to come back and talk about how

[00:03:27] to use the single responsibility principle to match the way your brain works to make

[00:03:33] code more understandable and to make it more focused.

[00:03:40] Today’s episode of Developer Tea is sponsored by DigitalOcean.

[00:03:44] DigitalOcean is simple cloud hosting built for developers.

[00:03:47] They’re dedicated to offering the most intuitive and easy way to spin up a cloud server.

[00:03:51] And in just 55 seconds, you can deploy a…

[00:03:54] …solid state drive cloud server.

[00:03:56] Plans start at only $5 per month for 512 megabytes of RAM, a 20 gigabyte solid state drive,

[00:04:03] one CPU, and a full terabyte of transfer.

[00:04:06] In addition to offering simple and affordable SSD cloud hosting, DigitalOcean is dedicated

[00:04:11] to building out a strong community and supports open source software.

[00:04:15] They offer a vast collection of hosting tutorials and invite developers to submit articles,

[00:04:20] and they pay $50 per published piece.

[00:04:23] Deploy.

[00:04:24] Your SSD cloud server with DigitalOcean today by going to DigitalOcean.com.

[00:04:29] Now, DigitalOcean has been kind enough to provide Developer Tea listeners a discount

[00:04:33] of $10 when you use the code DEVELOPERTEA.

[00:04:37] So go to DigitalOcean.com and use the code DEVELOPERTEA to get $10 off today, and you’ll

[00:04:42] get up and running with your own SSD cloud server in just 55 seconds.

[00:04:47] That’s DigitalOcean.com.

[00:04:53] We’ve been talking…

[00:04:54] We’ve been talking once again about focus on today’s episode, specifically about focusing

[00:04:59] your code and why it’s so important for you to focus your code.

[00:05:03] Of course, computers don’t have to worry about the overhead that it takes to switch between

[00:05:08] tasks, but as humans, we do have to worry about that overhead.

[00:05:11] We need to be able to think and focus on one thing at a time.

[00:05:16] On top of that, code is written for other humans.

[00:05:19] We talked about this in previous episodes, and we’re going to keep on talking about it

[00:05:23] because code is written for other humans.

[00:05:24] It’s written primarily for other humans to understand.

[00:05:27] So when you consider both of these things together, number one, that we need to focus

[00:05:31] on one thing at a time, and number two, that code is written to be understood best by humans,

[00:05:37] then we can easily realize that our code needs to have some level of focus.

[00:05:42] Our code needs to implement patterns that our brain naturally works well with.

[00:05:48] And as we’ve mentioned in the past, focus typically means that you’re only doing one

[00:05:52] thing at a time.

[00:05:54] As it turns out, this is not a novel concept.

[00:05:57] The idea of reducing your code into a single responsibility is aptly named the single

[00:06:04] responsibility principle, and it was written down formally in the early 2000s by Robert

[00:06:10] C. Martin.

[00:06:11] Now, you might know that name.

[00:06:12] You might know him better as Uncle Bob.

[00:06:14] Uncle Bob helped write the Agile Manifesto, and he came up with the solid principles.

[00:06:20] S-O-L-I-D.

[00:06:22] The first one is single responsibility.

[00:06:24] Now, the formal definition of this was a class should only have a single responsibility,

[00:06:30] specifically a class being an object-oriented class implemented in an object-oriented language

[00:06:37] like Ruby or Java.

[00:06:39] Uncle Bob’s definition held that only one change in the software specification should

[00:06:44] make a difference to that class.

[00:06:47] But we can extend this idea of single responsibility to encompass any particular block of code that

[00:06:54] we are writing.

[00:06:55] For a given method, that method should only do one thing.

[00:06:59] For a class, that class should only be responsible for one concept.

[00:07:05] Now, if this seems a little bit difficult to understand, then you can use this rule

[00:07:10] of thumb.

[00:07:11] Anything that you give a name in software, whether that’s a class, a function, or a variable,

[00:07:17] should only encompass what that name says that it encompasses.

[00:07:23] An easy way to…

[00:07:24] find out whether or not you are going beyond a single responsibility is if you are commenting

[00:07:31] in between different sections of a given method.

[00:07:34] So, for example, if you’re setting up a database, you might go and get the credentials in one

[00:07:40] part of the method, and you may actually establish the connection in another part of the method,

[00:07:45] and you may handle errors in another part of the method.

[00:07:47] That’s three separate responsibilities that that single method has, so instead, a better

[00:07:53] way to handle this…

[00:07:54] is to create those three methods so that the actual implementation code for each of those

[00:08:00] methods is held in its own location.

[00:08:03] Another good rule of thumb, particularly for object-oriented programmers that I’m stealing

[00:08:08] from Sandy Metz, is to keep your classes about 100 lines long.

[00:08:13] I know I mentioned this on a recent episode, but I think it’s relevant for this particular

[00:08:17] discussion because it helps you scope how much responsibility a single class should

[00:08:23] have.

[00:08:23] Now, there’s a…

[00:08:24] significant amount of this discussion that comes down to your own personal judgment.

[00:08:29] Are you able to understand everything that a given class, or a given method, or a given

[00:08:35] variable is doing?

[00:08:36] If any part of it seems out of place, or if it seems like it’s taking a diversion from

[00:08:42] what the rest of the class is doing, or what the rest of the method is doing, or if you

[00:08:46] find yourself having to comment the code to tell the story of what that code is doing,

[00:08:52] then it’s likely that you are violating the code.

[00:08:54] You’re violating the single responsibility principle, and you need to break things out

[00:08:58] into smaller methods, smaller chunks that do one thing at a time.

[00:09:02] That is how you gain focus in your code.

[00:09:06] Smaller amounts of code that have limited responsibilities.

[00:09:12] Thanks so much for listening to today’s episode of Developer Tea.

[00:09:15] I hope it encourages you to start coding a little bit earlier because we have all of

[00:09:21] these resources that are available to us.

[00:09:23] Speaking of resources, I’m going to talk a little bit about how to use them.

[00:09:24] I’m going to talk a little bit about how to use them.

[00:09:24] I’m going to talk a little bit about how to use them.

[00:09:24] Check out DigitalOcean, today’s sponsor.

[00:09:27] They provide a very fast and easy way to get up and running with a cloud SSD.

[00:09:33] Just 55 seconds, and if you use the code DEVELOPERTEA today, you can get $10 off.

[00:09:41] So go check that out.

[00:09:42] All the links will be in the show notes.

[00:09:43] Thank you again for listening to today’s episode, and until next time, enjoy your tea.

Visão de gráfico