Clean Code – How to Write Classes the Right Way

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | TuneIn | RSS

This week Allen is troubled by circles, Michael talks like a game show host, and Joe announces it’s twins as we continue our deep dive into the classic Clean Code book by Robert C. Martin.

Join in on the conversation by becoming a member of our Slack community by signing up at http://www.codingblocks.net/slack.

For the full show notes, visit: http://www.codingblocks.net/episode55.

Survey

This week’s survey: What type of development floats your boat?

News

• Big thanks to all of those that took the time to leave us a review!
  • iTunes Reviews: Brain D., Bonny Jamburloony, Jazman9000, Jon Moscrop, Aaron’s iPhone
  • Stitcher Reviews: jd2017, DrArtz, mrbailie, Weslextech, carndog19, ManWithCamera
• Joe releases another video in the Mini Code Adventures series. Watch at YouTube.
• Paul Seal gives Joe a lesson on how to setup Umbraco. Watch at YouTube.

Stickers

Want some? We want you to have some. Send us a self-addressed stamped envelope. More information available at http://www.codingblocks.net/swag.

Classes

Order Matters

• Class should begin with a list of variables
  • public static constant (or read only)
  • private static
  • private instance
  • public functions
  • private utility methods after the public function that calls it
• “Seldom a good reason to have a public variable”
• If a variable needs to be protected in order to be accessed by a test, so be it

Classes should be small

• Rather than count lines, count responsibilities
• Just because it’s small doesn’t mean it’s good – could still have too many responsibilities
• If you cannot derive a good class name, it’s probably too large / too broad a scope
• “Weasel” words like Processor, Manager, Super, usually indicate too many responsibilities
• We should be able to describe a class in 25 words without using the words “if”, “and”, “or”, or “but”.

Classes should adhere to SRP

• SRP, Single Responsibility Principle (Wikipedia): The S in SOLID
  • A class or module should have one and only one reason to change
• Identifying responsibilities can help us refactor into better, more concise classes
• SRP is easy to follow but usually the most abused concept
• Most people are focused on getting something done, so organizing the code goes to the wayside
• There is the concern of ballooning the number of files / classes that must be traversed to understand an application
• Would you rather organize drawers by just throwing everything into two drawers, or would you like well separated filing cabinets?
• Many small classes is better
• Large, multipurpose classes force us to scroll through code that we don’t need to know about right now.

Cohesion

• Classes should have a small number of instance variables
• Methods should affect as many variables in the class as possible to achieve “high cohesion”
• When variables aren’t used by many methods, those are probably begging for a new class
• When classes lose cohesion, it’s time to split them up.

Organizing Change

• Breaking classes into smaller, simpler functions reduces the event that one function will break another
• Subclassing properly can help reduce number of breaks in existing code
• “Private method behavior that applies only to a small subset of a class can be a useful heuristic for spotting potential areas for improvement.”
• OCP, Open Close Principle (Wikipedia): The O in SOLID
  • Classes should be open for extension but closed for modifications
• Ideally, we add new functionality by extending the system, not modifying the existing code.

Isolating from Change

• A client class depending on concrete details is at risk when those details change
• Using a good base / abstract class can make testing easier as you can create repeatable tests
• Making code more testable makes it more reusable in effect
• DIP, Dependency Inversion Principle (Wikipedia): The D in SOLID
  • Classes should depend on abstractions, not concrete details

Resources We Like

Of course we’re going to mention Clean Code.

Tip of the Week

• Trade in your old tech books (or other stuff). Check out this link at Amazon for the details.
• GUID Performance in SQL Server as a Primary Key. See this popular answer on StackOverflow.
• Use git archive to Git the files, not the repository. See the git-archive documentation and this popular answer on StackOverflow.

Spread the Word!

Enjoy the show? Want to help us out? It’s easier than you think. Simply tell everyone you know. And have them do the same.

OK, but seriously, we can’t expect you to tell everyone you know, but you could help us by sharing the show with some of the people you know. See? That’s not so bad now is it?

And if you haven’t already, we’d love for you to leave a review. Head to http://www.codingblocks.net/review to share your opinion with the world. Make your voice known.

Peace, love, and code.