I originally heard this concept from one of the luminaries of our industry, Uncle Bob Martin. This is the idea of hidden components or classes. In our very component-driven current age, they are often the heart of our applications. They often get the most focus and discussion.
Your application probably contains many hidden components. These components should exist on their own, yet they don’t. You haven’t created them and separated them out. I don’t mean new functionality either. This is existing functionality your app already has. But the components to control this functionality are hiding. You don’t know about them.
Where are they? Where are they hiding?
Simple: inside of other components…larger components. Components that are doing too much contain these components that you need to find and extract.
This concept is partially described by the concept of Container vs Presentational components. Following this pattern will certainly help you find and extract some of these hidden components, but this pattern isn’t sufficient. It helps divide components up by purpose, but that still leaves too much room for presentational components that contain other presentational components inside of them. The same thing goes for container components. You can easily have some of them that are hiding other container components inside of them.
The first question to ask here is why bother? Why do we care if there are components hiding in our application? If the application works, what does it matter? Let those hidden components be. They’re not hurting anyone….are they?
YES. They are. Hidden components are just another form of poor code with increased maintenance costs. You have not yet fully paid for those components. Writing a piece of “bug-free” code is not the end of it. Maintenance costs are still yet to come.
When you write a line of code, you have only made a down payment on the total cost of that code. Probably only a small one at that. The real cost comes as the code continues to run and requires maintenance as bugs are found, and new features are added to the system. As rewrites are initiated and understanding the current system is required to build the new one.
You might spend a minute writing a line of code, and an hour reading and maintaining it over the life of the application.
So, yes, your hidden components matter. They are costs waiting to happen. Call it technical debt, call it bad code, call it the Dark Side of the Force. Whatever you want to call it, it exists.
So craft your code carefully. In the case of components, find the smaller components that are hiding inside of the bigger ones, and extract them into their own components.
But how, you may ask?
I wrote about this recently in my article about the Single Responsibility Principle, “A Reason for Change”. Make sure your components each have a single responsibility and look for reasons for them to change. That will help you find your hidden components.
Keep your code tight and well-factored. Yes, this all sounds simple, but the honest truth is that it’s difficult. But it is possible to always be learning, always getting better.
Happy Coding!
Enjoy this discussion? Sign up for our newsletter here.
Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster
Top comments (0)