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
Break your 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() { }
}
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() { }
}
Detection
[X] Automatic
Most linters count methods and warn us.
Relations
More info
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)
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.
Hi
Objects have protocols and behavior
Subroutines don't.
This is another Code Smell called 'Helpers'
This sentence has more flaws than words and that's kind of impressive.
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.
So you don't use methods on your objects?
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
So the contract and the behaviour originate in the real world and manifest themselves in subroutines; then what do we need objects for?
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
What is (wrong with) software
Maxi Contieri ・ Oct 8 '20 ・ 4 min read
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
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.
Changed! Thank you very much!