A little bit more about DRY
As you know, DRY means «Don’t repeat yourself». It sounds easy, isn’t it? When I first read about this, I said, “Yes, I’ve done that before! Hmm … «Piece of knowledge». What’s it? Doesn’t matter”. Yes, I tried to find out more as soon as possible. But the knowledge about the “Piece of Knowledge” still came to me… Through pain. Now let’s see how it was!
Imagine you have some kind of service where you can create and handle a client. Let’s dwell on the client creation. You wrote a cool, simple and modern component:
The component loads some initial data creates a client based on the mapped form values sends the created client for processing and then clears the initial and client data on unmount. This works well until new business requirements come in. Your company is launching a new product based on your service. And now the clients have to be stored in a different database and they have a slightly different structure. Okay! Take it easy. You already know about DRY. You realize that you already have a client-creating component and all you need to do is extend it for a new case.
So, you’ve added a property with a product type extended the model for the component added conditions to the handler and render method. It works. Time goes by and the owners of Product A wanted to expand the client model. Now you need to fetch more initial data call to special service for client evaluation and validate data before you create a client in client service. Oh, Yea… The owners of Product C also discovered your cool platform. So, are you understanding what it means, yea?
As time goes on, the component is overgrown with new conditions checks and specialized requests. But your skills grow up too. You understand that the component needs refactoring. And you started thinking and exploring ways to solve this situation. Returning to DRY, you understand a new detail that tells us to create an abstraction so as not to violate the principle.
Now you have the abstraction for all business cases. You feed it dependencies and it does what you need to do. The project continues to develop you successfully implement new requirements. But you have started to notice that each change takes more and more time. Types have begun to clash, the model has grown exorbitantly. You are upset. Everything was done the way it was written. What’s wrong? You’ve run to investigate DRY again. You’ve seen what your abstraction depends on details. And you’ve read the following quote from Sandy Metz:
Duplication is much cheaper than the wrong abstraction
Well, you’ve thought about this phrase and decided to split abstraction into specific implementations. For example ClientCreationA.
Now the development term for client creation feature for a new product is stable. All you need is to duplicate the code and implement the specificity. But you feel like you violate DRY and it haunts you. Once again, you have time to refactor, and you are determined to fix this problem for good. You ask yourself, «How do you implement DRY correctly?». You google it. And you find patterns. Dived into them, you’ve found the «Factory Method» pattern. This pattern lets you know how to properly highlight whatever you need for your abstraction. If we look at our client creation feature, we realize that the methods of loading and clearing data, submitting for processing, submitting and rendering are common to all products. Let’s rewrite our abstract component.
This abstraction we can use for creating specific features. Let’s see feature implementation for product A.
Summary
In the end, I have to say that writing abstractions unnecessarily is a bad way that will bring a lot of pain. When you see the necessity to implement your component for other cases, you should research with the business and find out the plans for the development of this feature. The way of implementation will depend on this. Do you know? This YAGNI… Also, I want to advise you to read these books:
- The Pragmatic Programmer: From Journeyman to Master by Andy Hunt
- Clean Code: A Handbook of Agile Software Craftsmanship by Martin Robert C
- Design Patterns: Elements of Reusable Object-Oriented Software by Gamma Erich (Author), Helm Richard (Author), Johnson Ralph (Author), Vlissides John (Author), Grady Booch (Foreword)
This might save you time. By the way, what other principles did I use but didn’t mention? 🙂
