Keep object-oriented structure simple

Software Craftsmanship manifesto says “working software is important but also well-crafted software is important”. A “well-crafted” software should be self documented. When a new developer reads codes and tests, should understand how it works. Keeping the structure simple helps to readability.

Today’s most common paradigm is object-oriented programming. It allows us to create objects that contain data and functions. For instance, you have a User object. It has a password, email, address etc. When the address is changed, you can update it with a method like “User->updateAddress()”. It is very close to the real world. That’s why it helps us to design real world methods the same in the code. Even if you are not a developer, you can understand the user object with properties and functionalities.

Thinking in object oriented is important

We learn inheritance, polymorphism, encapsulation, abstraction, etc. on the beginning. We create a “bird” interface with “duck” implementation and we think that we get the idea. But the fact can be different. We might not understand it very well. You might use primitive types too much or you might have large classes which have many responsibilities.

We can become aware of those problems with code smells. Code smells are a crucial topic. They can give clues about your code. If you spot them earlier, you can prevent to mess up your structure. I list some of major smells. You can find detailed explanations in Refactoring book.

- Primitive Obsession
- Feature Envy
- Message Chains
- Middle Man
- Data Clumps
- Tell Don’t Ask
- Long Parameter List
- Long Method

Don’t be obsessed about “Keeping options open”

We need to quickly and easily change the system. It’s one of the signs of a good architecture.

We learn many architectural patterns, design patterns and principles. We apply them for the future. But the future is unpredictable and uncertain. We feel stressful during uncertainty. When we apply those patterns or principles, we might feel comfortable and ready for uncertainty. But most of the patterns which we apply are redundant. We increase the complexity by over-engineering.

In the earlier stages of my career, I had a chance to design pretty big web application. I started to design architecture alone. When other developers joined me, the project was flexible and extendible. Everything was designed according to books. If you wanted to implement a storage system, you could handle it with couple of classes. Did you want to add a caching layer? My adapter pattern was ready. But after a while, I realized that we had a small issue. The structure was too complex. The project always needed to be explained by me. And I made it unnecessarily flexible. We kept the storage system the same. We didn’t need one more caching system. Long story short, it was over-engineering. I can hear you say “I made the same mistake” as I write these lines.

Design patterns, coding principles, architectural patterns, etc. are helpful things. We should learn and understand them. There is no need to reinvent the wheel. They can be useful. But they are just tools. We should focus on use cases, not them.

Keep away from implementing unnecessary design patterns

Gang of Four was written 28 years ago. It’s been inspiring to the software industry. It is a brilliant book. But the book was published in 1994. The industry has been changed. Many things happened after that book. The agile manifesto published. We have been working in scrum teams. Monolithic projects are not cool anymore.

Many design patterns are suitable for large teams. In today’s world, if you don’t work on an open source project, you probably aren’t working with hundreds and thousands of people. People work in small teams and generally have their own projects. It is not possible for hundreds of people to use the class that you created.

Today, changing something is easier. You cannot break other teams’ codes. Because they don’t code for your project. Maybe your team has 10 developers and they only contribute to the project. You don’t need to design your code as working with hundreds of people. When use case is changed, you can rewrite that part easily. So you don’t need too many layers, interfaces or packages.

That doesn’t mean you shouldn’t use any patterns. If you really need it, you can use them. But consider this, it’s costly and it increases the complexity.

Conclusion

Complicated structures can waste your or your colleague’s time. It might even waste your future colleague’s time. A good design should be centered on use cases or business requirements. At the end of the day, it might be a basic user system and you might have to make it more complex. Keeping things simple can help you create an understandable system. That might be more important than you think.