আমি কখন কোন পরিষেবা বা ইউটিলিটি ফাংশন তৈরি করব?


11

সর্বশেষ সপ্তাহে আমার মনে এই প্রশ্নটি ছিল: কখন আমার কোনও পরিষেবা বা কোনও ইউটিলিটি ফাংশন তৈরি করা উচিত?

ড্রুপাল কোরটিতে আমাদের পরিষেবা এবং ইউটিলিটি উভয়ই ফাংশন রয়েছে তবে আমি তাদের মধ্যে পার্থক্যটি খুঁজে পাচ্ছি না (যখন আমাকে কোনও পরিষেবা তৈরি করার প্রয়োজন হয় বা যখন আমার কোনও ইউটিলিটি ফাংশন তৈরি করার প্রয়োজন হয়)।

আমি উদাহরণস্বরূপ মডিউলগুলির ওজন মডিউলটি গ্রহণ করব যেখানে আমার অভ্যন্তরীণ ফাংশন ক্লাস রয়েছে।

<?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()অন্য ক্লাসে থাকতে হবে এবং একটি পরিষেবা থাকতে হবে?

এই সময়ে আমি যে পার্থক্যটি পেয়েছি তা হ'ল নেমস্পেসের ভিতরে দ্রুপাল \ উপাদান \ ইউটিলিটি (যেখানে আপনি অনেকগুলি ইউটিলিটি ফিকশন দেখতে পাবেন) তাদের কোনওটিই কোনও পরিষেবার অভ্যন্তরে ব্যবহার করে না এবং সাধারণত একটি পরিষেবা ভিতরে অন্য পরিষেবা ব্যবহার করে (আমি না এটি যাচাই করতে সমস্ত পরিষেবা পর্যালোচনা করুন)।

সুতরাং, যখন আমার কোনও পরিষেবা বা কোনও ইউটিলিটি ফাংশন তৈরি করা উচিত?


স্ল্যাক ড্রুপাল # কন্ট্রিবিউট চ্যানেল থেকে কেন রিকার্ড বলেছেন: "আপনি যদি অন্য মডিউলগুলি (বা অন্যান্য বিকাশকারীগণ) সেই কোডটির সাথে যোগাযোগের প্রত্যাশা করেন তবে আমি একটি পরিষেবা তৈরি করব U ইউটিলিটি পদ্ধতিগুলি কেবল নিজের জন্য ব্যক্তিগত শর্টকাট" "
অ্যাড্রিয়ান সিড

এটিই আমি ইউটিলিটি পদ্ধতি সম্পর্কে ভাবছিলাম, তবে পরিষেবাগুলির জন্য মাঝে মাঝে আমি এটি আরও বিবেচ্য বলে মনে করি।
অ্যাড্রিয়ান সিড

আমি মনে করি এটির অনেক কিছুই ক্লাসটি কী করে এবং এটি পরিচালনা করার জন্য এটির কাছে কী সরবরাহ করা দরকার তা নেমে আসে। ক্লাসটিকে Unicodeমূল হিসাবে নিন - এটি একটি স্ট্যাটিক ইউটিলিটি ক্লাস, কোনও পরিষেবা নয়, কারণ এটির কোনও নির্ভরতা নেই এবং কোনও রাষ্ট্র বজায় রাখার প্রয়োজন নেই। যদি এটির কোনও পরিষেবা নির্ভরতা প্রয়োজন, ডিআই প্যাটার্নটির প্রয়োজন হয় এটি একটি পরিষেবাতে রূপান্তরিত করা, এবং আপনি যখন প্রয়োজন হবে তখন আপনি ধারকটি থেকে সিঙ্গলটন (বা কারখানা-উত্পাদিত) উদাহরণটি ব্যবহার করবেন। অন্যথায় আপনি useএটি স্থির শ্রেণি করতে পারেন যখন এটি বোধগম্য হয়।
ক্লাইভ

এই হিসাবে, যদি আপনি অন্যান্য মডিউলগুলি (বা অন্যান্য বিকাশকারী) কোডটির সাথে ইন্টারঅ্যাক্ট করতে আশা করেন তবে আমার কাছে পরিষেবাটি তৈরি হবে । যদি এটি হয় তবে Unicodeডিজাইনের ভিত্তিতে একটি পরিষেবা হবে এবং এটি আসলে হওয়ার দরকার নেই। ইউটিলিটি ক্লাসগুলি সহজেই, কিছু ক্ষেত্রে আরও সহজেই, নিজের মডিউলে অন্য মডিউল এবং অন্যান্য কোড ব্যবহার করতে পারে তা ভুলে যাবেন না। তবে এগুলি সমস্ত বিকাশকারী হিসাবে আপনার নিজস্ব দৃষ্টিভঙ্গি / অভিজ্ঞতার উপর নির্ভর করে, এটি বেশিরভাগই সাধারণ জ্ঞানটিতে নেমে আসবে কঠোর উপায়ে
ক্লাইভ

2
@ নো এসওয়েট তবে Unicode এটি একটি দ্রুপাল শ্রেণি যেখানে কেবল স্থির পদ্ধতি রয়েছে! মূল ডেভস কোনও পরিষেবা না দিয়ে স্থিতিশীল শ্রেণি হিসাবে এটি প্রয়োগ করার সিদ্ধান্ত নিয়েছে, সম্ভবত এমন কিছু অর্থ যা আপনি ভাবেন না? একটি ইউটিলিটি ক্লাসটি প্রকৃতপক্ষে প্রকৃতরূপে লেখার দরকার নেই - এটি কিছু জিনিস করে, যদি সেই জিনিসগুলি আপনি যা চান তা না করে আপনি তার পরিবর্তে নিজের ক্লাসটি লেখেন। Rememberতিহ্যগতভাবে ইউটিলিটি ক্লাসে যে ধরণের জিনিসগুলি থাকে সেগুলি মনে রাখবেন, "আমি এটি করি এবং কিছুই করি না" ধরণের পদ্ধতি, যা প্যারামিটারের একটি সেট ছাড়া ইনপুট লাগবে না
ক্লাইভ

উত্তর:


6

সাধারণ ব্যবহারের পরিষেবাগুলিতে। স্থিতিশীল ইউটিলিটি ফাংশন ব্যবহার করা ঠিক হবে যখন নিম্নলিখিত ব্লগ পোস্টটি দেখুন:

তাহলে কখনও স্ট্যাটিক ব্যবহার করবেন না?

ভাল না, সেখানে বৈধ ব্যবহারের কেস রয়েছে। একটি হ'ল যদি আপনার কাছে পূর্বনির্ধারিত আইটেমগুলির একটি তালিকা থাকে তবে স্ট্যাটিক স্মৃতি হ্রাস করতে সহায়তা করতে পারে কারণ এটি শ্রেণীর স্তরে হবে এবং কোনও ক্ষেত্রেই নয়।

অন্যান্য ক্ষেত্রে ইউটিলিটি পদ্ধতি যা বাইরের নির্ভরতার প্রয়োজন হয় না, উদাহরণস্বরূপ একটি স্লুগাইফ পদ্ধতি।

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

স্লাগ পদ্ধতিটি একটি খুব ভাল সংজ্ঞায়িত আচরণ করে। ইউনিট পরীক্ষায় আচরণটি অ্যাকাউন্টে নেওয়া সহজ এবং আমি যখন এই কলটি দেখি তখন খুব বেশি চিন্তিত হই না।

এই পদ্ধতিগুলি এমনকি ইউনিট পরীক্ষিত হতে পারে যেহেতু তাদের আরম্ভের প্রয়োজন হয় না।

উত্স: https://stovepipe.systems/post/avoider-static-in-your-code

(দ্রুপালে এখন স্ট্যাটিক কোডের পরিমাণ প্রক্রিয়াগত ডি 7 কোড থেকে পরিবর্তনের কারণ, সুতরাং বর্তমান অবস্থায় দ্রুপালকে ব্যবহার করবেন না))


প্রশ্ন থেকে উদাহরণ সম্পর্কে, বাকি ইউটিলিটি ক্লাস (প্রশ্নে দেখানো হয়নি)

<?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')

এটি সম্ভবত কারণ ইউটিলিটি ক্লাসটি উত্তরাধিকারের পদ্ধতিগত কোডে ব্যবহৃত হয়। ওওপি কোডে এটি প্রয়োজনীয় নয়, এখানে আপনার সরাসরি পরিষেবাটি ইনজেক্ট করা উচিত।


উত্তরের জন্য ধন্যবাদ, গতকাল আমি মডিউল কোডটি কিছুটা পরিবর্তন করেছি (কারণ আমি কিছু কমিট করেছি) এবং আমি মডিউল_ওয়েট পরিষেবা তৈরি করি। আমার পরিষেবা আছে কারণ এটি অন্যদের মডিউলগুলি ব্যবহার করতে পারে এবং এখন সাধারণ, আপনি সমস্ত মডিউল বা কেবল মূল মডিউলগুলির তালিকা পেতে পারেন। তবে মডিউলে এই তালিকাটি show_system_modules কনফিগার ভেরিয়েবলের অভ্যন্তরের মান দ্বারা প্রভাবিত হতে পারে, তাই আমি আরও একটি ফাংশন তৈরি করেছি যা এই varটি গ্রহণ করে এবং তারপরে পরিষেবাগুলিকে কল করে, তবে আপনার উত্তরটি পড়লে মনে হয় মডিউলগুলি তালিকা ফাংশনটি স্থির হওয়া উচিত নয়।
অ্যাড্রিয়ান সিড

এই ক্ষেত্রে আপনি কি জিনিসটি করেন যে মডিউললিস্টের ফাংশনটি পরিষেবার ভিতরে থাকা উচিত বা নির্ভরতা ইঞ্জেকশন সহ কোনও নির্মাণকারীর সাথে অন্য কোনও শ্রেণিতে থাকতে হবে?
অ্যাড্রিয়ান সিড

আমি মনে করি আপনি এটি একই পরিষেবাতে রাখতে পারেন এবং getModulesList () কে সুরক্ষিত পদ্ধতি হিসাবে ঘোষণা করতে পারেন।
4k4

তবে মুল বক্তব্যটি হ'ল যদি কেউ getModuleList () ব্যবহার করতে চায় তবে সম্ভব হবে না এবং মডিউললিস্টে () একটি পরিবর্তনশীল অ্যাক্সেস করতে পারে যা কেবলমাত্র মডিউলটির জন্য গুরুত্বপূর্ণ। হতে পারে অন্য পদ্ধতি হিসাবে মডিউললিস্ট () যোগ এবং বর্ণনায় মডিউল কনফিগার ভেরিয়েবল ব্যবহার?
অ্যাড্রিয়ান সিড

আমি দুটি পদ্ধতির মধ্যে কেবল একটিতে পাবলিক করব। সম্ভবত আপনি একটি ডিফল্ট মান সেট করতে পারেন $force = NULL, যাতে আপনি জানেন যে কেউ কোনও FALSE দিয়ে কনফিগার মানকে ওভাররাইড করতে চায় কিনা।
4k4

8

স্ল্যাক ড্রুপাল # কন্ট্রিবিউট চ্যানেল থেকে কেন রিকার্ড বলেছেন: "আপনি যদি অন্য মডিউলগুলি (বা অন্যান্য বিকাশকারীগণ) সেই কোডটির সাথে যোগাযোগের প্রত্যাশা করেন তবে আমি একটি পরিষেবা তৈরি করব U ইউটিলিটি পদ্ধতিগুলি কেবল নিজের জন্য ব্যক্তিগত শর্টকাট" "

হ্যাঁ, পরিষেবাদি সম্পর্কে একটি দুর্দান্ত জিনিস হ'ল যে কেউ সেগুলি ওভাররাইট করতে পারে। সুতরাং আপনি যদি অন্য লোককে কোডের একটি নির্দিষ্ট অংশকে কাস্টমাইজ করার ক্ষমতা দিতে চান। গতিশীল পরিষেবাদি সরবরাহ করে, বিদ্যমান পরিষেবাদিগুলির পরিবর্তন করা দেখুন ।

এছাড়াও, পিএইচপি ইউনিট পরীক্ষার জন্য আপনার যদি মক টেস্টের প্রয়োজন হয় তবে আপনার এটিকে পরিষেবা তৈরি করা উচিত। দেখুন Drupal এর 8 সার্ভিসেস অ্যান্ড নির্ভরতা ইনজেকশন দেখুন ইউনিট আরো জটিল Drupal এর ক্লাস পরীক্ষা

প্রশ্নোত্তর:

পরিষেবা ইউনিট পরীক্ষা

অন্য শ্রেণীর স্ট্যাটিক পদ্ধতিগুলিকে কল করে এমন পদ্ধতির জন্য লিখন ইউনিটের পরীক্ষা


ধন্যবাদ, আপনার উত্তরে যুক্ত করার জন্য আপনার কি কিছু রেফারেন্স রয়েছে?
অ্যাড্রিয়ান সিড

@AdrianCidAlmaguer যোগ করেছে
এসএসওয়েট

1
ধন্যবাদ, এখন এই রেফারেন্সগুলি অন্য ব্যবহারকারীদের (এবং আমিও) সহায়তা করতে পারে ;-)
অ্যাড্রিয়ান সিড আলমাগুয়ার

আপনার মডিউলের বিভিন্ন ফাইলগুলিতে নিজেকে আবার ব্যবহার করতে দেখাতে যদি এমন কোনও পরিষেবা তৈরি করা উচিত তবে কোনও পরিষেবাটি একই মডিউলে বেশ কয়েকবার ব্যবহৃত একটি ইউটিলিটি ক্লাস করার চেয়ে কেন বেশি কার্যকর (বা আরও ভাল অনুশীলন) হবে? (স্পষ্ট করে বলার জন্য: আমি তর্ক করছি না, তবে বিশেষত সেই প্রসঙ্গে কোনও পার্থক্য বলে মনে হচ্ছে না। আপনি কেন পরিষেবা আরও বেশি
ক্লাইভ

1
হ্যাঁ এটি একটি আকর্ষণীয় @ NoSssweat। আইএমও এটি দ্রুপাল বা সিমফোনির চেয়ে উচ্চ স্তরের নীতি দ্বারা পরিচালিত। আমি মনে করি আপনি আপনার কোডটিতে ভাল, মানক, শ্রেণি নকশা প্রয়োগ করেছেন এবং তারপরে আপনি যে কোনও কাঠামো ব্যবহার করছেন সেই ফলাফলটি যে শ্রেণীর জন্য বোধগম্য করে সেগুলি স্লট করুন
ক্লাইভ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.