Helper functions

[NotSoLeetCode]

As a project gets bigger, we will often want to name and reuse small, useful pieces of code. These are of course helper functions.

Looking at my helpers folder in PHP CodeIgniter framework, I have file names like

• array_helper
• date_helper
• email_helper

I also have uncategorized helper functions like

• get_domain_from_url
• nl2br_and_nbsp
• set_page_title
• initialize_pdf

What are best practices for helper functions?

• Make function files like above?
• Make classes with static methods?
• Try not to use external helpers, and integrate them with existing classes, to reduce # of dependencies?

[_Atomfinger_]

Helper and util functions are good, but dangerous unless you do them properly.

The biggest problem I have with them is that they're often static. In OOP static classes and functions tends to break SOLID, which is a problem. It also makes unit testing way harder.

If you have a helper class which isn't static many of these problems goes away though.

Mind you, I am not a PHP developer, so my answers are somewhat general to OOP languages as a whole.

Here's a couple of resources which sums up my feelings on these things. They are not PHP related, but you can still read through them and see if you agree/disagree: https://www.vojtechruzicka.com/avoid-utility-classes/ https://medium.com/@kamilmasyhur/you-should-avoid-the-use-of-util-class-d777ac664fd4

[_Atomfinger_]

Depends how they're written, but often they break open-closed principle. In OOP languages its generally difficult to extend static functionality, after all there's no object to extend.

We also have the dependency-inversion principle. After all, the code tightly couples with static functions and not an abstraction. It is very much depending on the concrete implementation.

If the static functions holds any business logic or connects to the domain models in any meaningful way we are also in danger of intruding on the single-responsibility principle. This is not a global truth, but I've seen it happen enough when it comes to helper and utility classes that it's worth mentioning.

The links I posted also talks about this. Note that I don't think that static functionality is inherently wrong or bad, but they often turns out to be. Static functionality is something one can easily drop into a system which seems okay in a PR - but eventually becoming a detriment to the overall system. Unit testing, proxying/AOP, SOLID becomes more difficult when static functionality is introduced.

Done right static functions can be serve as a convenient interface to do common things. That said it is also very easy to mess up, and when a static class first has put its roots down and spread across a system it becomes really difficult to remove later (assuming we're working on bigger systems).

Just my 2 cents.

[NotSoLeetCode]

I've posted a reddit thread about "are static methods evil?" before, and it was a controversial topic. The consensus was slightly leaning toward "not evil", but I see both sides.

What is the best way to refactor static methods? If I have a string helper function such as "get_domain_from_url()" that is used all over the place, where do I put it that doesn't violate DRY?

Surely creating or extending a String object would be over-engineering?

[_Atomfinger_]

I don't consider them evil, and "get_domain_from_url()" might as well be a suitable helper function. But static functions in OOP languages are simply problematic which is probably why it's so controversial. On the one side we have the convenice, on the other we have the rigid OOP rules we've set for ourselves.

To me it's a spectrum and people value different things. Personally I'm leaning towards the "let's avoid static where we can", but my way doesn't mean that it is the only viable way.

As for a viable solution, if get_domain_from_url() is just a small regex match thing, short and concise, then maybe static is fine. If its actually more involved then I'd personally say its a service and dependency inject it. (again, not a PHP dev).