So to answer his own question, yes he's doing OOP the wrong way. The advice he's given is actually really good if you want to learn how to think with objects, a

So to answer his own question, yes he's doing OOP the wrong way. The advice he's given is actually really good if you want to learn how to think with objects, any "actionable" name like Helper or Fetcher implies that there's a behavior mismatch somewhere and you should refactor so that you're back to Objects doing their thing. For the sake of the blog post, he should have refactored APIHelper to be something like ExternalApi, where it and it alone knows about how to fetch and how it's implemented. Then it's super simple to refactor ExternalApi's internals to be async instead of sync, but now he's got another object strictly dependent on the internal workings of another object, and will have trouble in the future. The fact that he instead built an async wrapper around a sync call shows that he doesn't understand OOP and is himself stuck in procedural land with objects. This article should be titled "How I threw away some of the best OOP advice I've ever been given".