নির্ভরতা ইনজেকশন ব্যবহার করার সময় এক শ্রেণিতে কতগুলি ইঞ্জেকশন গ্রহণযোগ্য


9

আমি নির্ভরশীলতা ইনজেকশনের জন্য সি # তে ইউনিটি ব্যবহার করছি, তবে নির্ভরতা ইঞ্জেকশন ব্যবহার করে এমন কোনও ভাষা এবং কাঠামোর ক্ষেত্রে প্রশ্নটি প্রযোজ্য।

আমি সলিড-নীতি অনুসরণ করার চেষ্টা করছি এবং তাই আমি প্রচুর বিমূর্ততা পেয়েছি। তবে এখন আমি ভাবছি যে এক শ্রেণিতে কতগুলি ইঞ্জেকশন লাগানো উচিত তার জন্য সেরা অনুশীলন আছে?

উদাহরণস্বরূপ, আমার 9 টি ইনজেকশন সহ একটি সংগ্রহস্থল রয়েছে। এটি কি অন্য বিকাশকারীদের পক্ষে পড়া শক্ত হবে?

ইনজেকশনগুলির নিম্নলিখিত দায়িত্ব রয়েছে:

  • আইডিবি কনটেক্সটফ্যাক্টরি - ডাটাবেসের জন্য প্রসঙ্গ তৈরি করা।
  • আইএমপ্পার - সত্ত্বা থেকে ডোমেন মডেলগুলিতে ম্যাপিং।
  • আইকলক - ইউনিট পরীক্ষাগুলিতে সহায়তা করার জন্য তারিখের সময়টিকে বিমূর্ত করে দেয়।
  • আইফেরফরমেন্সফ্যাক্টরি - নির্দিষ্ট পদ্ধতির জন্য কার্যকরকরণের সময় পরিমাপ করে।
  • আইলগ - লগিংয়ের জন্য লগ 4 নেট।
  • আইকোলিকেশনআউপারফ্যাক্টরি - সংগ্রহ তৈরি করে (এটি আইনেউমারেবল প্রসারিত করে)।
  • আইকিউরিফিল্টারফ্যাক্টরি - ইনপুটের ভিত্তিতে ক্যোয়ারী উত্পন্ন করে যা ডিবিতে কোয়েরি করবে।
  • IIdentityHelper - লগ ইন করা ব্যবহারকারীকে পুনরুদ্ধার করে।
  • আইফল্ট ফ্যাক্টরি - বিভিন্ন ফল্ট এক্সেক্সশন তৈরি করুন (আমি ডাব্লুসিএফ ব্যবহার করি)।

আমি কীভাবে দায়িত্ব অর্পণ করেছি তাতে আমি সত্যিই হতাশ নই, তবে আমি পঠনযোগ্যতার জন্য উদ্বিগ্ন হতে শুরু করি।

সুতরাং, আমার প্রশ্নগুলি:

ক্লাসে কতগুলি ইঞ্জেকশন লাগানো উচিত তার কোনও সীমা রয়েছে? এবং যদি তা হয় তবে কীভাবে এড়ানো যায়?

অনেকগুলি ইনজেকশন পাঠযোগ্যতা সীমাবদ্ধ করে, বা এটি আসলে এটির উন্নতি করে?


2
সংখ্যা দ্বারা গুণমান পরিমাপ করা সাধারণত আপনি প্রতি মাসে লেখার কোডের লাইনের মাধ্যমে প্রদত্ত হিসাবে খারাপ। যাইহোক, আপনি নির্ভরতার প্রকৃত উদাহরণ অন্তর্ভুক্ত করেছেন, এটি একটি দুর্দান্ত ধারণা। আমি যদি আপনি হয় তবে গণনা এবং কঠোর সীমাবদ্ধতার ধারণাটি সরিয়ে ফেলতে এবং প্রতি সেটের মানের পরিবর্তে ফোকাস করতে আমি আপনার প্রশ্নের সংশোধন করব। এটি সংশোধন করার সময়, আপনার প্রশ্নটি খুব নির্দিষ্ট না করার জন্য সতর্ক হন।
আরসেনি মরজেনকো

3
কয়টি কনস্ট্রাক্টর আর্গুমেন্ট গ্রহণযোগ্য? আইওসি এটি পরিবর্তন করে না
টেলাস্টিন

কেন লোকেরা সর্বদা পরম সীমা চায়?
মার্জন ভেনেমা

1
@ টেলাস্টিন: অগত্যা নয়। আইওসি কী পরিবর্তন করে তা হ'ল স্ট্যাটিক ক্লাস / সিঙ্গেলন / গ্লোবাল ভেরিয়েবলের উপর নির্ভর করার পরিবর্তে সমস্ত নির্ভরতা আরও কেন্দ্রীভূত এবং আরও "দৃশ্যমান" হয়।
আর্সেনী মোরজেনকো

@ মারজানভেনেমা: কারণ এটি জীবনকে অনেক সহজ করে তুলেছে। আপনি যদি পদ্ধতি অনুসারে সর্বাধিক এলওসি বা কোনও শ্রেণিতে সর্বাধিক পদ্ধতির সংখ্যা বা কোনও পদ্ধতিতে সর্বাধিক সংখ্যক ভেরিয়েবলগুলি জানেন এবং এই একমাত্র বিষয়টি গুরুত্বপূর্ণ হয় তবে কোডটি ভাল বা খারাপ হিসাবে যোগ্যতা অর্জন করা সহজ হয়ে যায়, কারণ পাশাপাশি খারাপ কোডটি "ঠিক করুন"। এটি দুর্ভাগ্যজনক যে বাস্তব জীবন তার চেয়ে অনেক জটিল এবং অনেকগুলি মেট্রিক বেশিরভাগ অপ্রাসঙ্গিক।
আর্সেনী মোরজেনকো

উত্তর:


11

খুব বেশি নির্ভরতা ইঙ্গিত করতে পারে যে ক্লাস নিজেই খুব বেশি করছে। এটি খুব বেশি করে না করছে কিনা তা নির্ধারণ করার জন্য:

  • ক্লাস নিজেই দেখুন। এটিকে কি দুই, তিন, চার ভাগে ভাগ করে নেওয়া উচিত? এটি সামগ্রিকভাবে কি অর্থবোধ করে?

  • নির্ভরতার ধরণগুলি দেখুন। কোনটি ডোমেন-নির্দিষ্ট এবং কোনটি "গ্লোবাল"? উদাহরণস্বরূপ, আমি ILogএকই স্তরের হিসাবে বিবেচনা করব না IQueryFilterFactory: লগিং ব্যবহার করা হচ্ছে যদি প্রথম ব্যবসায় বেশিরভাগ ব্যবসায় ক্লাসে উপলব্ধ। অন্যদিকে, আপনি যদি ডোমেন-নির্দিষ্ট নির্ভরতা অনেক খুঁজে পান তবে এটি ইঙ্গিত করতে পারে যে ক্লাসটি খুব বেশি করছে।

  • নির্ভরতাগুলি দেখুন যা মানগুলি দ্বারা প্রতিস্থাপন করা যেতে পারে।

    আইকলক - ইউনিট পরীক্ষাগুলিতে সহায়তা করার জন্য তারিখের সময়টিকে বিমূর্ত করে দেয়।

    এটি সহজেই DateTime.Nowবর্তমান পদ্ধতিগুলি জানার জন্য প্রয়োজনীয় পদ্ধতিগুলিতে সরাসরি পাস করে প্রতিস্থাপন করা যেতে পারে ।

প্রকৃত নির্ভরতা দেখে, আমি এমন কিছু দেখতে পাচ্ছি না যা খারাপ জিনিসের ইঙ্গিত দেয়:

  • আইডিবি কনটেক্সটফ্যাক্টরি - ডাটাবেসের জন্য প্রসঙ্গ তৈরি করা।

    ঠিক আছে, আমরা সম্ভবত একটি ব্যবসায়িক স্তরের ভিতরে আছি যেখানে ক্লাসগুলি ডেটা অ্যাক্সেস স্তরটির সাথে ইন্টারঅ্যাক্ট করে। দেখতে ভাল.

  • আইএমপ্পার - সত্ত্বা থেকে ডোমেন মডেলগুলিতে ম্যাপিং।

    সামগ্রিক চিত্র ছাড়া কিছু বলা মুশকিল। এটি হতে পারে যে আর্কিটেকচারটি ভুল এবং ম্যাপিং সরাসরি ডেটা অ্যাক্সেস লেয়ারের মাধ্যমে করা উচিত, বা এটি সম্ভবত আর্কিটেকচার পুরোপুরি ঠিক আছে। সব ক্ষেত্রে, এখানে এই নির্ভরতা থাকা বোধগম্য হয়।

    আরেকটি পছন্দ হবে ক্লাসটিকে দুটি ভাগে ভাগ করা: একটি ম্যাপিংয়ের সাথে ডিল করা, অন্যটি প্রকৃত ব্যবসায়ের যুক্তি নিয়ে কাজ করা। এটি একটি ডি ফ্যাক্টো স্তর তৈরি করবে যা ডাল থেকে বিএলকে আরও আলাদা করবে। ম্যাপিংগুলি জটিল হলে এটি একটি ভাল ধারণা হতে পারে। যদিও বেশিরভাগ ক্ষেত্রে এটি কেবল অকেজো জটিলতা যুক্ত করবে।

  • আইকলক - ইউনিট পরীক্ষাগুলিতে সহায়তা করার জন্য তারিখের সময়টিকে বিমূর্ত করে দেয়।

    কেবলমাত্র বর্তমান সময়টি পেতে আলাদা ইন্টারফেস (এবং শ্রেণি) পাওয়া খুব সম্ভবত কার্যকর নয়। আমি কেবল DateTime.Nowবর্তমান পদ্ধতিগুলির জন্য প্রয়োজনীয় পদ্ধতিগুলিতে পাস করব ।

    টাইমজোনস, বা তারিখের সীমা ইত্যাদির মতো কিছু অন্যান্য তথ্য থাকলে পৃথক শ্রেণি বোধগম্য হতে পারে

  • আইফেরফরমেন্সফ্যাক্টরি - নির্দিষ্ট পদ্ধতির জন্য কার্যকরকরণের সময় পরিমাপ করে।

    পরের বিষয়টি দেখুন।

  • আইলগ - লগিংয়ের জন্য লগ 4 নেট।

    এই ধরনের ট্রান্সসিড্যান্ট কার্যকারিতা কাঠামোর সাথে সম্পর্কিত এবং আসল গ্রন্থাগারগুলি রানটাইমের সময় বিনিময়যোগ্য এবং কনফিগারযোগ্য হওয়া উচিত (উদাহরণস্বরূপ .NET এ app.config এর মাধ্যমে)।

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

    লাইব্রেরিটি ব্যবহার করা যদি খুব জটিল হয় তবে একটি মুখের ধরণটি বোঝায় sense

  • আইকোলিকেশনআউপারফ্যাক্টরি - সংগ্রহ তৈরি করে (এটি আইনেউমারেবল প্রসারিত করে)।

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

  • আইকিউরিফিল্টারফ্যাক্টরি - ইনপুটের ভিত্তিতে ক্যোয়ারী উত্পন্ন করে যা ডিবিতে কোয়েরি করবে।

    এটি ডেটা অ্যাক্সেস লেয়ারে নেই কেন? নামে এখানে কেন Filter?

  • IIdentityHelper - লগ ইন করা ব্যবহারকারীকে পুনরুদ্ধার করে।

    আমি নিশ্চিত নই কেন এখানে Helperপ্রত্যয় আছে। সমস্ত ক্ষেত্রে, অন্যান্য প্রত্যয়গুলি (( IIdentityManager)) বিশেষভাবে স্পষ্ট হবে না

    যাইহোক, এখানে এই নির্ভরতা থাকা নিখুঁত করে তোলে।

  • আইফল্ট ফ্যাক্টরি - বিভিন্ন ফল্ট এক্সেক্সশন তৈরি করুন (আমি ডাব্লুসিএফ ব্যবহার করি)।

    এটা কি যুক্তি এত জটিল যে এটি একটি কারখানার প্যাটার্ন ব্যবহার করা প্রয়োজন? কেন নির্ভরতা ইনজেকশন ব্যবহার করা হয়? আপনি কি উত্পাদন কোড এবং পরীক্ষাগুলির মধ্যে ব্যাতিক্রমের উত্সকে পরিবর্তন করতে পারবেন? কেন?

    আমি refactor যে সহজ মধ্যে চেষ্টা করবে throw new FaultException(...)। যদি কিছু বৈশ্বিক তথ্য ক্লায়েন্টে প্রচারের আগে সমস্ত ব্যতিক্রমগুলিতে যুক্ত করা উচিত, ডাব্লুসিএফের সম্ভবত একটি ব্যবস্থা রয়েছে যেখানে আপনি একটি অযাচিত ব্যতিক্রম ধরা পড়েন এবং এটিকে পরিবর্তন করে ক্লায়েন্টে পুনর্বিবেচনা করতে পারেন।

ক্লাসে কতগুলি ইঞ্জেকশন লাগানো উচিত তার কোনও সীমা রয়েছে? এবং যদি তা হয় তবে কীভাবে এড়ানো যায়?

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

অনেকগুলি ইনজেকশন পাঠযোগ্যতা সীমাবদ্ধ করে, বা এটি আসলে এটির উন্নতি করে?

প্রচুর নির্ভরতা যুক্তিগুলি অনুসরণ করা আরও কঠিন করে তোলে। যদি যুক্তিটি অনুসরণ করা কঠিন হয় তবে ক্লাসটি সম্ভবত খুব বেশি করছে এবং বিভক্ত হওয়া উচিত।


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

7

এটি ডিআই-র একটি ক্লাসিক উদাহরণ যা আপনাকে জানিয়েছিল যে আপনার ক্লাসটি সম্ভবত একটি একক শ্রেণির হয়ে উঠার জন্য খুব বড় হয়ে উঠছে। এটি প্রায়শই ব্যাখ্যা করা হয় "বাহ, ডিআই আমার নির্মাতাকে বৃহস্পতির চেয়ে বড় করে তোলে, এই কৌশলটি ভয়াবহ", তবে এটি যা আপনাকে সত্যই বলে দেয় তা হল "আপনার শ্রেণীর উপর নির্ভরশীলতার নৌকা-বোঝা রয়েছে"। এটি জেনে, আমরা হয় করতে পারেন

  • পরিবর্তে নতুন উপর নির্ভরশীলতা শুরু করে বিষয়টি জোর করে under
  • আমাদের নকশা পুনর্বিবেচনা। সম্ভবত কিছু নির্ভরতা সর্বদা একত্রিত হয় এবং কিছু অন্যান্য বিমূর্ততার পিছনে লুকানো উচিত। হতে পারে আপনার ক্লাসটি 2 ভাগে বিভক্ত হওয়া উচিত হতে পারে এটি বেশ কয়েকটি শ্রেণীর দ্বারা রচিত হওয়া উচিত যার জন্য প্রতিটি নির্ভরতার একটি ছোট উপসেট প্রয়োজন।

নির্ভরতা পরিচালনার असंख्य উপায় রয়েছে এবং আপনার কোড এবং অ্যাপ্লিকেশন না জেনে আপনার ক্ষেত্রে কোনটি সবচেয়ে ভাল কাজ করে তা বলা অসম্ভব।

আপনার চূড়ান্ত প্রশ্নের উত্তর দিতে:

  • কোন শ্রেণীর কতটা নির্ভরতা থাকা উচিত তার একটি উচ্চতর সীমা আছে?

হ্যাঁ, উপরের সীমাটি "অনেক বেশি"। "অনেক বেশি" কত? "অত্যধিক" হয় যখন শ্রেণির সংহতি "খুব কম" হয়। এটা সব নির্ভর করে. সাধারণত কোনও শ্রেণীর প্রতি আপনার প্রতিক্রিয়া যদি "বাহ, এই জিনিসটির অনেক বেশি নির্ভরশীলতা" থাকে তবে তা অনেক বেশি।

  • ইনজেকশনের নির্ভরতা পাঠযোগ্যতার উন্নতি করে বা আঘাত করে?

আমি মনে করি এই প্রশ্নটি বিভ্রান্তিমূলক। উত্তর হ্যাঁ বা না হতে পারে। তবে এটি সবচেয়ে আকর্ষণীয় অংশ নয়। ইনজেকশন নির্ভরতা বিন্দু হ'ল তাদের ভিসিবল করা। এটি এমন একটি এপি তৈরির কথা যা মিথ্যা বলে না। এটি বিশ্বব্যাপী রাষ্ট্র প্রতিরোধ সম্পর্কে। এটি কোড টেস্টেবল করার বিষয়ে। এটি কাপলিং হ্রাস সম্পর্কে।

যুক্তিসঙ্গতভাবে ডিজাইন করা এবং নামকরণ পদ্ধতি সহ ভাল ডিজাইন করা ক্লাসগুলি খারাপভাবে ডিজাইন করা পাঠকদের চেয়ে বেশি পঠনযোগ্য। ডিআই প্রতি সেডের পাঠ্যগত উন্নতি ঘটায় না বা আঘাত করে না, এটি কেবল আপনার ডিজাইনের পছন্দগুলি আলাদা করে তোলে এবং যদি তারা খারাপ হয় তবে তা আপনার চোখকে ডুবিয়ে দেবে। এর অর্থ এই নয় যে ডিআই আপনার কোডটি কম পঠনযোগ্য করে তুলেছে, এটি কেবল আপনাকে দেখিয়েছে যে আপনার কোডটি ইতিমধ্যে একটি জগাখিচুড়ি ছিল, আপনি এটি কেবল লুকিয়ে রেখেছিলেন।


1
ভাল মতামত। ধন্যবাদ. হ্যাঁ, উপরের সীমাটি "অনেক বেশি"। - চমত্কার এবং সত্য।
24:36

3

সর্বব্যাপী "কোড কমপ্লিট" এর লেখক স্টিভ ম্যাককনেলের মতে, থাম্বের নিয়মটি হল যে 7 এরও বেশি একটি কোড গন্ধ যা রক্ষণাবেক্ষণের ক্ষতি করে। আমি ব্যক্তিগতভাবে মনে করি সংখ্যা বেশিরভাগ ক্ষেত্রেই কম, তবে ডিআই সঠিকভাবে করার ফলে আপনি যখন কম্পোজিশন রুটের খুব কাছাকাছি থাকবেন তখন ইনজেকশনের জন্য অনেকগুলি নির্ভরশীলতা তৈরি হবে। এটি স্বাভাবিক এবং প্রত্যাশিত। আইওসি কনটেইনারগুলি একটি দরকারী জিনিস এবং তারা কোনও প্রকল্পে যে জটিলতা যুক্ত করে সেগুলির এটি অন্যতম কারণ।

সুতরাং, আপনি যদি আপনার প্রোগ্রামের এন্ট্রি পয়েন্টের খুব কাছাকাছি থাকেন তবে এটি স্বাভাবিক এবং গ্রহণযোগ্য। আপনি যদি প্রোগ্রামটির যুক্তি আরও গভীর করে থাকেন তবে সম্ভবত এটি এমন গন্ধ যা সমাধান করা উচিত।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.