নির্ভরতা ইনজেকশন: এটি কীভাবে বিক্রি করবেন [বন্ধ]


95

এটি জানা যাক যে আমি নির্ভরতা ইনজেকশন (ডিআই) এবং স্বয়ংক্রিয় পরীক্ষার একটি বড় অনুরাগী । আমি এটি সম্পর্কে সারা দিন কথা বলতে পারে।

পটভূমি

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

সহ্য করার ক্ষমতা

সমস্যাটি ছিল আমাদের দলে, ডিআই নিষিদ্ধ। এটি কয়েকবার উত্থাপিত হয়েছে, তবে দেবতারা তাতে সম্মতি দেয় না। তবে তা আমাকে নিরুৎসাহিত করেনি।

আমার চাল

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

প্রতিক্রিয়া

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

অবশেষে, আমার প্রশ্ন

আমার পরিস্থিতি আপনি কীভাবে সামলাবেন? আমি আমার ধারণাগুলি উপস্থাপনে ভাল নই এবং আমি কীভাবে লোকেরা তাদের যুক্তি উপস্থাপন করবে তা জানতে চাই।

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

হালনাগাদ

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

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


64
আপনার মতো মনে হচ্ছে অন্য কোনও সংস্থায় যেতে হবে ...
সারদাথ্রিয়ন

24
ডিআই ব্যবহার করা (ইউনিট পরীক্ষাগুলি অন্তত জাভা, সি #, ...) প্রায় প্রাকৃতিক ফলাফল। আপনার সংস্থা ইউনিট পরীক্ষা ব্যবহার করে?
সেবাস্তেঞ্জিগার

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

34
"... আমি এটি নিয়ে সারা দিন কথা বলতে পারতাম।" দিনের কিছু সাদা কাগজে কৌতূহলবশত মেনে চলার কারণে আপনার মতো মনে হচ্ছে যে কোনও কিছুকে ঘৃণা করা যায় যা প্রায়ই ঘৃণা করা হয় সে সম্পর্কে আপনার মনোভাব বন্ধ করা উচিত।

21
এর আওয়াজ থেকে, আপনার সহকর্মীদের উদ্দেশ্যমূলক যুক্তি রয়েছে যা ডিআই কনটেইনার ব্যবহারের বিরুদ্ধে কথা বলে: "আমাদের জটিলতার এই স্তরটি ইতিমধ্যে একটি জটিল প্রকল্পে যুক্ত করার দরকার নেই" - তারা কি ঠিক আছে? কি জুড়েছে জটিলতা থেকে আসল জিনিসটি সুবিধাই? যদি তা হয় তবে তর্ক করা সম্ভব হওয়া উচিত। তাদের দাবি যে "ডিআই হ'ল একটি সুবিধাহীন জটিলতা” " আপনি যদি কোনও উদ্দেশ্যমূলক সুবিধা দেখাতে পারেন তবে আপনার এটি সহজেই জিততে হবে, না? অন্যান্য মন্তব্যে পরীক্ষার বিষয়টি বেশ প্রায়ই উল্লেখ করা হয়; তবে পরীক্ষার জন্য মৌলিকভাবে ডিআইয়ের প্রয়োজন হয় না , যদি না আপনার মক (যা দেওয়া হয় না) প্রয়োজন হয়।
কনরাড রুডল্ফ 23'12

উত্তর:


62

কিছু পাল্টা যুক্তি গ্রহণ:

"আমরা এটি সহজ রাখতে চাই, যদি সম্ভব হয় তবে সমস্ত কিছুকে একটি সমাবেশে স্টাফ করতে পারি DI

"এটি এমন নয় যে আমরা উপাদানগুলির বিভিন্ন বাস্তবায়নে প্লাগ ইন করব"।

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

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

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

আমি এখানে যা বলছি তা হ'ল ডিআই এর পক্ষে ডিআইয়ের পক্ষে তর্ক করার চেয়ে ডিআই যে উপকারগুলি নিয়ে আসে সেগুলি আপনার সমাধান করার দরকার। লোকেরা এই বিবৃতিতে রাজি হয়ে:

"আমাদের এক্স, ওয়াই এবং জেড দরকার"

আপনি তারপর সমস্যা স্থানান্তর। আপনাকে নিশ্চিত করতে হবে যে ডিআই-র এই বিবৃতিটির উত্তর। এটি করে আপনি সহকর্মীরা তাদের উপর চাপিয়ে দেওয়া বোধ করার পরিবর্তে সমাধানটির মালিক হবেন।


+1 টি। সংক্ষিপ্ত এবং বিন্দু থেকে. দুর্ভাগ্যক্রমে, মেলের সহকর্মীরা যে যুক্তি দিয়েছিলেন, সেগুলি থেকে তিনি তাদের বোঝাতে একটি কঠিন সময় পাবে যে এটি কেবল চেষ্টা করাও মূল্যবান - স্পোক তার উত্তরে যা বলেছিলেন, প্রযুক্তিগত সমস্যার চেয়ে আরও বেশি লোকের সমস্যা।
প্যাট্রিক ieউইক

1
@ ট্রস্টমে-আইনেডম ডক্টর - ওহ আমি সম্মত হই যে এটি একটি জনগণের সমস্যা, তবে এই পদ্ধতির সাহায্যে আপনি নিজের স্বার্থে ডিআইয়ের পক্ষে তর্ক করার চেয়ে সুবিধা উপস্থাপন করছেন।
ক্রিসএফ

সত্য এবং আমি তার ভাগ্য কামনা করছি, বিকাশকারী হিসাবে তার জীবন যথাযথ টেস্টাবিলিটি ইত্যাদির সাথে সহজতর হবে :)
প্যাট্রিক

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

প্রকৃতপক্ষে +1 খুব সহায়ক। আমি বলব না যে ইউনিট পরীক্ষার জন্য ডিআই নিরঙ্কুশভাবে আবশ্যক তবে এটি জিনিসগুলিকে অনেক সহজ করে দিয়েছে।
মেল

56

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

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


10
একটি রাজনৈতিক / গোপনীয়তার অচলাবস্থার জন্য +1 একটি ব্যবহারিক কাজ
বি

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

2
একমাত্র সমস্যা হল নির্ভরশীলদের মধ্যে ঢিলেঢালাভাবে-কাপল্ড নির্ভরতা ক্ষণস্থায়ী প্যাটার্ন হয় দ্বি। আইওসি, বা আলগা-যুগল নির্ভরতা সমাধানের জন্য একটি "ধারক" ব্যবহার, স্বয়ংক্রিয় ডিআইআই হয়।
কিথস

51

যেহেতু আপনি জিজ্ঞাসা করেছেন, আমি আপনার দলের পক্ষে ডিআই-এর বিরুদ্ধে থাকব।

নির্ভরতা ইনজেকশনের বিরুদ্ধে মামলা

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

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

ডিআই ব্যবহার করার সময় কোনও প্রোগ্রামকে সঠিক বলে প্রমাণ করা অনেক কঠিন। প্রচুর লোকের যুক্তি রয়েছে যে ডিআই ব্যবহার করে প্রোগ্রামগুলি পরীক্ষা করা সহজ , তবে প্রোগ্রাম টেস্টিং কখনই বাগের অভাবে প্রমাণ করতে পারে না । (দ্রষ্টব্য যে লিঙ্কযুক্ত কাগজটি প্রায় 40 বছরের পুরানো এবং এর মধ্যে কিছু আরকেন রেফারেন্স রয়েছে এবং কিছু পুরানো অনুশীলন উদ্ধৃত করা হয়েছে, তবে অনেকগুলি বুনিয়াদি বিবৃতি এখনও সত্য hold বিশেষত, পি <= পি ^ n, যেখানে পি সিস্টেমটি ত্রুটিমুক্ত, সম্ভাব্যতা হ'ল পি সম্ভাব্যতা হ'ল কোনও সিস্টেম উপাদান ত্রুটিমুক্ত, এবং এন উপাদানগুলির সংখ্যা course অবশ্যই, এই সমীকরণটি প্রশমিত করা হয়েছে, তবে এটি একটি গুরুত্বপূর্ণ সত্যকে নির্দেশ করে)) ফেসবুক আইপিও চলাকালীন নাসডাকের ক্র্যাশ হ'ল একটি সাম্প্রতিক উদাহরণ, যেখানেতারা দাবি করেছিল যে তারা কোডটি পরীক্ষায় এক হাজার ঘন্টা ব্যয় করেছে এবং ক্র্যাশ হওয়ার কারণে যে বাগগুলি রয়েছে তা এখনও প্রকাশ করতে পারেনি। 1,000 ঘন্টা অর্ধেক ব্যক্তি-বছর, তাই তারা পরীক্ষায় ঝাপটা পড়েছিল এমনটি হয় না।

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

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

নির্ভরতা বিপর্যয়ের জন্য নির্ভরতা ইনজেকশনও প্রয়োজন হয় না । নির্ভরতা বিপর্যয় বাস্তবায়নের জন্য আপনি সহজেই স্থিতিশীল কারখানার পদ্ধতি ব্যবহার করতে পারেন। এটি আসলে, এটি 1990 এর দশকে কীভাবে হয়েছিল।

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


1
আমি দ্বিমত পোষণ করছি, জটিলতা হ্রাস করা সম্ভব। আমি জানি কারণ আমি এটা করেছি। অবশ্যই, কিছু সমস্যা / প্রয়োজনীয়তা জটিলতা জোর করে, তবে সর্বোপরি এগুলির বেশিরভাগ প্রচেষ্টা দিয়ে মুছে ফেলা যায়।
রিকি ক্লার্কসন

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

2
@ লাই, কোডে ডিআইএ কনফিগার করা আরও কম দরকারী। ডিআই-র সর্বাধিক গৃহীত সুবিধার মধ্যে একটি হ'ল কোডটি পুনরায় সংবিধান না দিয়ে পরিষেবা বাস্তবায়ন পরিবর্তন করার ক্ষমতা এবং যদি আপনি ডিআইডি কোডে কনফিগার করেন তবে আপনি এটি হারাবেন।
ওল্ড প্রো

7
@ ওল্ডপ্রো - কোড কনফিগার করতে টাইপ-সুরক্ষার সুবিধা রয়েছে এবং বেশিরভাগ নির্ভরতা স্থির থাকে এবং বাহ্যিকভাবে সংজ্ঞায়িত হওয়ার কোনও সুবিধা নেই।
লি 21

3
@ লী যদি নির্ভরতা স্থির থাকে তবে ডিআই এর মাধ্যমে প্রদত্ত চৌরাস্তা ছাড়াই তারা কেন প্রথমে কঠোর কোডড হয় না?
কনরাড রুডলফ

25

আপনার সহকর্মীরা আপনার প্রশ্নে যা বলেছে তা প্রদত্ত যে সমস্যাটি আপনার কাছে হয়েছে তা বলার জন্য আমি দুঃখিত, প্রযুক্তিগত পরিবর্তে রাজনৈতিক প্রকৃতির is দুটি মন্ত্র রয়েছে যা আপনার মনে রাখা উচিত:

  • "এটি সর্বদা একটি সমস্যা"
  • " পরিবর্তন ভীতিজনক"

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

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

যদি আপনি দেখতে পান যে বর্তমান সংস্থা সংস্কৃতি আপনার সাথে কাজ করছে না তবে আপনার পরবর্তী কাজের সাক্ষাত্কারের জন্য জিজ্ঞাসা করার জন্য অন্য একটি জিনিস কমপক্ষে আপনি জানেন। ;-)


23

ডিআই ব্যবহার করবেন না। ভুলে যাও.

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

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


3
প্রকল্পের পাশাপাশি বর্ধনের জন্য +1 এবং "একে ডিআই বলবেন না"
কেভিন ম্যাককর্মিক

5
আমি একমত, কিন্তু শেষ পর্যন্ত, এটি ডিআই। এটি কেবল একটি ডিআই কনটেইনার ব্যবহার করছে না; এটি এক জায়গায় কেন্দ্রীকরণ না করে কলারের কাছে বোঝা প্রেরণ করছে। তবে এটি ডিআই এর পরিবর্তে "বহিরাগত নির্ভরতা" বলা স্মার্ট হবে।
হুয়ান মেন্ডেস

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

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

22

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

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

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

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

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

কিছু জায়গা রয়েছে যা ডিআই ব্যবহার করে বোঝায়:

  • ডেটা অ্যাক্সেস লেয়ারটি ডেটা গল্প করার কৌশলগুলি বদলানোর জন্য
  • প্রমাণীকরণ এবং অনুমোদন স্তর।
  • ইউজার ইন্টারফেসের জন্য থিমস
  • সেবা
  • আপনার নিজস্ব সিস্টেম বা তৃতীয় পক্ষ ব্যবহার করতে পারে এমন প্লাগইন এক্সটেনশন পয়েন্ট।

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

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

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


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

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

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

19

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

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

কেবল মনে রাখবেন যে এই পরিস্থিতিগুলিতে আপস করা জরুরি।


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

সমঝোতার জন্য +1। যদি কেউ আপোস করতে না চায় তবে সবাই কষ্ট ভোগ করে।
Tjaart

14

আমি মনে করি না যে আপনি আর ডিআই বিক্রি করতে পারবেন না, কারণ এটি একটি স্পষ্টবাদী সিদ্ধান্ত (বা হিসাবে @ স্পাইকে একে আরও বিনয়ী, রাজনৈতিক বলে অভিহিত করেছে )।

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

আপনার চেয়ে বেশি রাজনৈতিক ক্ষমতা সম্পন্ন কেউ ডিআই ব্যবহার না করার সিদ্ধান্ত নিয়েছে (সম্ভবত ভুল)।

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

বিশ্লেষণ

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

এই সমস্যাটি কি আসলেই সম্পর্কে

  • আমরা ডিআই চাই না ?

বা এই সম্পর্কে আরও হয়

  • tdd / ইউনিটেস্টেটিং কি সম্পদের অপচয় ?

[হালনাগাদ]

আপনি যদি প্রকল্প পরিচালনার দৃষ্টিতে ক্লাসিক ভুল থেকে আপনার প্রকল্পটি দেখেন তবে আপনি দেখতে পাবেন

#12: Politics placed over substance.
#21: Inadequate design. 
#22: Shortchanged quality assurance.
#27: Code-like-hell programming.

অন্যরা দেখতে পায়

#3: Uncontrolled problem employees. 
#30: Developer gold-plating. 
#32: Research-oriented development. 
#34: Overestimated savings from new tools or methods. 

আমরা বর্তমানে আমাদের দলে কোনও ইউনিট টেস্টিং করছি না। আমি সন্দেহ করি যে আপনার শেষ বক্তব্যটি স্পট রয়েছে। আমি কয়েকবার ইউনিট টেস্টিং এনেছি তবে কেউই এর প্রতি প্রকৃত আগ্রহ দেখায় নি এবং আমরা কেন এটি গ্রহণ করতে পারি না তার সবসময় কারণ রয়েছে।
মেল

10

যদি আপনি নিজেকে নিজের দলে কোনও নীতি "বিক্রয়" করতে দেখেন তবে আপনি সম্ভবত ইতিমধ্যে বেশ কয়েক মাইল দূরে ভুল পথে গেছেন।

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

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

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

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

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

আপনি যখন কোনও ধারণাটি সঠিকভাবে বিক্রি করেন তখন লোকেরা জানতে পারবে না যে আপনি কোনও কিছুর বিষয়ে তাদের নিশ্চিত করেছেন।


8

অবশ্যই, ইনভার্শন অফ কন্ট্রোল (আইওসি) এর প্রচুর সুবিধাগুলি রয়েছে: এটি কোডটি সহজ করে তোলে, কিছু যাদু যুক্ত করে যা সাধারণ কাজগুলি করে চলেছে ইত্যাদি etc.

যাহোক:

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

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

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

  4. আইওসি ব্যবহারটি সাধারণত ইনজেকশন নির্ভরতা দিয়ে শেষ হয় না, এটি অগণিত প্রক্সি দিয়ে শেষ হয় এবং আপনি স্ট্যাক ট্রেসকে শত শত লাইন গণনা করেন, যার মধ্যে 90% প্রক্সি এবং প্রতিফলনের মাধ্যমে প্রার্থনা করে। এটি স্ট্যাক ট্রেস বিশ্লেষণকে ব্যাপকভাবে জটিল করে তোলে।

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

আমার পরামর্শ, আপনি যদি নিজের চাকরিতে আইওসি ব্যবহার বাধ্যতামূলক করেন তবে অন্য কেউ যে কোনও অপব্যবহার করবেন তার জন্য আপনাকে দায়বদ্ধ করা হবে;)


প্রতিটি শক্তিশালী সরঞ্জামের মতো +1 এর সহজেই এটির অপব্যবহার করা হয় এবং কখন এটি ব্যবহার করবেন না তা আপনার বুঝতে হবে।
ফিল

4

আমি মনে করি ক্রিসএফ সঠিক কিছু আছে। নিজে ডিআই বিক্রি করবেন না। কোডটি ইউনিট পরীক্ষার সম্পর্কে ধারণাটি বিক্রি করুন।

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

public class UserController {
    public UserController() : this (new UserRepository()) {}

    public UserController(IUserRepository userRepository) {
        ...
    }

    ...
}

এটি আপনাকে ব্যবহারকারীর সংগ্রহস্থলের প্রকৃত বাস্তবায়ন থেকে decoupled ইউনিট পরীক্ষা লেখার অনুমতি দেয় allows ক্লাসটি এখনও আপনার জন্য এটি তৈরি করতে কোনও ডিআই কনটেইন ছাড়াই কাজ করে। প্যারামিটারলেস কনস্ট্রাক্টর এটি ডিফল্ট সংগ্রহস্থল দ্বারা তৈরি করবে।

যদি আপনি সহকর্মীরা দেখতে পান যে এটি আরও ক্লিনার পরীক্ষার দিকে নিয়ে যায়, সম্ভবত তারা বুঝতে পারে যে এটি একটি আরও ভাল উপায়। হতে পারে আপনি তাদেরকে এভাবে কোডিং শুরু করতে পারেন।

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


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

2
সেক্ষেত্রে আমি বলব এখানেই আসল সমস্যা। ইউনিট পরীক্ষার প্রতিরোধের মূলটি সন্ধান করুন এবং এটি আক্রমণ করুন। আপাতত ডিআই কে মিথ্যা বলা যাক। পরীক্ষা আরও গুরুত্বপূর্ণ আইএমএইচও।
খ্রিস্টান হর্সডাল

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

এই ধারণাটি সত্যিই দুর্দান্ত ... পরীক্ষার জন্য দুর্দান্ত বিক্রয়
25:48

2

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

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

সুতরাং আমার পরামর্শটি হ'ল প্রথমে চ্যাম্পিয়ন ইউনিট টেস্টিং এবং রিফ্যাক্টরিং করার পরে, পরিবর্তে ডিআই এবং শেষ পর্যন্ত ডিআই পাত্রে পরিচয় করিয়ে দিন।


2

আমি এখানে আপনার দল থেকে কিছু বড় সংখ্যা শুনতে পাচ্ছি:

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

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

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

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

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

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

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

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

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


1

অনুমোদিত না হলে কোনও প্রকল্পে অতিরিক্ত বৈশিষ্ট্যগুলি (ডিআই এর মতো) যুক্ত করার বিষয়ে সতর্কতা অবলম্বন করুন। আপনার যদি সময়সীমা সহ একটি প্রকল্প পরিকল্পনা থাকে তবে আপনি অনুমোদিত বৈশিষ্ট্যগুলি শেষ করতে পর্যাপ্ত সময় না পাওয়ার ফাঁদে পড়তে পারেন।

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

আপনি যদি ডিআই ব্যবহার না করেন তবে আপনি সৃজনশীল পেতে পারেন এবং আপনার কোডটি ডিআই- "প্রস্তুত" করতে পারেন। অন্যান্য কনস্ট্রাক্টরকে কল করতে প্যারামিটারলেস কনস্ট্রাক্টর ব্যবহার করুন:

MyClassConstructor()
{
    MyClassConstructor(new Dependency)
    Property = New Dependent Property
}

MyClassConstructor(Dependency)
{
    _Dependency = Dependency
}

0

আমি মনে করি তাদের বৃহত্তম উদ্বেগগুলির মধ্যে একটি আসলে আসলে বিপরীত: ডিআই প্রকল্পটিকে জটিল করে তুলছে না। বেশিরভাগ ক্ষেত্রে এটি প্রচুর জটিলতা হ্রাস করছে।

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

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

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

সুতরাং, ডিআই প্রকল্পটিকে জটিল করে তুলছে না, উপাদানগুলি আরও সহজ করে এটি সহজতর করছে।

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

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


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

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

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

0

"আমরা এটি সহজ রাখতে চাই, যদি সম্ভব হয় তবে সমস্ত কিছুকে একটি সমাবেশে স্টাফ করতে পারি DI

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

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


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

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

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

0

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


0

যদিও ডিআইকে উত্সাহিত করে এমন একটি হ'ল ইউনিট টেস্টিং, তবে আমি বিশ্বাস করি যে এটি কিছু ক্ষেত্রে জটিলতার স্তর যুক্ত করে।

  • টেস্টিংয়ে গাড়ি থাকা ভাল, তবে টেস্টিংয়ে গাড়ি ও মেরামত করা শক্তের চেয়ে মেরামত সহজ than

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

  • আমাদের যদি 5 টি বিভিন্ন ফাংশন করার পদ্ধতি থাকে

    ডিআই-লোকেরা বলে:

    • উদ্বেগ কোন বিচ্ছেদ। [তাতে সমস্যা কী? তারা এটিকে খারাপ দেখানোর চেষ্টা করছেন, যা যুক্তি এবং প্রোগ্রামিংয়ে দ্বন্দ্ব এবং ভুল-প্রত্যাশা এড়াতে এবং কোড পরিবর্তনের প্রভাব সহজেই দেখতে সহজেই একে অপরের কাছ থেকে কী করছে তা জানা আরও ভাল, কারণ আমরা আপনার সমস্ত কিছুই তৈরি করতে পারি না একে অপরের সাথে সম্পর্কিত নয় এমন বস্তুগুলি 100% বা কমপক্ষে আমরা এটিকে গ্যারান্টি দিতে পারি না - যদি না কেন রিগ্রেশন টেস্টিং গুরুত্বপূর্ণ?}]
    • জটিল [তারা ডিফল্ট থাকতে "দর্শনের পাশাপাশি সেটিংসের (এক্সএমএল বা অভিধান) এর উপর ভিত্তি করে প্রয়োজনীয় ফাংশনের জন্য ক্লাস তৈরি করার জন্য একটি করে ফাংশন পরিচালনা করার জন্য অতিরিক্ত আরও পাঁচটি ক্লাস এবং অতিরিক্ত ক্লাস (ধারক) হ্রাস করে জটিলতা হ্রাস করতে চায়" বা না "আলোচনা, ...] তারপরে তারা এই জটিলতাটিকে ধারক এবং কাঠামোর দিকে নিয়ে গিয়েছিল, [আমার কাছে মনে হয় এটিকে পরিচালনা করার জন্য ভাষার জটিলতার সমস্ত জটিলতা সহ এক জায়গা থেকে দুটি জায়গায় জটিলতা চলে আসা। ]

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

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

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