Timeline for When should I create a service or a utility function?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 16, 2018 at 7:01 | history | edited | avpaderno♦ |
edited tags
|
|
| Nov 30, 2017 at 16:26 | vote | accept | Adrian Cid Almaguer | ||
| Nov 29, 2017 at 7:53 | answer | added | 4uk4 | timeline score: 8 | |
| Nov 29, 2017 at 1:03 | history | edited | No Sssweat | CC BY-SA 3.0 |
edited title
|
| Nov 28, 2017 at 20:18 | comment | added | Clive♦ |
@NoSssweat But Unicode is a Drupal class that contains only static methods! The fact that the core devs chose to implement it as a static class, rather than a service, probably means something don't you think? A utility class doesn't really need to be overwritten, by its nature - it does some things, if those things aren't what you want, you write your own class instead. Remember the sort of things that traditionally live in utility classes are one-shot, "I do this and nothing else" types of methods, that don't need input except a set of parameters
|
|
| Nov 28, 2017 at 20:16 | comment | added | No Sssweat |
@Clive it doesn't really need to be. One could argue it's the "Drupal way". Also, making it a service makes it easier for other devs to find what you can overwrite.
|
|
| Nov 28, 2017 at 20:11 | comment | added | Clive♦ |
As such, I would create a service if you expect other modules (or other developers) to interact with that code doesn't ring true to me. If that were the case, Unicode would be a service by design, and it doesn't really need to be. Don't forget utility classes can just as easily, more easily in some respects, be used by other modules and other code in your own module. But that all depends on your own perspective/experience as a developer, it'll mostly come down to common sense learnt the hard way
|
|
| Nov 28, 2017 at 20:07 | comment | added | Clive♦ |
I think a lot of it comes down to what the class does, and what it needs to have made available to it in order to operate. Take the Unicode class in core - that's a static utility class, not a service, because it doesn't have any dependencies, and doesn't need to maintain any state. If it required a service dependency, the DI pattern would require it to be converted to a service, and you'd use the singleton (or factory-generated) instance from the container when you needed it. Otherwise you can just use the static class it when it makes sense.
|
|
| Nov 28, 2017 at 19:49 | history | tweeted | twitter.com/StackDrupal/status/935596652139896832 | ||
| Nov 28, 2017 at 19:20 | answer | added | No Sssweat | timeline score: 11 | |
| Nov 28, 2017 at 19:05 | history | edited | No Sssweat | CC BY-SA 3.0 |
edited body
|
| Nov 28, 2017 at 18:54 | comment | added | Adrian Cid Almaguer | That's what I was thinking about Utility methods, but for services sometimes I think that is more a consideration. | |
| Nov 28, 2017 at 18:52 | comment | added | Adrian Cid Almaguer | Ken Rickard from Slack Drupal #contribute channel says: "I would create a service if you expect other modules (or other developers) to interact with that code. Utility methods are just private shortcuts for yourself." | |
| Nov 28, 2017 at 18:20 | history | asked | Adrian Cid Almaguer | CC BY-SA 3.0 |