How to avoid too many classes is not a good question a better question would do you want to avoid too many classes? Let’s explore:
A developer was ridiculing the way code was written in a project. I can hear it because he was sitting next to my cubicle. He was loud so other developers gathered around.
He was telling everybody that “Who write such a code– why so many classes and interfaces? Why is there so much code to do a simple task”.
It was in late 2007. When ASP .NET was moving from Web Forms to MVC and we were looking at open source MVC framework for .Net. Although MVC was well known in JAVA world Microsoft was in the early phases of releasing it’s MVC framework.
TOO many classes?
It was a ridiculous idea for us that there were so many classes and interfaces.
When I was learning about Filling in JAVA I always beat my head that why so many classes to do a simple task. I pondered why is there a Stream object and then another object BinaryWriter/BinaryReader to do a minuscule job.
Afterward, when I started programming in C# I found that developers of C# were doing the things like JAVA developers i.e. too many classes to do a simple job of filling.
I thought that there might be something with this shit load of classes and C#/Java architects know something that I don’t. They were elite developers-Right?
I did a simple research and found out that those developers were implementing the Decorator pattern with Stream class.
Design patterns are easy to understand but difficult to implement and the obvious help i.e books are full of boring and basic level examples. Although, I found out a real-world example of the decorator pattern and it was better than the boring textbook examples but still I didn’t internalize the real benefits of the pattern.
Except for the textbook benefits:
“It helps you Wrap”
OR
“Add features Dynamically”
I said hmmm… What does that even mean!. Ok, I can understand the benefits in terms of coffee, animal and other basic examples but how it would be helpful in a real world and real life scenarios.
Move Ahead or Dig Out
In programming, there are times when you don’t know why are you doing something. Like following the guidelines of using an API or framework. At that moment you can do two things.
First is that you go out and dig the solution and keep yourself stuck instead of moving. This sound logical and I have found many peers doing the same. They don’t keep the things at a higher level of understanding and try to find out the deeper understanding right there.
I am not going to tell you that you should not find out the answers but keeping yourself stuck is more dangerous. Moving create momentum and bring results and results will feed your desire to learn more. But if you are going down the rabbit hole it is quite possible that the answer is in front of you but it is going to take a lot more time before you recognize it.
The second option is you take the leap of faith. You trust the experience of senior developers and keep working on that path laid out in front of you. In that path, every roadblock that you will ever face is taken care of.
In the case of Filling and decorator pattern I trusted the experience of senior developers and keep using them. Therefore, when I was writing code for network I observe the benefits of the decorator pattern in classes Stream and NetworkStream.
In another project of mine, I have to write an acquisition library from the scratch. I write all the basic I/O function and at that moment I really miss the Stream class:). So I write one for myself. This was the second occasion when I realize the importance of the Decorator pattern.
So, now, will I make fun of some senior developer’s code if he has written too many classes–NO. I will just take a leap of faith and believe in the wit of seniors and every puzzle will be solved down the line. Not today or in next few months but it will be clear to you when you see the benefits from your eyes.
We all know that design patterns/frameworks usually causes more classes. But they made their place in the solution and they will pay off when you realize their benefits in the not so distant future.
Note for a CREATIVE programmer
One of my peers considers himself a creative person. In his opinion, you have to break the rules to make new ones. I took him seriously and tried to break the rules. But rules broke me. Why?
We have seen creative people like Steve jobs breaking rules all the time and succeeding. So why I was failing? I was failing because I was missing an important part of the equation.
“To break the rules you have to know the rules.”
Once you master the rules and principles then and only then you can break them. Steve job has spent years and years in computer electronics and hacking phones before he breaks the rules set by giants like HP and IBM.
So, if you are a creative programmer I encourage you to break the rules but first master them. If you think that design patterns developed by our seniors are useless and you can come up with better ones then hurray to you.
But first, complete the equation i.e master these patterns. Find out the real benefits and then break them and make new ones.
So do you have a story when you realize the real benefits of any design principle/pattern or framework that you were using for months or years? Reply to me. I love to read them:)