DEV Community

Cover image for Code Smell 147 - Too Many Methods
Maxi Contieri
Maxi Contieri

Posted on • Originally published at maximilianocontieri.com

Code Smell 147 - Too Many Methods

Util classes are great to gather protocol

TL;DR: Don't add an accidental protocol to your classes

Problems

  • Readability

  • Single Responsibility Violation

  • Bad Cohesion

  • High Coupling

  • Low Reusability

Solutions

  1. Break your class

  2. Extract Class

Related Refactorings

Context

We tend to put a protocol in the first class we find.

That's not a problem.

We just need to refactor.

Sample Code

Wrong

public class MyHelperClass {
  public void print() { }
  public void format() { }
  // ... many methods more

  // ... even more methods 
  public void persist() { }
  public void solveFermiParadox() { }      
}
Enter fullscreen mode Exit fullscreen mode

Right

public class Printer {
  public void print() { }
}

public class DateToStringFormater {
  public void format() { }
}

public class Database {
  public void persist() { }
}

public class RadioTelescope {
  public void solveFermiParadox() { }
}   
Enter fullscreen mode Exit fullscreen mode

Detection

[X] Automatic

Most linters count methods and warn us.

Relations

More info

Refactoring Guru

Tags

  • Cohesion

  • Bloaters

Conclusion

Splitting classes and protocol is a good practice to favor small and reusable objects.

Credits

Photo by Marcin Simonides on Unsplash


There is no code so big, twisted, or complex that maintenance can't make it worse.

Gerald M. Weinberg


This article is part of the CodeSmell Series.

Top comments (10)

Collapse
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️
public class Printer {
  public void print() { }
}
Enter fullscreen mode Exit fullscreen mode

I know this is an example, and such a class would usually have more methods and some state, but with the example like that, it's the perfect example of something that shouldn't be a class, but a simple subroutine.

Collapse
 
mcsee profile image
Maxi Contieri

Hi

Objects have protocols and behavior

Subroutines don't.
This is another Code Smell called 'Helpers'

Collapse
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

Subroutines don't.

This sentence has more flaws than words and that's kind of impressive.

  1. The "behaviour" is literally a bunch of subroutines
  2. Having behaviour is literally what subroutines are about
  3. How do you think calling subroutines even works if there are no protocols...?
Thread Thread
 
mcsee profile image
Maxi Contieri

hi

1 - The behavior is on the real world objects. I could never have a real world metaphore for a subroutine.
2 - Having behavior is always related to real world objects
3 - I don't do structured programming. So I don't know about subroutines. I am fine with them in structured paradigm.

Thread Thread
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

 So I don't know about subroutines

So you don't use methods on your objects?

Thread Thread
 
mcsee profile image
Maxi Contieri

of course.

Methods are the way to implement the accidental 'how' and to perform the essential 'what'
An object is what it does.
And methods fullfill the object's contract

Thread Thread
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

So the contract and the behaviour originate in the real world and manifest themselves in subroutines; then what do we need objects for?

Thread Thread
 
mcsee profile image
Maxi Contieri

Subroutines are fine for programming in the small.
For example a solo work

In order to manage complexity and very large systems you need to follow principles like these

IMHO, You cannot built a serious system based on subroutines.
That was 1950's approach and didn't scale. It was called 'The software crisis'.

And that's the difference between beeing a software engineer and a coder

Thread Thread
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

I assume you just misunderstand what a subroutine is, because you seem to think they're somehow a different thing than methods. They're not. When you call a method on an object, you're using a subroutine.

And since the behaviour of any object-oriented system is implemented in methods, and the protocols, as you've mentioned earlier, emerge from the real-world objects, not the program objects built to parallel them, you really don't need said objects in your code whatsoever to represent the protocols and behaviour of a real-world system.

Add to that a mechanism to store subroutines in variables and data structures, and you can easily write code in an object-oriented way with just those basic building blocks, as languages like Lua or early JavaScript have shown.

Collapse
 
mcsee profile image
Maxi Contieri

Changed! Thank you very much!