When should I create a new class?
There’s no single answer I can give you for this because every situation is different and even then, there’s usually no design that’s right or wrong. It’s all a tradeoff. You give up one thing and get something else. But I do have some opinions and can explain how I approach problems and some of the reasons for when I’ll create a new class.
A lot of this comes from experience. I’ve programmed enough to be able to anticipate the needs of my code later and can start out with what might seem to be a bit too much design at first. The program will grow into the design later. At least that’s the goal. It doesn’t always happen especially when the requirements change.
The first thing I look for are examples. I try to find the descriptions and stories of how something similar was done either through books, magazines, or online articles. And if there are multiple sources, that’s even better because then I can compare the approaches taken. This doesn’t mean that I copy the designs. I learn from them. I try to approach each new project with an open mind and learn as much about the current situation as possible. Technology changes fast so it’s not a good idea to keep using the same methods and designs without first checking to see if there’s a better way.
One of the first reasons to create a new class is to fit in with a framework or library. These usually have specific requirements that will affect how you design your code.
Then you can start applying design patterns. Make sure to listen to episodes 59 through 90 for more information about design patterns. There’s a full episode for each design pattern that I explained. Many of these design patterns make use of classes and special relationships between them.
Another reason to create a new class is when you find some new behavior. You wouldn’t create a new class just for some difference in data.
When I’m starting a new project in a new field, I usually wait until there’s either a clear need for a new class or my experience from other projects allows me to anticipate a future need. One sign of a clear need is duplicate code. If you ever find yourself writing similar code or even the same code in multiple classes, then you should rethink your design. This is not a bad thing. It’s a sing that you need to refactor the common code into either some other class or method.
Listen to the full episode or you can also read the full transcript below.
Transcript
The question this week comes from Rich who wanted to know when to create a new class. Should everything go into the main method until it gets too big and complicated? Should classes be created ahead of time even if their use is unclear?
There’s no single answer I can give you for this because every situation is different and even then, there’s usually no design that’s right or wrong. It’s all a tradeoff. You give up one thing and get something else.
But I do have some opinions and can explain how I approach problems and some of the reasons for when I’ll create a new class.
A lot of this comes from experience. I’ve programmed enough to be able to anticipate the needs of my code later and can start out with what might seem to be a bit too much design at first. The program will grow into the design later.
At least that’s the goal. It doesn’t always happen especially when the requirements change.
The thing that will probably benefit you the most is if I explain how I approach a new situation.
The first thing I look for are examples. I try to find the descriptions and stories of how something similar was done either through books, magazines, or online articles. And if there are multiple sources, that’s even better because then I can compare the approaches taken.
This doesn’t mean that I copy the designs. I learn from them. I try to approach each new project with an open mind and learn as much about the current situation as possible. Technology changes fast so it’s not a good idea to keep using the same methods and designs without first checking to see if there’s a better way.
This is how I found one of my favorite technologies a few years ago. I was looking for ways to serialize data so that I could send it from one computer to another. I found Google’s Protocol Buffers during this investigation along with several other methods. I spent several days just researching the alternatives. This involved reading, searching, and test designs.
Imagine you want to buy a new car and the last time you had to do this was 8 years ago. A lot’s changed in the last 8 years. Do you base your decision on what you knew from 8 years ago? Or do you visit the dealers, read online reviews, and take a few cars out for a test drive?
I suggest the same thing for software designs except think more in terms of months instead of years. If it’s been over 8 months since you last investigated alternate designs, then you might miss out on some advancement that could help you.
Why am I mentioning all this about researching technologies when this episode is supposed to be about when to create a new class? Don’t worry, I’ll tie it all together right after this message from our sponsor.
You might be familiar with the experiment of putting some large rocks into a glass along with several smaller rocks and some sand. If you put the sand in first then the smaller rocks, there won’t be any room for the larger rocks. You need to start with the big items and maybe some smaller items along the way. Once they’re all in place, the sand can fill in the gaps.
The same thing happens in software. Thinking about which classes to create won’t do you any good at first. This is the sand. You need those bigger pieces. Choosing a framework is like placing the large rocks. You can make use of software libraries next which are the smaller rocks. Then all your code makes up the sand.
You don’t have to follow this approach. It’s really up to you. Maybe you research various frameworks and libraries and don’t find any that meet your needs. They could be poorly written and behave badly. They might have licenses you don’t agree with. But if you do decide to use a framework or a library, then you’re going to want to create a design that fits in with the framework or library. Actually a framework will be more influential in your design than a library.
So all of that is the first reason for creating a class, to fit in with some bigger design.
Then you can start applying design patterns. Make sure to listen to episodes 59 through 90 for more information about design patterns. There’s a full episode for each design pattern that I explained. Many of these design patterns make use of classes and special relationships between them.
Another reason to create a new class is when you find some new behavior. You wouldn’t create a new class just for some difference in data. For example, cars. You probably wouldn’t want a RedCar class and a BlueCar class because color would be better represented as a property of all cars. What about a race car vs. a street car? Maybe. But, again, most of this is just a difference in data. A race car has a higher top speed than a typical street car. But since they both behave essentially the same, then separate classes may not be a good idea. Now, a race car with no lights, no functional doors, and no reverse gear might be different enough to need a separate class.
Once you find some behavior difference, then you can decide if you want to use inheritance, composition, or some other design to model the differences.
When I’m starting a new project in a new field, I usually wait until there’s either a clear need for a new class or my experience from other projects allows me to anticipate a future need.
One sign of a clear need is duplicate code. If you ever find yourself writing similar code or even the same code in multiple classes, then you should rethink your design. This is not a bad thing. It’s a sing that you need to refactor the common code into either some other class or method.
One last reason to create a class is for organizational purposes. If you have a group of methods or data that are related, then a class can sometimes be a good way to group them together.