¿Cuándo debo crear un servicio o una función de utilidad?

Tuve esta pregunta en mente durante toda la última semana: ¿Cuándo debería crear un servicio o una función de utilidad?

En Drupal Core tenemos funciones tanto de Servicios como de Utilidades, pero no puedo encontrar la distinción entre ellas (cuando necesito crear un servicio o cuando necesito crear una función de utilidad).

Tomaré como ejemplo el módulo Módulos Peso donde tengo la clase 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;
  }

}

En esta clase tengo dos funciones estáticas, pero ambas son funciones de utilidad o prepareDelta()es una función de utilidad y modulesList()deberían estar en otra clase y tener un servicio.

La única diferencia que encontré en este momento es que dentro del espacio de nombres Drupal \ Component \ Utility (donde verá muchas funciones de utilidad) ninguno de ellos usa dentro de un servicio y generalmente un servicio usa otros servicios dentro (no revise todos los servicios para validar esto).

Entonces, ¿cuándo debo crear un servicio o una función de utilidad?

En general servicios de uso. Consulte la siguiente publicación de blog cuando esté bien usar funciones de utilidad estáticas:

Entonces, ¿nunca usas estática?

Pues no, hay casos de uso válidos. Una es que si tiene una lista de elementos estáticos predefinidos puede ayudar a reducir la memoria, ya que estará en el nivel de clase y no en ningún caso.

Otros casos son métodos de utilidad que no requieren dependencias externas, por ejemplo, un método slugify.

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

El método slug solo tiene un comportamiento muy bien definido. Es fácil tener en cuenta el comportamiento en las pruebas unitarias y no me preocuparía demasiado cuando vea esta llamada.

Estos métodos pueden incluso probarse en unidades, ya que no requieren inicialización.

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

(La cantidad de código estático ahora en Drupal se debe a la transición del código de procedimiento D7, así que no use Drupal en el estado actual como ejemplo).

Sobre el ejemplo de la pregunta, el resto de la clase de utilidad (no se muestra en la pregunta)

<?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;
  }

}

llama al servicio propio del módulo en un contenedor estático:

\Drupal::service('modules_weight')

Esto probablemente se deba a que la clase de utilidad se usa en código de procedimiento heredado. En el código OOP esto no es necesario, aquí debe inyectar el servicio directamente.

Ken Rickard del canal #contribute de Slack Drupal dice: "Crearía un servicio si espera que otros módulos (u otros desarrolladores) interactúen con ese código. Los métodos de utilidad son solo atajos privados para usted".

Sí, lo bueno de los servicios es que cualquiera puede sobrescribirlos. Entonces, si desea dar a otras personas la capacidad de personalizar un fragmento de código en particular. Consulte Alteración de servicios existentes, prestación de servicios dinámicos .

Además, debe hacer que sea un servicio si necesita hacer una prueba simulada para pruebas de unidad PHP. Consulte Servicios e inyección de dependencias en Drupal 8 , consulte Unidad de prueba de clases de Drupal más complicadas .

Q & A:

Prueba de unidad de servicio

Escribir pruebas unitarias para un método que llama a métodos estáticos de otra clase