getupkid

3y

The Rise and Fall of Helper Classes

New method doesn't seem to fit into one of the existing classes so a developer creates a new class and innocently called it "helper".

Another dev had a similar conundrum and adds a couple more methods to the "helper" class.

And a few more methods added...

A couple more methods surely wouldn't be too bad. It has unit tests anyway.

After a year, the helper class has now grown to about 10,000 lines that no one is brave enough to refactor.

CTO now says, "Ok let's park this project and build a new one in Go." Fun times!

devrant

superclass

Ranter

Comments

2

nitnip

1828

3y

Isn't that why everyone started adopting 'service' classes instead? To me helpers are like this very specific, tiny functions that are somewhere between just syntactic sugar and mildly useful.

For instance if you keep some form of currency like US dollars in your database as integer (cents of a dollar instead of a float value representing the dollars themselves), I'd have a function that just takes care of the money format.
3

saucyatom

2526

3y

Like @nitnip said, those helper functions should be tiny (often <10 LOC), concise and unit-tested. It is also advised to have different helper classes for different things (e.g. StringHelper, CurrencyHelper, XyzHelper, ...). If they're having thousands of methods, I'd say you're doing something wrong.

Refactoring shouldn't even be an issue there, as it's easy enough to create them in a very clear, structured way in the first place.

devRant © 2021 Hexical Labs LLC
Privacy Policy | Terms of Service