As a bootcamp instructor, I’ve reviewed a lot of junior dev code… like, a lot. There are a handful of errors I see new programmers run into over and over again when creating OOP projects, so I wanted to write an article about them! In this article, I’ll discuss 3 common object-oriented programming mistakes junior devs make, and why they’re mistakes. Making these mistakes can lead to poorly-designed, tightly-coupled code and a difficult-to-understand, hard-to-maintain codebase!
Mistake 1: Poorly-Designed Classes
When you’re new to OOP, it’s common to write classes that are too big or that “do too much”. It’s also common to write classes that have unclear responsibilities, or classes where the properties and methods of the class aren’t clearly connected. If you find yourself adding properties or behaviors to your class that are only loosely related, take a step back and think about what the class's instantiated objects will need to do in your application. If your class contains too many unrelated things, it will make it more difficult to use the resulting objects in your program later on.
Ideally, classes should only “do one thing”. This is the Single Responsibility Principle (SRP), originally coined by Robert "Uncle Bob" Martin. Each class in your application should have a single, well-defined responsibility or purpose. When a class has multiple responsibilities, they can become tightly coupled with other classes, resulting in codebases that are difficult to maintain. Think about it this way: if you are going to change something about your program, will you have to re-write many classes with dependencies on each other? If so, you haven’t followed the SRP very well.
Another class design issue I see with new developers is including a lot of methods that don’t return anything. If a method does not return a value, what is its purpose in the class? Returning “void” is perfectly fine if you have a reason to do so, but if none of the methods in your application return a value, how will you write comprehensive unit tests to verify the behavior of your objects? When a method produces a result, you can easily test the output and compare it to the expected outcome of the method call.
Mistake 2: Misusing Inheritance
Once you’ve learned how to use inheritance, it can be tempting to create a lot of base classes and subclasses–even if you don’t need them. If you find yourself creating deep, nested class hierarchies, take a step back and consider if you really need them. Inheritance should only be used for “is-a” relationships, and not simply to reuse code in another class. If you have unrelated classes that use the same or very similar code, you may need to go back to the paragraph above and rethink your class design!
On the other hand, some new developers don’t use inheritance enough. If you have related classes and don’t inherit repeatable code from a base class, you may not be writing “DRY” code. DRY stands for “Don’t Repeat Yourself”, and reminds us that we shouldn’t be duplicating code across multiple classes–doing so can make code maintenance an absolute nightmare when a block of code has to be updated in multiple places. What happens if (when!) you forget one?!
Mistake 3: Treating Encapsulation As Optional
A very common thing I see with devs new to OOP is the overuse of the “public” access modifier. While the majority of things in your code can probably be public, it’s important to keep an eye out for properties and methods that don’t need to be available outside of their class. For example, properties of an object should be accessed and modified via getter and setter methods, and not by direct access to the properties. This helps avoid a tight coupling of code when working with objects.
Similarly, if you find yourself relying on global variables, you probably need to take a step back and reconsider your design. “Global” refers to variables that are accessible from anywhere in an application, and overusing them can lead to very tight coupling of code, reduced maintainability, and lots of problems debugging. If you rely on a piece of information being available from anywhere in your application, any changes to that information can result in bugs cropping up in several different parts of your program.
Another mistake I see often is liberal use of the “static” keyword, mostly because a lot of IDEs will suggest it as a “fix” when a new developer is trying to directly use a class instead of instantiating objects from that class. If you don’t fully understand why something would need to be static, it probably does not need to be static! Remember, it’s “object-oriented programming”, not “class-oriented programming”.
Conclusion
Does it take some time to fully get your head around OOP? Yes, absolutely! Making these object-oriented programming mistakes is extremely common and they’re all part of a new developer’s learning process. If you’re a new dev, be on the lookout for these mistakes while you’re programming, and actively seek out ways to improve your code: ask a senior for review, make practice projects, and write unit tests as you go! By learning from the challenges you encounter along the way, you’ll become a more object-oriented developer quickly. Happy coding!
This post was originally published at CodeMom.net.
Top comments (1)
I would include some code examples and it would be a perfect post (it's great without them) 🚀