Quando devo creare un servizio o una funzione di utilità?

Ho avuto questa domanda in mente per tutta l'ultima settimana: quando dovrei creare un servizio o una funzione di utilità?

Nel Drupal Core abbiamo entrambe le funzioni Servizi e Utilità, ma non riesco a trovare la distinzione tra loro (quando devo creare un servizio o quando devo creare una funzione di utilità).

Prenderò ad esempio il modulo Modules Weight in cui ho la classe InternalFunctions .

<?php

namespace Drupal\modules_weight\Utility;

class InternalFunctions {

  public static function prepareDelta($weight) {
    $delta = 100;

    $weight = (int) $weight;

    if ($weight > $delta) {
      return $weight;
    }

    if ($weight < -100) {
      return $weight * -1;
    }

    return $delta;
  }


  public static function modulesList($force = FALSE) {
    $modules = [];
    $installed_modules = system_get_info('module');

    $config_factory = \Drupal::service('config.factory');

    if ($force) {
      $show_system_modules = TRUE;
    }
    else {
modules.
      $show_system_modules = $config_factory->get('modules_weight.settings')->get('show_system_modules');
    }

    $modules_weight = $config_factory->get('core.extension')->get('module');

    foreach ($installed_modules as $filename => $module_info) {
      if (!isset($module_info['hidden']) && ($show_system_modules || $module_info['package'] != 'Core')) {
        $modules[$filename]['name'] = $module_info['name'];
        $modules[$filename]['description'] = $module_info['description'];
        $modules[$filename]['weight'] = $modules_weight[$filename];
        $modules[$filename]['package'] = $module_info['package'];
      }
    }
    uasort($modules, ['Drupal\Component\Utility\SortArray', 'sortByWeightElement']);

    return $modules;
  }

}

In questa classe ho due funzioni statiche ma sono entrambe funzioni di utilità o prepareDelta()è una funzione di utilità e modulesList()dovrebbe essere in un'altra classe e avere un servizio?

L'unica differenza che ho riscontrato in questo momento è che all'interno dello spazio dei nomi Drupal \ Component \ Utility (dove vedrai un sacco di programmi di utilità) nessuno di essi utilizza all'interno di un servizio e di solito un servizio utilizza altri servizi all'interno (io no rivedere tutti i servizi per convalidarlo).

Quindi, quando dovrei creare un servizio o una funzione di utilità?

In servizi di uso generale. Vedere il seguente post di blog quando è corretto utilizzare le funzioni dell'utilità statica:

Quindi non usare mai statico?

Bene no, ci sono casi d'uso validi. Uno è che se si dispone di un elenco di elementi predefiniti statici può aiutare a ridurre la memoria poiché sarà a livello di classe e non in nessun caso.

Altri casi sono metodi di utilità che non richiedono dipendenze esterne, ad esempio un metodo slugify.

<?php
class Util
{
    public static function slug($string)
    {
        return strtolower(trim(preg_replace('/[^A-Za-z0-9-]+/', '_', $string)));
    }
}

Il metodo slug ha solo un comportamento molto ben definito. È facile prendere in considerazione il comportamento nei test unitari e non sarei troppo preoccupato quando vedo questa chiamata.

Questi metodi possono anche essere testati in unità poiché non richiedono l'inizializzazione.

Fonte: https://stovepipe.systems/post/avoiding-static-in-your-code

(La quantità di codice statico ora in Drupal è dovuta alla transizione dal codice D7 procedurale, quindi non usare Drupal nello stato corrente come esempio.)

Sull'esempio della domanda, il resto della classe di utilità (non mostrato nella domanda)

<?php

namespace Drupal\modules_weight\Utility;

/**
 * Provides module internal helper methods.
 *
 * @ingroup utility
 */
class InternalFunctions {

...

  /**
   * Return the modules list ordered by the modules weight.
   *
   * @param bool $force
   *   Force to show the core modules.
   *
   * @return array
   *   The modules list.
   */
  public static function modulesList($force = FALSE) {
    // If we don't force we need to check the configuration variable.
    if (!$force) {
      // Getting the config to know if we should show or not the core modules.
      $force = \Drupal::service('config.factory')->get('modules_weight.settings')->get('show_system_modules');
    }
    // Getting the modules list.
    $modules = \Drupal::service('modules_weight')->getModulesList($force);

    return $modules;
  }

}

chiama il servizio del modulo in un wrapper statico:

\Drupal::service('modules_weight')

Ciò è probabilmente dovuto al fatto che la classe di utilità viene utilizzata nel codice procedurale legacy. Nel codice OOP questo non è necessario, qui è necessario iniettare direttamente il servizio.

Ken Rickard del canale #contribute di Slack Drupal dice: "Creerei un servizio se ti aspetti che altri moduli (o altri sviluppatori) interagiscano con quel codice. I metodi di utilità sono solo scorciatoie private per te".

Sì, una cosa interessante dei servizi è che chiunque può sovrascriverli. Quindi, se vuoi dare ad altre persone la possibilità di personalizzare un particolare pezzo di codice. Vedi Modifica di servizi esistenti, fornitura di servizi dinamici .

Inoltre, è necessario renderlo un servizio se è necessario eseguire un test di simulazione per il test dell'unità PHP. Vedi Servizi e iniezione di dipendenze in Drupal 8 , vedi Test unitari su classi Drupal più complicate .

Domande e risposte:

Test dell'unità di servizio

Scrittura di unit test per un metodo che chiama metodi statici da un'altra classe