3 ms·
This is great! I can't help but feel there's also an opportunity in a sequel to allude to the all too common "invent arbitrary abstract base classes to keep my
by jlewallen 11y ago
This is great! I can't help but feel there's also an opportunity in a sequel to allude to the all too common "invent arbitrary abstract base classes to keep my code DRY" anti-pattern.
- jdmichal 11y agoFor learning purposes for those reading this, what would you consider the alternative? I personally prefer just stuffing commonly used stuff into utility classes containing only public static functions. Makes them really easy to test, too.
- jlewallen 11y agoThanks for asking! My answer, of course, depends on the particular scenario. I've had success with simple static methods, especially early in a project. I'd also consider some kind of composition (has-a vs is-a). The latter can be especially nice as static methods gain complexity in the form of more parameters/variations. This also shines if there's meaningful alternative implementations that can be swapped or if you're writing business logic and some legitimate business concepts start to congeal out of the code being re-used.