« All Episodes

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

Published 8/3/2015

In today's episode I review why focus is so important to coding by diving into the Solid Principles developed by Robert C. Martin also known as "Uncle Bob" and the importance of the Single Responsibility Principle: A class should have one, and only one, reason to change.

Thanks to today's sponsor: Digital Ocean

Today's episode is presented by DigitalOcean. Go to https://digitalocean.com to get started, and use the promo code "DEVELOPER TEA" at the checkout after you create your account to get a $10 credit!

I hope you've enjoyed this episode. Until next time,

Enjoy your tea.

Transcript (Generated by OpenAI Whisper)
Hey, everyone and welcome to Developer Tea. My name is Jonathan Cutrell, and today I'm going to be talking about Focus in your code. Of course, you know I talk about the concept of Focus quite often on this show. In fact, one of the very first episodes of Developer Tea was on Focus because it is so important that we develop Focus so that we can actually work on something that takes a significant amount of mental energy. In that episode, I went on to discuss why Focus is more important for a software developer than it would be for most other jobs that don't require you to keep a lot of stuff in working memory. But Focus isn't just something that you practice in your own mind. The concept of Focus is actually applicable to the things that you are producing, specifically developing a sense of focus in your code base is important for it to be able to be understood by you or other people in the future. So in this episode, I want to talk about what it means to have focused code. How do you write code that is easily understood and works the way that your brain already works? So let's revisit the idea of distraction to talk about why Focus is important. If you were, for example, to write your name on a piece of paper, write your first and your last name, that's relatively easy for you to do. If you write your first name and then your last name, now if you were to try to write one letter each from your first name and then your last name, for example, for me, I would write J for Jonathan, then I would write C for Cutrell, and then I would write the O and then the U. If I were to do this, it's going to take me much more time because I am having to switch context. My brain is not very good at switching context, and this is a simple proof of that inaction. Now, there's a lot of reasons why that particular example works so well, some of them have to do with what we call muscle memory, but the underlying truth remains the same. It's been studied over and over. We just aren't very good at multitasking. Now, a computer can be quite decent at multitasking. And specifically, when we talk about multitasking, we're more talking about switching between tasks. Unlike a human, a computer doesn't really have much overhead switching between tasks. It can do one thing and then jump to another, and it's basically the same performance as if it were to continue doing the first thing. But we have to remember that we write code for humans. We do not write code for computers. Most of the best practices in computer science are created for humans to be able to connect the dots between each other's code, not a computer to connect the dots. A computer doesn't have a preference of what style of code you write. A computer doesn't have a preference of how you name your variables or your methods. A computer doesn't care if you use a functional paradigm or an object-oriented paradigm with some minor performance considerations. All of these abstractions have been created for humans. All of these abstractions are intended to give us an interface to be able to code our intentions into the computer and to be able to transfer that code between myself and another person or myself and future me. I'm going to take a quick sponsor break and then I'm going to come back and talk about how to use the single responsibility principle to match the way your brain works, to make code more understandable and to make it more focused. Today's episode of Developer Tea is sponsored by DigitalOcean. DigitalOcean is simple cloud hosting built for developers. They're dedicated to offering the most intuitive and easy way to spin up a cloud server. And in just 55 seconds, you can deploy a solid state drive cloud server. Plan start at only $5 per month for 512 megabytes of RAM, a 20 gigabyte solid state drive, one CPU, and a full terabyte of transfer. In addition to offering simple and affordable SSD cloud hosting, DigitalOcean is dedicated to building out a strong community and supports open source software. They offer a vast collection of hosting tutorials and invite Developer To submit articles and they pay $50 per published piece. Deploy your SSD cloud server with DigitalOcean today by going to digitalocean.com. Now DigitalOcean has been kind enough to provide Developer Tealisteners a discount of $10 when you use the code Developer Tea. So go to digitalocean.com and use the code Developer Teato get $10 off today and you'll get up and running with your own SSD cloud server in just 55 seconds. That's digitalocean.com. We've been talking once again about focus on today's episode specifically about focusing your code and why it's so important for you to focus your code. Of course, computers don't have to worry about the overhead that it takes to switch between tasks, but as humans, we do have to worry about that overhead. We need to be able to think and focus on one thing at a time. On top of that, code is written for other humans. We talked about this in previous episodes and we're going to keep on talking about it because code is written primarily for other humans to understand. So when you consider both of these things together, number one, that we need to focus on one thing at a time and number two, that code is written to be understood best by humans, then we can easily realize that our code needs to have some level of focus. Our code needs to implement patterns that are brain naturally works well with. And as we've mentioned in the past, focus typically means that you're only doing one thing at a time. Now, as it turns out, this is not a novel concept. The idea of reducing your code into a single responsibility is aptly named the single responsibility principle and it was written down formally in the early 2000s by Robert C. Martin. Now you might know that name. You might know him better is Uncle Bob. Uncle Bob helped write the Agile Manifesto and he came up with the solid principles. S-O-L-I-D, the first one is single responsibility principle. Now the formal definition of this was a class should only have a single responsibility, specifically a class being an object oriented class implemented in an object oriented language like Ruby or Java. Uncle Bob's definition held that only one change in the software specification should make a difference to that class. But we can extend this idea of single responsibility to encompass any particular block of code that we are writing for a given method that method should only do one thing. For a class that class should only be responsible for one concept. Now if this seems a little bit difficult to understand then you can use this rule of thumb. Anything that you give a name in software whether that's a class, a function, or a variable should only encompass what that name says that it encompasses. An easy way to find out whether or not you are going beyond a single responsibility is if you are commenting in between different sections of a given method. So for example if you are setting up a database you might go and get the credentials in one part of the method and you may actually establish the connection in another part of the method and you may handle errors in another part of the method. That's three separate responsibilities that that single method has. So instead a better way to handle this is to create those three methods so that the actual implementation code for each of those methods is held in its own location. Another good rule of thumb particularly for object oriented programmers that I'm stealing from Sandy Metts is to keep your classes about 100 lines long. I know I mentioned this on a recent episode but I think it's relevant for this particular discussion because it helps you scope how much responsibility a single class should have. Now there's a significant amount of this discussion that comes down to your own personal judgment. Are you able to understand everything that a given class or a given method or a given variable is doing? If any part of it seems out of place or if it seems like it's taking a diversion from what the rest of the class is doing or what the rest of the method is doing or if you find yourself having to comment the code to tell the story of what that code is doing then it's likely that you are violating the single responsibility principle and you need to break things out into smaller methods, smaller chunks that do one thing at a time. That is how you gain focus in your code. Smaller amounts of code that have limited responsibilities. Thanks so much for listening to today's episode of Developer Tea. I hope it encourages you to start coding a little bit earlier because we have all of these resources that are available to us. Speaking of resources, check out Digital Ocean today's sponsor. They provide a very fast and easy way to get up and running with a cloud SSD. Just 55 seconds and if you use the code Developer Tea today you can get $10 off. So go check that out. All the links will be in the show notes. Thank you again for listening to today's episode and until next time, enjoy your tea.