ডিপেন্ডেন্সি ইনজেকশন ব্যবহারের ডাউনসাইডগুলি কী কী? [বন্ধ]


336

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

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


ব্যাখ্যা : আমি নির্ভরতা ইনজেকশন বিষয়ে কথা বলছি প্যাটার্ন (দেখুন এই নিবন্ধটি মার্টিন জালিয়া দ্বারা), না একটি নির্দিষ্ট কাঠামো, কিনা XML- ভিত্তিক (যেমন বসন্ত হিসাবে) বা কোড-ভিত্তিক (যেমন Guice হিসাবে), বা "আত্ম-ঘূর্ণিত" ।


সম্পাদনা করুন : এখানে দুর্দান্ত কিছু আলোচনা / রেটিং / বিতর্ক চলছে / র / প্রোগ্রামিং চলছে ।


আমরা নিজেই ডিআইই বা এটির সমর্থনকারী কোনও নির্দিষ্ট ধরণের সরঞ্জাম (এক্সএমএল-ভিত্তিক বা না) নিয়ে আলোচনা করব কিনা তা নির্দিষ্ট করে দেওয়া ভাল ধারণা হতে পারে।
জেসি মিলিকান

5
পার্থক্যটি হ'ল আমি এমন উত্তরগুলির সন্ধান করছি না যা কেবলমাত্র "এক্সএমএল সাকস" এর মতো নির্দিষ্ট কাঠামোর ক্ষেত্রে প্রযোজ্য। :) আমি এমন উত্তর খুঁজছি যা ডিও

3
আমি সাধারণভাবে ডিআই এর কাছে কোনও ডাউনসাইডস দেখতে পাই না (কনস্ট্রাক্টর, সেটার বা পদ্ধতি)। এটি ডিউপলস করে এবং কোনও ওভারহেড ছাড়াই সরল করে।
কিসাকি

2
@ কিসমাকি সেটারের ইনজেকশন স্টাফ থেকে আলাদা। নির্মাণে ব্যবহারযোগ্য এমন বস্তু তৈরির পক্ষে সেরা। আপনি যদি বিশ্বাস না করেন, কেবল 'সেটার' ইনজেকশন দিয়ে কোনও বস্তুকে অন্য সহযোগী যুক্ত করার চেষ্টা করুন, আপনি অবশ্যই একটি
এনপিই

উত্তর:


209

কয়েক দফা:

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

সাধারণত, ডিউপলিংয়ের সুবিধা প্রতিটি কাজকে পড়তে ও বুঝতে সহজ করে তোলে, তবে আরও জটিল কাজগুলি বাছাইয়ের জটিলতা বৃদ্ধি করে।


72
- ক্লাস পৃথকীকরণ জটিলতা হ্রাস করে। অনেক ক্লাস কোনও অ্যাপ্লিকেশন জটিল করে না। - অ্যাপ্লিকেশন-রুটে আপনার ডিআই ফ্রেমওয়ার্কের উপর কেবলমাত্র নির্ভরতা থাকা উচিত।
রবার্ট

91
আমরা মানুষ; আমাদের স্বল্পমেয়াদী মেমরিটি সীমিত এবং এক সাথে অনেকগুলি <xxx> পরিচালনা করতে পারে না। ক্লাসগুলির জন্য এটি একই রকম, এটি আপনার প্রোগ্রামটি বিকাশের জন্য পদ্ধতি, ফাংশন, ফাইল বা আপনি যে কোনও নির্মাণের জন্য ব্যবহার করেন।
হাভার্ড এস

45
@ হাওয়ার্ড এস: হ্যাঁ, তবে 5 টি জটিল ক্লাস 15 টি সাধারণের চেয়ে সহজ নয়। জটিলতা হ্রাস করার উপায় হ'ল কোডারে কর্মরত প্রোগ্রামার দ্বারা প্রয়োজনীয় কাজের সেট হ্রাস করা - জটিল, অত্যন্ত আন্তঃনির্ভরশীল ক্লাসগুলি এটি সম্পাদন করে না।
কিরিউ

35
@ ক্যারিউ আমি মনে করি আমরা সকলেই তাতে একমত হই। মনে রাখবেন জটিলতা মিলনের মতো নয় । সংযুক্তি হ্রাস জটিলতা বাড়াতে পারে। আমি সত্যিই বলছি না যে ডিআই একটি খারাপ জিনিস কারণ এটি ক্লাসের সংখ্যা বৃদ্ধি করে, আমি এর সাথে যুক্ত সম্ভাব্য ডাউনসাইডগুলি হাইলাইট করছি। :)
হাভার্ড এস

96
"ডিআই জটিলতা বৃদ্ধি করে" এর জন্য +1 এটি ডিআই এবং তার বাইরেও সত্য। (প্রায়) যেকোন সময় আমরা নমনীয়তা বাড়াতে, আমরা জটিলতা বাড়িয়ে তুলি। এটি সমস্ত ভারসাম্য সম্পর্কে, যা উত্সাহ এবং ডাউনসাইডগুলি জেনে শুরু হয়। লোকেরা যখন বলে, 'কোনও ডাউনসাইড নেই,' এটি একটি নিশ্চিত সূচক যে তারা এখনও বিষয়টি পুরোপুরি বুঝতে পারে নি।
ডন ব্রানসন

183

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

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

মূল কথাটি কোডটি লিখতে হয় যা কাজটি করে এবং শক্ত, পাঠযোগ্য এবং রক্ষণাবেক্ষণযোগ্য। আপনি একটি সফ্টওয়্যার বিকাশকারী - আইভরি টাওয়ার নির্মাতা নন।

প্রাসঙ্গিক লিঙ্ক

http://thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx

http://www.joelonsoftware.com/articles/fog0000000018.html


সম্ভবত নির্ভরতা ইনজেকশনটির সহজতম রূপ (হাসবেন না) একটি প্যারামিটার। নির্ভরশীল কোডটি ডেটা নির্ভর করে এবং সেই তথ্যটি প্যারামিটারটি পাস করার মাধ্যমে ইনজেক্ট করা হয়।

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

এই সাধারণ traditionalতিহ্যবাহী ফাংশনটি গ্রহণ করা যাক - সি ++ সিনট্যাক্স এখানে গুরুত্বপূর্ণ নয়, তবে আমি এটি কোনওভাবে বানান করতে চাই ...

void Say_Hello_World ()
{
  std::cout << "Hello World" << std::endl;
}

আমার একটি নির্ভরতা আছে যা আমি বের করতে এবং ইনজেকশন করতে চাই - "হ্যালো ওয়ার্ল্ড" পাঠ্য। যথেষ্ট সহজ ...

void Say_Something (const char *p_text)
{
  std::cout << p_text << std::endl;
}

আসলটির চেয়ে কী আরও জটিল? ঠিক আছে, আমি যদি সিদ্ধান্ত নিই যে আউটপুটটি ইউনিকোড হওয়া উচিত। আমি সম্ভবত std :: cout থেকে std :: wcout এ পরিবর্তন করতে চাই। তবে তার মানে আমার স্ট্রিংগুলি তখন wchar_t হতে হবে, চরের নয়। হয় প্রতিটি কলার পরিবর্তন করতে হবে, বা (আরও যুক্তিসঙ্গতভাবে), পুরানো বাস্তবায়ন একটি অ্যাডাপ্টারের সাথে প্রতিস্থাপন হয়ে যায় যা স্ট্রিংটিকে অনুবাদ করে এবং নতুন বাস্তবায়ন কল করে।

ঠিক এখনই এটি রক্ষণাবেক্ষণের কাজ যা আমরা যদি মূলটি রাখি তবে প্রয়োজন হবে না।

এবং যদি এটি তুচ্ছ মনে হয়, তবে উইন 32 এপিআই থেকে এই আসল-ওয়ার্ল্ড ফাংশনটি একবার দেখুন ...

http://msdn.microsoft.com/en-us/library/ms632680%28v=vs.85%29.aspx

এটি মোকাবেলায় 12 "নির্ভরতা"। উদাহরণস্বরূপ, যদি স্ক্রিন রেজোলিউশনগুলি সত্যিই বিশাল আকার ধারণ করে, তবে আমাদের প্রয়োজন হবে -৪-বিট সমন্বিত মান - এবং ক্রিয়েট উইন্ডোএক্সের অন্য সংস্করণ। এবং হ্যাঁ, ইতিমধ্যে একটি পুরানো সংস্করণ ইতিমধ্যে ঝুলছে, সম্ভবত পর্দার পিছনে নতুন সংস্করণে ম্যাপ করা হবে ...

http://msdn.microsoft.com/en-us/library/ms632679%28v=vs.85%29.aspx

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

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

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


3
নির্ভরতা ইনজেকশন এর কোনও ত্রুটি নেই any এটি কেবল আপনার পাসের নির্ভরতাগুলি অবজেক্টগুলিতে পরিবর্তন করে, যা জটিলতা বা জটিলতা যুক্ত করে না। পুরোপুরি বিপরীত.
কিসাকি

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

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

আপনি যদি ওভারলোডিং বিবেচনা করেন তবে আমি এই উদাহরণটি বুঝতে পারি তা নিশ্চিত নই। আক্ষরিক "হ্যালো ওয়ার্ল্ড" আউটপুট করতে, আমরা () স্বাক্ষর ব্যবহার করি। একটি 8-বিট স্ট্রিং আউটপুট করতে (চর) স্বাক্ষর ব্যবহার করুন। ইউনিকোড আউটপুট করতে, ওভারলোড (wchar_t)। স্পষ্টতই, এক্ষেত্রে, (wchar_t) হ'ল একে পর্দার আড়ালে অন্যরা ডাকে। সেখানে খুব বেশি কোড পুনর্লিখনের প্রয়োজন নেই। আমি কিছু অনুপস্থিত করছি?
ingredient_15939

2
@ উপাদান_15939 - হ্যাঁ, এটি খেলনার একটি সরল উদাহরণ। আপনি যদি সত্যিই এটি করে চলেছেন তবে আপনি অ্যাডাপ্টারের চেয়ে কেবল ওভারলোডিং ব্যবহার করতেন কারণ কোডটি নকল করার জন্য অ্যাডাপ্টারের ব্যয়ের চেয়ে কম খরচ হয়। তবে মনে রাখবেন যে সদৃশ কোডটি সাধারণত একটি খারাপ জিনিস এবং সদৃশ কোড এড়ানোর জন্য অ্যাডাপ্টার ব্যবহার করা অন্য একটি ভাল কৌশল (যা কখনও কখনও খুব বেশি এবং ভুল জায়গায় ব্যবহার করা যেতে পারে)।
স্টিভ 314

77

এখানে আমার নিজস্ব প্রাথমিক প্রতিক্রিয়া: মূলত যে কোনও প্যাটার্নের একই ডাউনসাইড।

  • এটি শিখতে সময় লাগে
  • ভুল বোঝাবুঝি করলে তা ভালোর চেয়ে আরও বেশি ক্ষতি হতে পারে
  • যদি চূড়ান্তভাবে নিয়ে যাওয়া হয় তবে এটি উপকারের ন্যায্যতার চেয়ে বেশি কাজ হতে পারে

2
কেন শিখতে সময় লাগে? আমি ভেবেছিলাম ইজবির সাথে তুলনা করে বিষয়গুলি সহজ করে তোলে।
ফাস্টকোডাজভা

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

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

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

1
+1 আমি সিমফনি 2 ব্যবহার করছি, ডিআই সমস্ত ব্যবহারকারীর কোডের মধ্যে রয়েছে, কেবল এটি ব্যবহার করে উত্সাহ দিচ্ছে।
এমজিপি

45

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


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

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

1
আমি সম্মত (আমি আপনাকে ভোট দিয়েছি)। আমি ঠিক কথা বলছিলাম।
বিকির্ক

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

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

42

7
আমি কৌতূহলী, যখন কেউ উইন্ডসাইডের জন্য জিজ্ঞাসা করে, কেন একটি আত্মায় উত্তরগুলি "সেখানে কোনও" থাকে না এবং যেগুলির প্রশ্নের সাথে সম্পর্কিত কিছু তথ্য থাকে না কেন?
গ্যাব্রিয়েল áerbák

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

4
আমি অবাক হয়েছি যদি সর্বাধিক উত্সাহিত উত্তরটিও হ্রাস পেয়ে যায়, কারণ এটি সত্যই কোনও প্রশ্নের উত্তর দেয় না imho :) অবশ্যই আমি জানি আপনি কী জিজ্ঞাসা করেছিলেন এবং আমি কী উত্তর দিয়েছি, আমি উচ্ছ্বাসের জন্য জিজ্ঞাসা করছি না, আমি শুধু বিভ্রান্ত হয়েছি কেন আমার আপাতদৃষ্টিতে ডিআইই নেতিবাচকভাবে বলছেন এমন উত্তর হ'ল উত্তরটি সহায়তা করছে না এটি খুব শীতল যে অনেক বেশি সহায়তা করছে।
গ্যাব্রিয়েল áerbák

41

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

  • কোড বোঝা শক্ত হয়ে উঠতে পারে। নির্ভরতা ইনজেকশন খুব ... সৃজনশীল ... উপায়ে ব্যবহার করা যেতে পারে। উদাহরণস্বরূপ আমি কিছু কোড জুড়ে এসেছি যা নির্দিষ্ট আইওএসট্রিমগুলি ইনজেক্ট করতে কাস্টম টীকা ব্যবহার করে (যেমন: @ সার্ভার 1 স্ট্রিম, @ সার্ভার 2 স্ট্রিম)। এটি কাজ করে এবং আমি স্বীকার করি যে একটি নির্দিষ্ট কমনীয়তা রয়েছে, এটি গুইস ইনজেকশনগুলি বোঝার জন্য কোডটি বোঝার পূর্বশর্ত তৈরি করে।
  • প্রকল্প শেখার সময় উচ্চতর শিক্ষার বক্ররেখা। এটি 1 পয়েন্টের সাথে সম্পর্কিত a একটি প্রকল্প যা নির্ভরতা ইনজেকশন ব্যবহার করে তা কীভাবে বোঝার জন্য আপনাকে নির্ভরতা ইনজেকশন প্যাটার্ন এবং নির্দিষ্ট কাঠামো উভয়ই বুঝতে হবে। আমি যখন আমার বর্তমান কাজটি শুরু করেছি তখন গুয়াস পর্দার আড়ালে কী করছে তা নিয়ে আমি বেশ কয়েকটা বিভ্রান্ত ঘন্টা কাটিয়েছি hours
  • কনস্ট্রাক্টররা বড় হয়ে যায়। যদিও এটি একটি ডিফল্ট নির্মাতা বা কারখানার সাথে অনেকাংশে সমাধান করা যায়।
  • ত্রুটিগুলি আপত্তি করা যায়। আমার সাম্প্রতিকতম উদাহরণটি হ'ল আমার 2 টি পতাকা নামের সাথে সংঘর্ষ হয়েছিল। গুইস ত্রুটিটি নিঃশব্দে গ্রাস করেছে এবং আমার একটি পতাকা আরম্ভ করা হয়নি।
  • ত্রুটিগুলি রান-টাইমে ঠেলাঠেলি করা হয়। আপনি যদি আপনার গুইস মডিউলটি ভুলভাবে কনফিগার করেন (বিজ্ঞপ্তি সংক্রান্ত রেফারেন্স, খারাপ বাঁধাই, ...) বেশিরভাগ ত্রুটি সংকলনের সময় অনাবৃত হয় না। পরিবর্তে, প্রোগ্রামটি আসলে চালানো হলে ত্রুটিগুলি প্রকাশিত হয়।

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

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


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

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

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

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

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

24

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

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

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

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


1
হ্যাঁ, আমি সেই শব্দটি "রাভিওলি কোড" পছন্দ করি; আমি যখন ডিআই এর খারাপ দিক সম্পর্কে কথা বলি তখন আমি এটি আরও দীর্ঘ-বাতাসে প্রকাশ করি। তবুও, আমি ডিআই ছাড়া জাভাতে কোনও বাস্তব কাঠামো বা অ্যাপ্লিকেশন বিকাশ করতে পারি না।
হাওয়ার্ড এম লুইস শিপ

13

যদি আপনার একটি বাড়তি-উত্পন্ন সমাধান থাকে তবে নির্ধারকের মধ্যে নির্ভরতাগুলি আপনার মুখে ঠিক in অথবা আবার পদ্ধতি পরামিতি হিসাবে যা আবার স্পট করা খুব কঠিন নয়। ফ্রেমওয়ার্ক পরিচালিত নির্ভরতা, চূড়ান্তভাবে নেওয়া হলেও, যাদুটির মতো প্রদর্শিত হতে পারে।

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


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

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

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

ডিআই কি এই সমস্যার সমাধান করে? কোন । তবে আপনি প্রতিটি ঘর ডিজাইন করার দায়িত্ব তার দখলকারীদের অর্পণ করার চেষ্টা করছেন কিনা তা আপনাকে পরিষ্কারভাবে দেখতে সহায়তা করে।


13

একটা জিনিস যা আমাকে ডিআই-এর সাথে একটু ঝাপসা করে তোলে তা হ'ল এই ধারণাটি যে সমস্ত ইনজেকশনের জিনিসগুলি ইনস্ট্যান্ট করে তুলতে এবং কোনও পার্শ্ব প্রতিক্রিয়া তৈরি করা সস্তা -আর নির্ভরতা এত ঘন ঘন ব্যবহৃত হয় যে এটি কোনও সম্পর্কিত ইনস্ট্যান্টেশন ব্যয়ের চেয়েও বেশি।

যেখানে এটি তাত্পর্যপূর্ণ হতে পারে যখন কোনও গ্রাহক শ্রেণীর মধ্যে নির্ভরতা ঘন ঘন ব্যবহৃত হয় না ; যেমন একটি মত কিছু IExceptionLogHandlerService। স্পষ্টতই, এই জাতীয় পরিষেবাটি ক্লাসের মধ্যে খুব কমই আহ্বান করা হয় (আশা করা যায় :) - সম্ভবত কেবল ব্যতিক্রম লগ ইন করার প্রয়োজনে; তবুও ক্যানোনিকাল কনস্ট্রাক্টর-ইনজেকশন প্যাটার্ন ...

Public Class MyClass
    Private ReadOnly mExLogHandlerService As IExceptionLogHandlerService

    Public Sub New(exLogHandlerService As IExceptionLogHandlerService)
        Me.mExLogHandlerService = exLogHandlerService
    End Sub

     ...
End Class

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

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

যাইহোক, নির্দিষ্ট কৌশলগুলি ইনজেকশনের নির্ভরতা অলস-লোডিংয়ের অনুমতি দিয়ে এই সঠিক সমস্যাটি হ্রাস করতে পারে, উদাহরণস্বরূপ একটি শ্রেণিটিকে Lazy<IService>নির্ভরতা হিসাবে উদাহরণ সরবরাহ করে। এটি আপনার নির্ভরশীল অবজেক্টের কনস্ট্রাক্টরগুলিকে পরিবর্তন করবে এবং তারপরে বাস্তবায়ন সম্পর্কিত বিশদ যেমন অবজেক্ট কনস্ট্রাকশন ব্যয়ের বিষয়ে আরও সচেতন হবে, যা তাত্ক্ষণিকভাবে কাম্য নয়।


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

1
যে কোনও আধুনিক আইওসি ধারক আপনাকে কোনও নির্দিষ্ট বিমূর্ত প্রকার / ইন্টারফেসের জন্য সর্বদা অবজেক্টের জীবনকাল নির্দিষ্ট করতে দেয় (সর্বদা অনন্য, সিঙ্গলটন, এইচপি স্কোপ ইত্যাদি)। আপনি ফ্যানক <টি> বা আলস্য <T> ব্যবহার করে অলসভাবে এটি ইনস্ট্যান্ট করার জন্য একটি কারখানার পদ্ধতি / প্রতিনিধিও সরবরাহ করতে পারেন।
দিমিত্রি এস

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

12

যে মায়া আপনি আপনার কোডটি ডিকোপল করেছেন কেবলমাত্র নির্ভরতা ইনজেকশন প্রয়োগ করে এটি সত্যই ডিকপলিং ছাড়াই। আমি মনে করি এটি ডিআই সম্পর্কে সবচেয়ে বিপজ্জনক জিনিস।


11

এটি একটি নিটপিক আরও। কিন্তু নির্ভরতা ইনজেকশনটির একটি ডাউনসাইড হ'ল কোড সম্পর্কিত কারণ এবং নেভিগেট করা বিকাশের সরঞ্জামগুলির পক্ষে একে আরও শক্ত করে তোলে।

বিশেষত, আপনি যদি কোডটিতে কোন পদ্ধতিতে প্রার্থনা-ক্লিক / কমান্ড-ক্লিক করেন তবে এটি আপনাকে কংক্রিটের প্রয়োগের পরিবর্তে ইন্টারফেসের পদ্ধতি ঘোষণায় নিয়ে যাবে।

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

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

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


5
পুনরায় ভাগের সাথে সিটিটিএল-শিফট-বি আপনাকে বাস্তবায়ন করে
অ্যাড্রিয়ানম

1
তবে তারপরেও আমরা (আদর্শ বিশ্বে) প্রতিটি কিছুর কমপক্ষে ২ টি বাস্তবায়ন করব না, অর্থাৎ ইউনিট পরীক্ষার জন্য কমপক্ষে একটি আসল বাস্তবায়ন এবং একটি বিদ্রূপ ;-)
বিকির্ক

1
Eclipse এ আপনি যদি সিটিআরএল ধরে রাখেন এবং পদ্ধতি আহ্বান কোডের উপরে ঘোরােন তবে এটি আপনাকে ঘোষণাপত্র বা বাস্তবায়নটি খোলার জন্য একটি মেনু প্রদর্শন করবে।
স্যাম হাসলার

আপনি যদি ইন্টারফেস সংজ্ঞায় থাকেন তবে পদ্ধতির নামটি হাইলাইট করুন এবং সেই পদ্ধতির জন্য হায়ারার্কির ধরণটি আনতে Ctrl + T টি স্ট্রাইক করুন - আপনি সেই পদ্ধতির প্রতিটি প্রয়োগকারীকে একটি ধরণের শ্রেণিবদ্ধ গাছের মধ্যে দেখতে পাবেন।
কোয়ালিডাফিয়াল

10

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

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


1
কনস্ট্রাক্টর-ভিত্তিক সমস্যা হ'ল আপনাকে সর্বদা আরও বেশি কনস্ট্রাক্টর আরগ যুক্ত করতে হবে ...
মিগুয়েল পিং

1
হা হা। আপনি যদি এটি খুব বেশি করে করেন তবে শীঘ্রই আপনি দেখতে পাবেন যে আপনার কোডটি কৃপণ এবং আপনি এটিকে রিফেক্টর করবেন। তদ্ব্যতীত, ctrl-f6 যে হার্ড নয় that
4tea

এবং অবশ্যই এর বিপরীতটিও সত্য: ওও প্রোগ্রামিংয়ের সুবিধা পাওয়ার জন্য ক্লোজার হিসাবে ক্লাস লেখার এটি কেবল একটি দীর্ঘকালীন দীর্ঘ হাতের কার্যকরী উপায়
কার্টেনডোগ

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

9

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

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

(একটি সাইডনোট হিসাবে, আমি পুরো বিষয়টিকে বেশ "ধর্মীয়" দেখতে পাই, তবে আপনার মাইলেজটি আপনার দেব দলের প্রযুক্তিগত উদ্যোগের মাত্রার সাথে পৃথক হবে!)


8
আপনার যদি বড় কুৎসিত নির্মাণকারী থাকে, আপনার ক্লাসগুলি বড় হতে পারে এবং আপনার কেবলমাত্র অনেক নির্ভরশীলতা থাকতে হবে?
রবার্ট

4
এটাই সম্ভবত এমন একটি সম্ভাবনা যা আমি আনন্দ করতে চাই! ... দুঃখের বিষয়, যদিও আমার সাথে এমন কোনও দল নেই যা আমি সমাপ্তির সাথে পর্যালোচনা করতে পারি। বেহালার পটভূমিতে নরমভাবে বাজায়, এবং তারপরে স্ক্রিনটি ম্লান হয়ে যায় ...
জেমস বি

1
মার্ক সিমনের উপরে "এটি আপনার ক্যারিয়ারের জন্য বিপজ্জনক হতে পারে" এর উপরে দুঃখজনক হিসাবে ...
রবার্ট

আমার কোনও ক্লু ব্যাকগ্রাউন্ডের বিবরণগুলি এতটা ভাবপূর্ণ হতে পারে না: পি
অনুরাগ

@ রবার্ট আমি উদ্ধৃতিটি খোঁজার চেষ্টা করছি, উপরে তিনি কোথায় বলেছেন?
লিয়াং

8

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

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


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

5

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

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

  • আপনাকে দলকে প্রশিক্ষণ দিতে হবে
  • আপনাকে আপনার অ্যাপ্লিকেশন পরিবর্তন করতে হবে (যার মধ্যে ঝুঁকি রয়েছে)

সাধারণভাবে আপনাকে সময় এবং অর্থ বিনিয়োগ করতে হবে , তার পাশেই, কোনও ডাউনসাইড নেই, সত্যই!


3

কোড পাঠযোগ্যতা। এক্সএমএল ফাইলগুলিতে নির্ভরতাগুলি লুকানো থাকায় আপনি কোড প্রবাহটি সহজেই বের করতে পারবেন না।


9
নির্ভরতা ইনজেকশনের জন্য আপনার এক্সএমএল কনফিগারেশন ফাইলগুলি ব্যবহার করার দরকার নেই - একটি ডিআই কনটেইনার চয়ন করুন যা কোডটিতে কনফিগারেশন সমর্থন করে।
হাভার্ড এস

8
নির্ভরতা ইনজেকশন অগত্যা এক্সএমএল ফাইল বোঝায় না। মনে হচ্ছে জাভাতে এখনও এটি হতে পারে, কিন্তু। নেট-এ আমরা বহু বছর আগে এই সংযুক্তিকে ত্যাগ করেছি।
মার্ক সিমেন

6
অথবা কোনও ডিআই কনটেইনার ব্যবহার করবেন না।
জেসি মিলিকান

যদি আপনি জানেন কোডটি ডিআই ব্যবহার করছে তবে আপনি সহজেই ধরে নিতে পারেন কে নির্ভরতা নির্ধারণ করে।
বোঝো

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

2

দুটি জিনিস:

  • কনফিগারেশনটি বৈধ কিনা তা পরীক্ষা করতে তাদের অতিরিক্ত সরঞ্জাম সহায়তা প্রয়োজন।

উদাহরণস্বরূপ, ইন্টেলিজ (বাণিজ্যিক সংস্করণ) এর একটি স্প্রিং কনফিগারেশনের বৈধতা যাচাইয়ের জন্য সমর্থন রয়েছে এবং কনফিগারেশনে টাইপ লঙ্ঘনের মতো ত্রুটিগুলি চিহ্নিত করা হবে। এই জাতীয় সরঞ্জাম সমর্থন ব্যতীত, আপনি পরীক্ষা চালানোর আগে কনফিগারেশনটি বৈধ কিনা তা পরীক্ষা করতে পারবেন না।

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

  • এটি প্রোগ্রামগুলির গ্লোবাল স্ট্যাটিক বিশ্লেষণকে খুব কঠিন করে তুলেছে।

স্প্রিং বা গুইসের মতো ফ্রেমওয়ার্কগুলি ধারক দ্বারা তৈরি করা অবজেক্ট গ্রাফটি কেমন হবে তা স্থিরভাবে নির্ধারণ করা কঠিন করে তোলে। যদিও তারা ধারক শুরু হওয়ার সাথে সাথে কোনও বস্তু গ্রাফ তৈরি করে, তারা দরকারী API গুলি সরবরাহ করে না যা / যা / তৈরি করা অবজেক্টের গ্রাফ বর্ণনা করে।


1
এটি পরম ষাঁড়। নির্ভরতা ইনজেকশন একটি ধারণা, এটি একটি ফ্রিকেন ফ্রেমওয়ার্কের প্রয়োজন হয় না। আপনার যা দরকার তা নতুন। ডাচ বসন্ত এবং এই সমস্ত কৃপণতা, তারপরে আপনার সরঞ্জামগুলি ঠিকঠাকভাবে কাজ করবে, এবং আপনি আপনার কোডটিকে আরও ভালভাবে রিফেক্টর করতে সক্ষম হবেন।
tea

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

আহ। সেক্ষেত্রে আমি সুখে আমার বিরক্তি ফিরিয়ে নিই। ক্ষমাপ্রার্থী।
4tea

2

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


1

এটি অ্যাপ্লিকেশন প্রারম্ভের সময় বাড়াতে পারে কারণ আইওসি ধারকটির একটি নির্ভরযোগ্যতা সঠিক উপায়ে সমাধান করা উচিত এবং এর জন্য মাঝে মাঝে বেশ কয়েকটি পুনরাবৃত্তি করা প্রয়োজন।


3
একটি চিত্র দেওয়ার জন্য, একটি ডিআই কনটেইনারের প্রতি সেকেন্ডে একাধিক হাজার নির্ভরতা সমাধান করা উচিত। ( কোডিংস্টিনট্যাক্ট ২০০২ / ২০০৮ / ৫ / )) ডিআই পাত্রে স্থগিত তাত্ক্ষণিক অনুমতি দেয় allow পারফরম্যান্স (এমনকি বিশাল অ্যাপ্লিকেশনগুলিতেও) কোনও সমস্যা হওয়া উচিত নয়। বা কমপক্ষে পারফরম্যান্সের সমস্যাটি সমাধানযোগ্য এবং আইওসি এবং এর কাঠামোর বিরুদ্ধে সিদ্ধান্ত নেওয়ার কারণ নয়।
রবার্ট
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.