QA Friday 2016-Aug-12

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 projec