সমালোচনা এবং নির্ভরতা ইনজেকশন এর অসুবিধা

119

নির্ভরতা ইনজেকশন (ডিআই) একটি সুপরিচিত এবং কেতাদুরস্ত প্যাটার্ন। ইঞ্জিনিয়ারদের বেশিরভাগই এর সুবিধাগুলি জানেন:

ইউনিট পরীক্ষায় পৃথক করা সম্ভব / সহজ
স্পষ্টভাবে কোনও শ্রেণীর নির্ভরতা সংজ্ঞায়িত করা
ভাল ডিজাইনের সুবিধার্থে (উদাহরণস্বরূপ একক দায়িত্বের নীতি (এসআরপি))
সুইচিং বাস্তবায়নগুলি দ্রুত সক্ষম করা ( উদাহরণস্বরূপ DbLoggerপরিবর্তে ConsoleLogger)

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

ক্লাস সংখ্যা বৃদ্ধি
অপ্রয়োজনীয় ইন্টারফেস তৈরি

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

আমি জিজ্ঞাসা করতে চাই জিনিসগুলি হ'ল:

যখন আমাদের কেবল একটি বাস্তবায়ন হয় তখন আমাদের কি নির্ভরতা ইনজেকশন ব্যবহার করা উচিত?
আমাদের কি ভাষা / কাঠামোর বিষয়গুলি বাদ দিয়ে নতুন অবজেক্ট তৈরি নিষিদ্ধ করা উচিত?
একটি একক বাস্তবায়ন খারাপ ধারণা ইনজেকশন করা হয় (আসুন আমরা বলি যে আমাদের কেবল একটি বাস্তবায়ন রয়েছে তাই আমরা "খালি" ইন্টারফেস তৈরি করতে চাই না) যদি আমরা কোনও নির্দিষ্ট শ্রেণির ইউনিট পরীক্ষার পরিকল্পনা না করি?

design-patterns architecture dependency-injection

— Landeeyo
সূত্র

33

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

— ফ্রেেক্স

10

প্যাটার্ন সম্পর্কে ফ্রেক্স, ফ্রেমওয়ার্ক নয়

— ল্যান্ডিও

10

আপনি নির্ভরতা ইনজেকশনের সাথে নির্ভরতা বিপরীতকে বিভ্রান্ত করছেন। পূর্ববর্তী একটি নকশা নীতি। পরেরটি হ'ল অবজেক্টের শ্রেণিবদ্ধকরণের জন্য একটি কৌশল (সাধারণত কোনও বিদ্যমান সরঞ্জাম দিয়ে প্রয়োগ করা হয়)।

— jpmc26

3

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

— usr

3

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

— টি। সার

160

প্রথমত, আমি ফ্রেমওয়ার্কগুলির ধারণা থেকে নকশা পদ্ধতির আলাদা করতে চাই। এর সহজতম এবং সবচেয়ে মৌলিক স্তরে নির্ভরতা ইনজেকশনটি কেবলমাত্র:

প্যারেন্ট অবজেক্ট শিশু অবজেক্টের জন্য প্রয়োজনীয় সমস্ত নির্ভরতা সরবরাহ করে।

এটাই. দ্রষ্টব্য, এর যে কোনও কিছুর জন্য ইন্টারফেস, ফ্রেমওয়ার্ক, ইনজেকশনের কোনও স্টাইল ইত্যাদির প্রয়োজন নেই fair এটা নতুন নয়।

নির্ভরতা ইনজেকশন প্রসঙ্গে পিতা-মাতা এবং সন্তানের শব্দটি সম্পর্কে 2 জনেরও বেশি লোক বিভ্রান্তির কারণে:

পিতা বা মাতা বস্তু instantiates ও শিশু বস্তুর এটি ব্যবহার করে কনফিগার করা হয়
শিশু যে উপাদানটি নিস্ক্রিয়ভাবে instantiated করা ডিজাইন করা হয়। অর্থাৎ এটি পিতামাতার দ্বারা প্রদত্ত যে কোনও নির্ভরতা ব্যবহার করার জন্য ডিজাইন করা হয়েছে এবং এটি নিজস্ব নির্ভরতাগুলি তাত্পর্যপূর্ণ করে না।

নির্ভরতা ইনজেকশন হ'ল অবজেক্ট কম্পোজিশনের একটি প্যাটার্ন ।

ইন্টারফেস কেন?

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

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

ফ্রেমওয়ার্ক কেন?

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

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

তাদের নিম্নলিখিত অসুবিধাগুলিও রয়েছে:

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

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

[ইন্টারনেটে এলোমেলো নিবন্ধ] কী?

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

সংক্ষেপে, নিজের জন্য চিন্তা করুন এবং জিনিস চেষ্টা করে দেখুন।

"পুরানো মাথা" দিয়ে কাজ করা

আপনি যতটা পারেন শিখুন। 70০ এর দশকে আপনি যে অনেক বিকাশকারী কাজ করছেন তার সাথে আপনি কী খুঁজে পাবেন তা হ'ল তারা অনেক কিছু সম্পর্কে কৌতূহলপূর্ণ না হতে শিখেছে। তাদের কয়েক দশক ধরে কাজ করে এমন পদ্ধতি রয়েছে যা সঠিক ফলাফল দেয়।

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

— বেরিন লরিটস
সূত্র

6

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

— বেরিন লরিটশ

17

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

— জেরোইন মোস্টার্ট

1

ইন্টারফেসগুলি চুক্তি নয়, এগুলি কেবল এপিআই এর। চুক্তিগুলি শব্দার্থ বোঝায়। এই উত্তরটি ভাষা নির্দিষ্ট পরিভাষা এবং জাভা / সি # নির্দিষ্ট কনভেনশন ব্যবহার করছে।

— ফ্র্যাঙ্ক হিলিমান

2

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

— কার্ল লেথ

1

@ কার্লেলথ: সমস্ত ডিআই ফ্রেমওয়ার্কগুলি এমন কিছু জিনিস অপসারণ বা স্বয়ংক্রিয় করার জন্য ডিজাইন করা হয়েছে যা প্রোগ্রামার বানান করতে চান না, তারা ঠিক কীভাবে পরিবর্তিত হয়। আমার জানা মতে, তারা সবাই জানি কিভাবে (অথবা ক্ষমতা সরানো যদি ) বর্গ এবং মাত্র A এবং B দিকে তাকিয়ে বি ইন্টারঅ্যাক্ট - খুব অন্তত, এছাড়াও আপনি তাকান প্রয়োজন দ্বি সেটআপ / কনফিগারেশন / নিয়মাবলী। প্রোগ্রামারটির জন্য সমস্যা নয় (এটি আসলে তারা যা চায় ঠিক তেমন), তবে কোনও রক্ষণাবেক্ষণকারী / ডিবাগার (সম্ভবত একই প্রোগ্রামার, পরে) এর একটি সম্ভাব্য সমস্যা। এটি আপনার ডিআই ফ্রেমওয়ার্ক "নিখুঁত" হওয়া সত্ত্বেও আপনি বানানো বাণিজ্য।

— জেরোইন মোস্টার্ট

88

নির্ভরতা ইনজেকশন হল বেশিরভাগ নিদর্শনগুলির মতো, সমস্যার সমাধান । সুতরাং আপনার এমনকি প্রথম স্থানে সমস্যা আছে কিনা তা জিজ্ঞাসা করে শুরু করুন। যদি তা না হয় তবে প্যাটার্নটি সম্ভবত ব্যবহার করা কোডটিকে আরও খারাপ করে দেবে ।

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

একটি মডিউল বিবেচনা করুন যা কোনও বাহ্যিক পরিষেবা থেকে কিছু ডেটা ডাউনলোড করে, এটি বিশ্লেষণ করে এবং কিছু জটিল বিশ্লেষণ করে এবং কোনও ফাইলে ফলাফল লিখতে লিখতে।

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

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

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

অন্যদিকে কিছু ক্ষেত্রে রয়েছে যেখানে ডিআই সত্যিই দরকারী। যেমন লগারের মতো পার্শ্ব প্রতিক্রিয়া সহ গ্লোবাল পরিষেবাগুলির জন্য।

সমস্যাটি তখন যখন নিদর্শন এবং আর্কিটেকচারগুলি সরঞ্জামের চেয়ে নিজেরাই লক্ষ্য হয়ে ওঠে। কেবল জিজ্ঞাসা করছেন "আমাদের কি ডিআই ব্যবহার করা উচিত?" ঘোড়ার আগে কার্ট লাগানো হচ্ছে। আপনার জিজ্ঞাসা করা উচিত: "আমাদের কি সমস্যা আছে?" এবং "এই সমস্যার সর্বোত্তম সমাধান কী?"

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

— JacquesB
সূত্র

15

আমি আরও রাজি হতে পারে না! এছাড়াও নোট করুন যে এটির জন্য বিষয়গুলি উপহাস করার অর্থ হ'ল আমরা প্রকৃত বাস্তবায়নগুলি পরীক্ষা করছি না। যদি উত্পাদনে Aব্যবহার Bহয় তবে কেবল তার বিপরীতে পরীক্ষা করা হয় তবে MockBআমাদের পরীক্ষাগুলি আমাদের জানায় না যে এটি প্রযোজনায় কাজ করবে কিনা। যখন কোনও ডোমেন মডেলের খাঁটি (কোনও পার্শ্ব-প্রতিক্রিয়া) উপাদানগুলি একে অপরকে ইনজেকশন দেয় এবং উপহাস করে তখন ফলাফলটি প্রত্যেকের সময়ের একটি বিশাল অপচয়, একটি ফোলা এবং ভঙ্গুর কোডবেস এবং ফলাফলের সিস্টেমে কম আস্থা অর্জন করে। সিস্টেমের সীমানাগুলিতে মক করুন, একই সিস্টেমের যথেচ্ছ টুকরোগুলির মধ্যে নয় between

— ওয়ারবো

17

@ কার্লেলথ আপনি কী ভাবেন ডিআই কোডকে "পরীক্ষামূলক এবং রক্ষণাবেক্ষণযোগ্য" এবং কোডটি কম ছাড়া করে তোলে? জ্যাকসবি ঠিক বলেছেন যে পার্শ্ব প্রতিক্রিয়া হ'ল টেস্টিবিলিটি / রক্ষণাবেক্ষণের ক্ষতি করে। কোডের কোনও পার্শ্ব-প্রতিক্রিয়া না থাকলে, আমরা কীভাবে / কোথায় / কখন / কীভাবে এটি অন্য কোডকে কল করে তা বিবেচনা করি না; আমরা এটি সহজ এবং সরাসরি রাখতে পারি। কোড পার্শ্ব প্রতিক্রিয়া থাকে আমরা আছে যত্ন। ডিআই পার্শ্ব-প্রতিক্রিয়াগুলি ফাংশনগুলির বাইরে টানতে পারে এবং এটি পরামিতিগুলিতে রাখতে পারে, সেই ফাংশনগুলিকে আরও পরীক্ষামূলক করে তবে প্রোগ্রামটিকে আরও জটিল করে তোলে। কখনও কখনও এটি অনিবার্য (যেমন ডিবি অ্যাক্সেস)। কোডের কোনও পার্শ্ব প্রতিক্রিয়া না থাকলে ডিআই কেবলমাত্র অকেজো জটিলতা।

— ওয়ারবো

13

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

— ডক ব্রাউন

5

@ ওয়ার্বো এটিই মূল এবং এখনও সম্ভবত উপহাসের একমাত্র বৈধ ব্যবহার। এমনকি সিস্টেমের সীমানায়, এটি খুব কমই প্রয়োজন হয়। লোকেরা প্রায় মূল্যহীন পরীক্ষাগুলি তৈরি এবং আপডেট করতে সত্যই অনেক সময় নষ্ট করে।

— ফ্র্যাঙ্ক হিলিমান

6

@ কার্লেলথ: ঠিক আছে, আমি এখন দেখছি যে ভুল বোঝাবুঝি এসেছে। আপনি নির্ভরতা বিপরীতের কথা বলছেন । তবে, প্রশ্ন, এই উত্তর এবং আমার মন্তব্যগুলি ডিআই = ডিপোপেন্সি ইনজেকশন সম্পর্কে ।

— ডক ব্রাউন

36

আমার অভিজ্ঞতায় নির্ভরতা ইনজেকশনটিতে বেশ কয়েকটি ডাউনসাইড রয়েছে।

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

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

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

— এরিক
সূত্র

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

— রডনি পি। বারবাতি

7

যদি আপনি বাস্তব প্রয়োগের (কোনও উপহাস নয়) সহ কোনও শ্রেণি পরীক্ষা করতে চান তবে আপনি কার্যকরী পরীক্ষা লিখতে পারেন - ইউনিট পরীক্ষার অনুরূপ টেস্ট, তবে মক ব্যবহার না করে।

— BЈовић

2

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

— কনরাড রুডলফ

4

নির্ভরতার ইনজেকশন, সত্যিকারের ক্ষেত্রে এটির প্রয়োজনের বাইরে, এটি একটি সতর্কতা চিহ্ন যা অন্য অতিরিক্ত অতিরিক্ত কোড প্রচুর পরিমাণে উপস্থিত হতে পারে। এক্সিকিউটিভরা প্রায়শই শিখতে পেরে অবাক হন যে বিকাশকারীরা জটিলতার জন্য জটিলতা যুক্ত করে।

— ফ্রাঙ্ক হিলিমান

1

+1 টি। এটিই যে প্রশ্নের জিজ্ঞাসা করা হয়েছিল তার আসল উত্তর এবং এটি অবশ্যই গ্রহণযোগ্য উত্তর হওয়া উচিত।

— ম্যাসন হুইলারের

13

আমি "নেট মধ্যে নির্ভরতা ইনজেকশন" থেকে মার্ক সিমেনের পরামর্শ অনুসরণ করে - অনুগ্রহ করে।

আপনার যখন 'অস্থির নির্ভরতা' থাকে তখন ডিআই ব্যবহার করা উচিত, উদাহরণস্বরূপ এটির পরিবর্তনের কোনও যুক্তিসঙ্গত সুযোগ রয়েছে।

সুতরাং আপনি যদি ভাবেন ভবিষ্যতে আপনার একাধিক বাস্তবায়ন থাকতে পারে বা বাস্তবায়ন পরিবর্তিত হতে পারে, ডিআই ব্যবহার করুন। অন্যথায় newঠিক আছে।

— হরণ করা
সূত্র

5

উল্লেখ্য তিনি OO যেমন পণ্য জন্য বিভিন্ন পরামর্শ দেয় এবং কার্মিক ভাষায় blog.ploeh.dk/2017/01/27/...

— জে।

1

এটা ভাল পয়েন্ট। আমরা যদি ডিফল্টরূপে প্রতিটি নির্ভরতার জন্য ইন্টারফেস তৈরি করি তবে এটি কোনওভাবে YAGNI এর বিপরীতে।

— ল্যান্ডিও

4

আপনি কি ".NET মধ্যে নির্ভরতা ইনজেকশন" এর একটি রেফারেন্স সরবরাহ করতে পারেন ?

— পিটার মর্টেনসেন

1

আপনি যদি ইউনিট টেস্টিং করেন তবে সম্ভবত আপনার নির্ভরতা অস্থায়ী।

— জাকিজ 16'12

11

ভাল কথা হ'ল বিকাশকারীরা সর্বদা নির্ভুল নির্ভুলতার সাথে ভবিষ্যতের পূর্বাভাস দিতে সক্ষম হন।

— ফ্রাঙ্ক হিলিমান

5

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

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

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

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

— Vilx-
সূত্র

3

দ্রুত রূপান্তরকরণ বাস্তবায়ন সক্ষম করা (উদাহরণস্বরূপ কনসোললগারের পরিবর্তে DbLogger)

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

ক্লাস সংখ্যা বৃদ্ধি

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

অপ্রয়োজনীয় ইন্টারফেস তৈরি

প্রয়োজনের সময় আমি কেবল ইন্টারফেস তৈরি করি (যা বিরল)। এর অর্থ হ'ল কখনও কখনও, আমাকে একটি ইন্টারফেস দ্বারা শ্রেণীর সমস্ত উপস্থিতি প্রতিস্থাপন করতে হয়, তবে IDE আমার জন্য এটি করতে পারে।

যখন আমাদের কেবল একটি বাস্তবায়ন হয় তখন আমাদের কি নির্ভরতা ইনজেকশন ব্যবহার করা উচিত?

হ্যাঁ, তবে কোনও যুক্ত বয়লারপ্লেট এড়ানো উচিত ।

আমাদের কি ভাষা / কাঠামোর বিষয়গুলি বাদ দিয়ে নতুন অবজেক্ট তৈরি নিষিদ্ধ করা উচিত?

না। অনেকগুলি মান (অপরিবর্তনীয়) এবং ডেটা (পরিবর্তনযোগ্য) ক্লাস হবে, যেখানে উদাহরণগুলি কেবল তৈরি হয়ে যায় এবং চারপাশে পাস করে এবং যেখানে তাদের ইনজেকশন দেওয়ার কোনও লাভ নেই - কারণ তারা কখনই অন্য কোনও বস্তুতে সঞ্চয় হয় না (বা কেবল অন্যটিতে) যেমন বস্তু)।

তাদের জন্য, আপনার পরিবর্তে কারখানাটি ইনজেকশনের প্রয়োজন হতে পারে, তবে বেশিরভাগ সময় এটি কোনও বোধগম্য হয় না (উদাহরণস্বরূপ কল্পনা করুন @Value class NamedUrl {private final String name; private final URL url;}; আপনার এখানে সত্যিই কারখানার দরকার নেই এবং ইনজেকশন দেওয়ার মতো কিছুই নেই)।

একটি একক বাস্তবায়ন খারাপ ধারণা ইনজেকশন করা হয় (আসুন আমরা বলি যে আমাদের কেবল একটি বাস্তবায়ন রয়েছে তাই আমরা "খালি" ইন্টারফেস তৈরি করতে চাই না) যদি আমরা কোনও নির্দিষ্ট শ্রেণির ইউনিট পরীক্ষার পরিকল্পনা না করি?

আইএমএইচও যতক্ষণ না এটি কোনও কোড ফোটার কারণ না হয় ততক্ষণ তা ঠিক। নির্ভরতা ইনজেকশন করুন তবে ইন্টারফেসটি তৈরি করবেন না (এবং কোনও পাগল কনফিগারেশন এক্সএমএল!) আপনি এটি কোনও ঝামেলা ছাড়াই পরে করতে পারেন।

প্রকৃতপক্ষে, আমার বর্তমান প্রকল্পে, চারটি শ্রেণি রয়েছে (শতকের মধ্যে), যা আমি ডিআই থেকে বাদ দেওয়ার সিদ্ধান্ত নিয়েছিলাম কারণ এগুলি ডেটা অবজেক্ট সহ অনেক জায়গায় ব্যবহৃত সাধারণ ক্লাস used

বেশিরভাগ ডিআই ফ্রেমওয়ার্কের আর একটি অসুবিধা হ'ল রানটাইম ওভারহেড। এটি সংকলন সময় সরিয়ে নেওয়া যেতে পারে (জাভা জন্য, ড্যাজার আছে , অন্যান্য ভাষা সম্পর্কে ধারণা নেই)।

তবুও আরেকটি অসুবিধা হ'ল যাদুঘর সর্বত্র ঘটছে, যা টিউন করা যেতে পারে (যেমন, গুইস ব্যবহার করার সময় আমি প্রক্সি তৈরিটি অক্ষম করেছিলাম)।

— maaartinus
সূত্র

-4

আমাকে বলতে হবে যে আমার মতে, নির্ভরতা ইনজেকশনটির পুরো ধারণাটি ওভাররেটেড।

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

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

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

কোডে, এই ধারণাটি এর মতো দেখাচ্ছে ...

class ClassUnderTest {

   protected final ADependency;
   protected final AnotherDependency;

   // Call from a factory or use an initializer 
   public void initializeDependencies() {
      aDependency = new ADependency();
      anotherDependency = new AnotherDependency();
   }
}

class TestClassUnderTest extends ClassUnderTest {

    @Override
    public void initializeDependencies() {
      aDependency = new MockitoObject();
      anotherDependency = new MockitoObject();
    }

    // Unit tests go here...
    // Unit tests call base class methods
}

ফলাফলটি ডিআই ব্যবহারের সমান সমান - যা ক্লাসউন্ডারস্টেস্ট পরীক্ষার জন্য কনফিগার করা হয়।

কেবলমাত্র পার্থক্যগুলি হ'ল এই কোডটি সম্পূর্ণ সংক্ষিপ্ত, সম্পূর্ণ এনপ্যাপুলেটেড, কোড করা সহজ, দ্রুত বোঝা যায়, কম স্মৃতি ব্যবহার করে, বিকল্প কনফিগারেশন প্রয়োজন হয় না, কোনও ফ্রেমওয়ার্ক প্রয়োজন হয় না, 4 পৃষ্ঠার কারণ কখনই হবে না (ডাব্লুটিএফ!) স্ট্যাক ট্রেস যার মধ্যে আপনি লিখেছেন ঠিক জিরো (0) ক্লাস অন্তর্ভুক্ত রয়েছে এবং আপনি এমনকি গুরু থেকে শুরু করে এমনকি গুরুতর জ্ঞানহীন কারও কাছেই সম্পূর্ণ স্পষ্ট ((আপনি ভেবেছিলেন, তবে ভুল হবে)।

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

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

— রডনি পি বারবতি
সূত্র

6

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

— লোগান পিকআপ 6

1

এটি আপনার ক্লাসের উত্তরাধিকারের একটি মাত্রা এবং নির্ভরশীলতার এক স্তর থাকে তখন এটি পরিষ্কার। অবশ্যই এটি পৃথিবীতে জাহান্নামে পরিণত হবে যখন এটি প্রসারিত হবে?

— ইভান

4

আপনি যদি ইন্টারফেস ব্যবহার করেন এবং কনস্ট্রাক্টরটিতে প্রাথমিককরণ নির্ভরতা () এর একই তবে নীচের দিকে সরান। পরবর্তী পদক্ষেপ, নির্মাণের পরামিতি যুক্ত করার অর্থ আপনি আপনার সমস্ত টেস্টক্লাসগুলি সরিয়ে ফেলতে পারবেন।

— ইভান

5

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

— মিঃমিন্দর

3

@ মিঃ মাইন্ডারে যুক্ত করা: আরও একটি সাধারণ অ্যান্টি-প্যাটার্ন "সিক্যুয়েন্সাল কাপলিং" রয়েছে যা কেবল আরম্ভের ক্ষেত্রে প্রযোজ্য নয়। যদি কোনও অবজেক্টের পদ্ধতিগুলি (বা আরও সাধারণভাবে, একটি এপিআই এর কল) অবশ্যই একটি নির্দিষ্ট ক্রমে চালানো হয়, উদাহরণস্বরূপ barকেবল পরে বলা যেতে পারে foo, তবে এটি একটি খারাপ এপিআই। এটি কার্যকারিতা সরবরাহ করার জন্য দাবি করে ( bar), তবে আমরা আসলে এটি ব্যবহার করতে পারি না (যেহেতু fooসম্ভবত ডাকা হত না)। আপনি যদি আপনার initializeDependencies(বিরোধী?) নিদর্শনটির সাথে তাল মিলাতে চান তবে আপনার এটিকে কমপক্ষে ব্যক্তিগত / সুরক্ষিত করা উচিত এবং নির্মাণকারীর কাছ থেকে এটি স্বয়ংক্রিয়ভাবে কল করা উচিত, সুতরাং API আন্তরিক।

— ওয়ারবো

-6

আপনার প্রশ্নটি কি "ইউনিট টেস্টিং খারাপ?"

ইনজেক্ট করার জন্য আপনার বিকল্প ক্লাসের 99% হ'ল শখগুলি হবে যা ইউনিট পরীক্ষা সক্ষম করে।

আপনি ডিআই ছাড়াই ইউনিট টেস্টিংয়ের ক্ষেত্রে ক্লাসগুলি কীভাবে উপহাস করা ডেটা বা উপহাস পরিষেবা ব্যবহার করবেন তা নিয়ে আপনার সমস্যা রয়েছে। 'যুক্তির অংশ' বলতে দিন কারণ আপনি এটি পরিষেবাগুলিতে আলাদা করছেন না।

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

এত অসুবিধে করতে অসুবিধা করা কল্পনা করা শক্ত যে ইউনিট পরীক্ষার সুবিধাটি অভিভূত হয়।

— ইওয়ান
সূত্র

13

আমি আপনার এই দাবির সাথে একমত নই যে ডিআই ইউনিট পরীক্ষার বিষয়ে। ইউনিট পরীক্ষার সুবিধার্থে ডিআই-র অন্যতম একটি সুবিধা এবং যুক্তিযুক্তভাবে এটি সবচেয়ে গুরুত্বপূর্ণ নয়।

— রবার্ট হার্ভে

5

আমি আপনার ভিত্তির সাথে একমত নই যে ইউনিট টেস্টিং এবং ডিআই এত কাছে are মক / স্টাব ব্যবহার করে আমরা টেস্ট স্যুটটি আরও কিছুটা মিথ্যা বলি: পরীক্ষার অধীনে থাকা সিস্টেমটি আসল সিস্টেম থেকে আরও এগিয়ে যায়। এটা উদ্দেশ্যমূলকভাবে খারাপ। কখনও কখনও এটি একটি উল্টোপাল্ট দ্বারা ছাপিয়ে যায়: উপহাসকৃত এফএস কলগুলির ক্লিনআপের প্রয়োজন হয় না; ঠাট্টা করা এইচটিটিপি অনুরোধগুলি দ্রুত, নিরোধক এবং অফলাইনে কাজ করে; ইত্যাদি বিপরীতে, প্রতিটি সময় আমরা newকোনও পদ্ধতির অভ্যন্তরে হার্ড-কোডড ব্যবহার করি আমরা জানি যে পরীক্ষায় চলমান একই কোডটি চলমান ছিল।

— ওয়ারবো

8

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

— কনরাড রুডল্ফ

6

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

— কনরাড রুডলফ

5

@ ইভান আপনার লিঙ্ক ইউনিট পরীক্ষার একটি ভাল সংজ্ঞা দেয়। সেই সংজ্ঞা অনুসারে আমার Orderউদাহরণটি ইউনিট পরীক্ষা: এটি একটি পদ্ধতি ( totalপদ্ধতি Order) পরীক্ষা করছে। আপনি অভিযোগ করছেন যে এটি 2 টি ক্লাস থেকে কোড কল করছে, আমার প্রতিক্রিয়া তাই কি ? আমরা "একবারে 2 টি ক্লাস" পরীক্ষা করছি না, আমরা totalপদ্ধতিটি পরীক্ষা করছি । আমরা পরোয়া করা উচিত নয় কিভাবে একটি পদ্ধতি তার পেশা আছে: এই বাস্তবায়ন বিবরণ আছে; এগুলির পরীক্ষার ফলে ভঙ্গুরতা, আঁটসাঁট পোশাক ইত্যাদি ঘটে We আমরা কেবল পদ্ধতিটির আচরণের (রিটার্নের মান এবং পার্শ্ব প্রতিক্রিয়া) যত্ন করি না, ক্লাস / মডিউল / সিপিইউ রেজিস্টার / ইত্যাদি। এটি প্রক্রিয়া ব্যবহৃত।

— ওয়ার্বো