Over a million developers have joined DZone.

Tons of Small Classes

· Java Zone

Discover how powerful static code analysis and ergonomic design make development not only productive but also an enjoyable experience, brought to you in partnership with JetBrains

When I do Clean Code Training or if I discuss the topic with coworkers one argument comes up over and over again:

“But if I have split all my code in those tiny methods and classes, how will I find anything? I’ll have to navigate through dozens of files!”

The problem with this argument is: It is not that wrong. And I have certainly seen code where I had to navigate a dozen classes very carefully in order to understand what is going on.

If you look at it from an abstract point of view it looks like it even has to be this way. If you want to completely understand a piece of code it’s certainly best, to have it all in one piece on the monitor. You can go from top to bottom, line by line. If you have lots of little methods and classes, you in addition to that have to navigate through all that classes and methods, keeping track on from where you called this piece of code. Obviously these are additional tasks that just make your work harder!?

I still insist this argument is wrong. The mistake is the premise that the task at hand is to understand all the code.

It is very limited what you can keep in your brains working memory at any given time. So for any non trivial program the task to completely understand it is not feasible.

The real task at hand is to

  1. limit the amount of code you have to understand
  2. make it as easy to understand as possible

The key to that is abstraction!

Let me ask you a question: How often do you use a HashMap or what ever the equivalent in your preferred programming language is used? Probably many times a week, right? But how often do you actually look into the source code of a HashMap? Probably next to never! We just know what a Map does and that a HashMap is one very good general purpose implementation of it. That’s all we need to know about it. We just use it. We just know how it behaves. We just understand what is going on when it get’s called.

If your abstractions, i.e. your methods and classes are just like that, you don’t need to look at their source code most of the time. You just read the name and you know what it does. You probably don’t know how it does it. At least not in detail. But you don’t need to. If you know what it does, you know enough to decide, if you need to step into that class or not, for what ever you try to achieve right now.

Of course if what your classes and methods do isn’t as obvious as a get on a HashMap you still have room for improvement.

Learn more about Kotlin, a new programming language designed to solve problems that software developers face every day brought to you in partnership with JetBrains.

Topics:

Published at DZone with permission of Jens Schauder, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}