मुझे सेवा या उपयोगिता फ़ंक्शन कब बनाना चाहिए?

Question

मेरे मन में यह सवाल पिछले हफ्ते भर से था: मुझे सेवा या उपयोगिता समारोह कब बनाना चाहिए?

Drupal Core में हमारे पास दोनों सेवाएँ और उपयोगिता फ़ंक्शंस हैं, लेकिन मैं उनके बीच अंतर नहीं खोज सकता (जब मुझे एक सेवा बनाने की आवश्यकता होती है या जब मुझे एक उपयोगिता फ़ंक्शन बनाने की आवश्यकता होती है)।

मैं उदाहरण के तौर पर मॉडल्स वेट मॉड्यूल ले जाऊंगा, जहां मेरे पास इंटरनल एफक्शन क्लास है।

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

}

इस वर्ग में मेरे दो स्थिर कार्य हैं लेकिन वे दोनों उपयोगिता कार्य हैं या prepareDelta()एक उपयोगिता कार्य है और modulesList()दूसरी कक्षा में होना चाहिए और एक सेवा होनी चाहिए?

इस समय मुझे जो एकमात्र अंतर मिला वह यह है कि नेमस्पेस Drupal \ Component \ उपयोगिता के अंदर (जहाँ आपको बहुत सारी उपयोगिताएँ fucntions दिखाई देंगी) उनमें से कोई भी एक सेवा के अंदर उपयोग नहीं करता है और आमतौर पर एक सेवा अंदर अन्य सेवाओं का उपयोग करती है (मैं नहीं। इसे सत्यापित करने के लिए सभी सेवाओं की समीक्षा करें)।

तो, मुझे एक सेवा या एक उपयोगिता समारोह कब बनाना चाहिए?

Comments

स्लैक ड्रुपल # कॉन्ट्रिब्यूट चैनल के केन रिकार्ड कहते हैं: "यदि आप अन्य मॉड्यूल (या अन्य डेवलपर्स) से उस कोड के साथ बातचीत करने की अपेक्षा करते हैं तो मैं एक सेवा तैयार करूंगा। यूटिलिटी के तरीके सिर्फ अपने लिए निजी शॉर्टकट हैं।"

— एड्रियन सीआईडी ​​अल्मागुएर

यही मैं उपयोगिता के तरीकों के बारे में सोच रहा था, लेकिन सेवाओं के लिए कभी-कभी मुझे लगता है कि यह एक विचार है।

— एड्रियन सीआईडी ​​अल्मागुएर

मुझे लगता है कि यह बहुत कुछ नीचे आता है जो वर्ग करता है, और इसे संचालित करने के लिए इसे क्या उपलब्ध कराने की आवश्यकता है। Unicodeकक्षा को मूल में लें - यह एक स्थिर उपयोगिता वर्ग है, सेवा नहीं, क्योंकि इसकी कोई निर्भरता नहीं है, और किसी भी राज्य को बनाए रखने की आवश्यकता नहीं है। यदि इसे सेवा निर्भरता की आवश्यकता होती है, तो DI पैटर्न को सेवा में परिवर्तित करने की आवश्यकता होती है, और जब आपको इसकी आवश्यकता होती है तो आप कंटेनर से सिंगलटन (या फ़ैक्ट्री-जनरेटेड) उदाहरण का उपयोग करेंगे। अन्यथा useजब आप समझ में आता है तो आप इसे केवल स्थिर वर्ग बना सकते हैं।

— क्लाइव

जैसे, यदि आप अन्य मॉड्यूल (या अन्य डेवलपर्स) से अपेक्षा करते हैं कि मैं उस कोड के साथ बातचीत करने के लिए एक सेवा बनाऊंगा तो मेरे लिए सही नहीं होगा। यदि ऐसा Unicodeहोता , तो डिजाइन द्वारा एक सेवा होगी, और यह वास्तव में होने की आवश्यकता नहीं है। उपयोगिता वर्ग को मत भूलो, आसानी से और अधिक आसानी से, कुछ मामलों में, अपने मॉड्यूल में अन्य मॉड्यूल और अन्य कोड द्वारा उपयोग किया जा सकता है। लेकिन इनके अलावा अपने स्वयं के परिप्रेक्ष्य / एक डेवलपर के रूप में अनुभव पर निर्भर करता है, यह ज्यादातर नीचे सामान्य ज्ञान के लिए आया हूँ मुश्किल तरीके से सीखा

— क्लाइव

@NoSssweat लेकिन Unicode है एक Drupal वर्ग है कि केवल स्थिर तरीकों शामिल हैं! तथ्य यह है कि कोर देवों ने इसे एक स्थिर वर्ग के रूप में लागू करने के लिए चुना था, बजाय एक सेवा के, शायद इसका मतलब है कि आपको कुछ नहीं लगता है? एक उपयोगिता वर्ग को वास्तव में अपने स्वभाव से, अधिलेखित होने की आवश्यकता नहीं है - यह कुछ चीजें करता है, यदि वे चीजें नहीं हैं जो आप चाहते हैं, तो आप इसके बजाय अपनी कक्षा लिखते हैं। चीजें हैं जो पारंपरिक रूप से उपयोगिता कक्षाओं में रहते एक शॉट हैं की तरह याद रखें, तरीकों के प्रकार, कि मानकों का एक सेट को छोड़कर इनपुट की जरूरत नहीं है "मैं इस और कुछ नहीं करते हैं"

— क्लाइव

Answer 1

सामान्य उपयोग सेवाओं में। जब स्थिर उपयोगिता फ़ंक्शंस का उपयोग करना ठीक हो तो निम्न ब्लॉग पोस्ट देखें:

तो कभी स्थैतिक का उपयोग न करें?

खैर नहीं, वैध उपयोग के मामले हैं। एक यह है कि यदि आपके पास पूर्व परिभाषित वस्तुओं की सूची है तो स्थिर मेमोरी को कम करने में मदद कर सकती है क्योंकि यह कक्षा के स्तर पर होगी और किसी भी उदाहरण में नहीं।

अन्य मामले उपयोगिता विधियां हैं, जिनके लिए बाहर की निर्भरता की आवश्यकता नहीं होती है, उदाहरण के लिए एक सुस्त विधि।

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

स्लग विधि केवल बहुत अच्छी तरह से परिभाषित व्यवहार करती है। यूनिट परीक्षणों में व्यवहार को ध्यान में रखना आसान है और जब मैं इस कॉल को देखता हूं तो मुझे बहुत चिंता नहीं होगी।

इन विधियों को इकाई परीक्षण भी किया जा सकता है क्योंकि उन्हें आरंभीकरण की आवश्यकता नहीं होती है।

स्रोत: https://stovepipe.systems/post/avoiding-static-in-your-code

(अब Drupal में स्थिर कोड की मात्रा प्रक्रियात्मक D7 कोड से संक्रमण के कारण है, इसलिए वर्तमान स्थिति में Drupal का उपयोग उदाहरण के रूप में न करें।)

---

प्रश्न से उदाहरण के बारे में, उपयोगिता वर्ग के बाकी (प्रश्न में नहीं दिखाया गया है)

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

}

स्थिर आवरण में मॉड्यूल को स्वयं सेवा कहते हैं:

\Drupal::service('modules_weight')

यह शायद इसलिए है क्योंकि उपयोगिता वर्ग का उपयोग विरासत प्रक्रियात्मक कोड में किया जाता है। OOP कोड में यह आवश्यक नहीं है, यहां आपको सीधे सेवा को इंजेक्ट करना चाहिए।

Comments

उत्तर के लिए धन्यवाद, कल मैंने थोड़ा मॉड्यूल कोड बदल दिया (क्योंकि मैंने कुछ कमिट किए) और मैं मॉड्यूल_वेट सेवा बनाता हूं। मेरे पास सेवा है क्योंकि यह दूसरों के मॉड्यूल द्वारा उपयोग किया जा सकता है और अब सामान्य है, आप सभी मॉड्यूल या केवल मुख्य मॉड्यूल सूची प्राप्त कर सकते हैं। लेकिन मॉड्यूल में यह सूची show_system_modules कॉन्फ़िग चर के अंदर मान से प्रभावित हो सकती है, इसलिए मैंने एक और फ़ंक्शन बनाया जो इस संस्करण को लेता है और फिर सेवाओं को कॉल करता है, लेकिन आपके उत्तर को पढ़कर ऐसा लगता है कि मॉड्यूललिस्ट फ़ंक्शन स्थिर नहीं होना चाहिए।

— एड्रियन सीआईडी ​​अल्मागुएर

इस मामले में क्या आप बात करते हैं कि मॉड्यूललिस्ट फ़ंक्शन सेवा के अंदर होना चाहिए या निर्भरता इंजेक्शन के साथ एक निर्माता के साथ किसी अन्य वर्ग पर होना चाहिए?

— एड्रियन सिड अल्मागुएर

मुझे लगता है कि आप इसे एक ही सेवा में रख सकते हैं और getModulesList () को संरक्षित विधि घोषित कर सकते हैं।

— 4k4

लेकिन मुद्दा यह है कि अगर कोई getModuleList () का उपयोग करना चाहता है और संभव नहीं होगा और मॉड्यूलिस्ट () के पास एक वैरिएबल तक पहुंच है जो केवल मॉड्यूल के लिए महत्वपूर्ण है। शायद मॉड्यूललिस्ट () को एक अन्य विधि के रूप में जोड़ना और विवरण में जोड़ना जो मॉड्यूल कॉन्फ़िगरेशन चर का उपयोग करते हैं?

— एड्रियन सीआईडी ​​अल्मागुएर

मैं केवल दो विधियों में से एक को सार्वजनिक करूंगा। शायद आप एक डिफ़ॉल्ट मान सेट कर सकते हैं $force = NULL, ताकि आप जान सकें कि क्या कोई FALSE के साथ कॉन्फिगर वैल्यू को ओवरराइड करना चाहता है।

— 4k4

Answer 2

स्लैक ड्रुपल # कॉन्ट्रिब्यूट चैनल के केन रिकार्ड कहते हैं: "यदि आप अन्य मॉड्यूल (या अन्य डेवलपर्स) से उस कोड के साथ बातचीत करने की अपेक्षा करते हैं तो मैं एक सेवा तैयार करूंगा। यूटिलिटी के तरीके सिर्फ अपने लिए निजी शॉर्टकट हैं।"

हां, सेवाओं के बारे में एक अच्छी बात यह है कि कोई भी उन्हें अधिलेखित कर सकता है। इसलिए यदि आप अन्य लोगों को एक विशेष कोड कोड को अनुकूलित करने की क्षमता देना चाहते हैं। मौजूदा सेवाओं को बदलना, गतिशील सेवाएं प्रदान करना देखें ।

इसके अलावा, यदि आप PHP इकाई परीक्षण के लिए मॉक टेस्ट करने की आवश्यकता है, तो आपको इसे एक सेवा बना देना चाहिए। देखें Drupal 8 में सेवा और निर्भरता इंजेक्शन , देख यूनिट अधिक जटिल Drupal कक्षाओं का परीक्षण ।

प्रश्नोत्तर:

सेवा इकाई परीक्षण

किसी अन्य वर्ग से स्थिर विधियों को कॉल करने वाली विधि के लिए लेखन इकाई परीक्षण

Comments

धन्यवाद, क्या आपके पास अपने उत्तर में जोड़ने के लिए कुछ संदर्भ हैं?

— एड्रियन सिड अल्मागुएर

@AdrianCidAlmaguer गयी।

— कोई Sssweat

धन्यवाद, अब यह संदर्भ अन्य उपयोगकर्ताओं (और मुझे भी) की मदद कर सकता है ;-)

— एड्रियन सीआईडी ​​अल्मागुएर

आपको एक ऐसी सेवा का निर्माण करना चाहिए, यदि यह कुछ ऐसा है जिसे आप स्वयं अपने मॉड्यूल की विभिन्न फाइलों में फिर से उपयोग करते हुए देखते हैं। एक उपयोगिता वर्ग में एक सेवा क्यों अधिक उपयोगी (या बेहतर अभ्यास) होगी जो एक ही मॉड्यूल में कई बार उपयोग की जाती है? (स्पष्ट करने के लिए: मैं उनका तर्क है नहीं कर रहा हूँ, लेकिन वहाँ इस संदर्भ में विशेष रूप में किसी भी अंतर हो प्रतीत नहीं होता है तुम क्यों लगता है कि एक सेवा अधिक समझ में आता है मैं यह जानकर प्रसन्नता होगी।)

— क्लाइव

हाँ, यह एक दिलचस्प @NoSssweat है। IMO यह Drupal या Symfony की तुलना में उच्च-स्तरीय सिद्धांतों द्वारा निर्देशित है। मैं आप अपने कोड के लिए अच्छा है, मानक, वर्ग डिजाइन लागू लगता है, और उसके बाद में परिणाम जो भी ढांचा आप जो कुछ भी विधि है कि वर्ग के लिए समझ में आता है से समय का उपयोग कर रहे स्लॉट

— क्लाइव