Object oriented programming is a powerful tool which many modern languages have been based around. However, many developers become bogged down by their object oriented framework, reducing the efficiency that object oriented design was supposed to improve. Some of the common mistakes developers make while developing in an object oriented environment include issues with naming, exception handling, deep hierarchies, and overly optimistic development.
Naming
Object oriented programming is designed to increase readability of code for developers, but with poor naming, code actually becomes even harder to read. Here are several examples of poor naming conventions:
Ambiguous Variables
Nondescriptive variable names can be confusing. In general, a developer should be able to look at a variable name and have a general understanding of what it does and what values it contains.
Misleading Functions
Java’s URL equals method is a notorious example of a misleading function name. Without getting into specifics, the function: lies, is inconsistent, and blocks. Instead, you are supposed to use the URI equals api if you want to compare two URLs.
Overly Descriptive Variables
The opposite of ambiguous naming is overly descriptive variable names. After a certain point, longer function names become hard to read. Multiple subsequent function calls become multiple lines long, detracting from readability. The goal is not to name for the sake of naming but to name for other developers who may read the code.
Exception Handling
A lot of object oriented languages such as Java have extensive exception handling built in. A common mistake that developers make is catching errors with non-specific exceptions.
Catching a generic IOException is lazy coding. There are many types of IOExceptions which may need to be handled differently and it’s difficult to know exactly what error has been thrown. Although it may be tedious, it is good practice to have thorough exception handling.
Deep Hierarchies
Inheritance is a powerful and core part of object oriented design and, like many things in object oriented design, it’s important to use it in moderation. Developers who use inheritance without restraint can see hierarchies go four, five, or even ten deep. The problem with deep hierarchies is that they tend to be brittle, meaning that a seemingly minor change can cause the whole thing to fail. This is known as the Fragile Base Class problem. Restructuring a class hierarchy due to a requirements/design change can also be incredibly painful. Instead, it is generally better to follow the rule of Composition over Inheritance. The idea is to identify the behaviors (verbs) as interfaces and have your class contain them as parameters, as opposed to the traditional way of describing a system through objects (nouns). See the image below for an example of Composition over Inheritance design. Composition over inheritance allows a code base to be more flexible and simplifies initial design by describing what a system needs to do.
Optimistic Development
Object oriented programming understands that developer time is expensive. Although object oriented design has more overhead and tends to run a little slower than its procedural counterpart, it trades this for easy readability, maintainability, and faster development times. Optimistic Hierarchies, which falls under over-engineering, kill all of that. It’s common when starting a new project for excited developers to plan huge hierarchies in anticipation of future features. However, what this does is actually create a large base of code that becomes tedious and hard to maintain and many of these planned features never come into fruition. It’s important to plan ahead, but when developing, the solution that generates the least amount of code is usually the better way to go.
When developing in an object oriented environment, it is important not to lose sight of the original goals of object oriented design: readability, maintainability, and increasing developer output. A good design finds a balance between over doing it and not doing enough. Poor naming and exception handling are examples of lazy coding, but on the other hand excessively deep hierarchies and optimistic development are examples of taking object oriented design too far. Object oriented programming is a powerful tool, but only when used correctly.