যখন নির্ভরতা বিপরীতমুখী নীতিটি প্রয়োগ না করা হয়?

Question

আমি বর্তমানে সলিড বের করার চেষ্টা করছি। সুতরাং নির্ভরতা বিপর্যয় নীতি মানে যে কোনও দুটি শ্রেণির সরাসরি নয়, ইন্টারফেসের মাধ্যমে যোগাযোগ করা উচিত। উদাহরণ: যদি class Aকোনও পদ্ধতি থাকে, যা টাইপের কোনও বস্তুর কাছে পয়েন্টার প্রত্যাশা করে class B, তবে এই পদ্ধতির প্রকৃতপক্ষে কোনও প্রকারের বস্তুর প্রত্যাশা করা উচিত abstract base class of B। এটি ওপেন / ক্লোজ করার জন্যও সহায়তা করে।

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

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

_{অন্য কথায়, কিছু পরিবর্তন করার জন্য, আমাকে পরিবর্তন করতে হবে 1. কলার 2. ইন্টারফেস 3. ঘোষণা 4. বাস্তবায়ন। অজগরটিতে সরাসরি যুগল প্রয়োগে, আমাকে কেবল বাস্তবায়ন পরিবর্তন করতে হবে ।}

Comments

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

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

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

— রোবং

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

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

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

— রোগারিও

Answer 1

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

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

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

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

Comments

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

— কলফুল

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

— jpmc26

এখানে প্রচুর বিরোধী মনোভাব রয়েছে ID সলিড এবং ইয়াজিএনআই কোনও বর্ণালীর দুটি প্রান্ত নয়। তারা চার্টে X এবং Y স্থানাঙ্কের মতো। একটি ভাল সিস্টেমে খুব কম অতিমাত্রায় কোড থাকে (YAGNI) এবং সলিড নীতি অনুসরণ করে।

— স্টিফেন

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

— অ্যারোনআউট

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

— স্টিভ জেসোপ

Answer 2

সাধারণ মানুষের কথায়:

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

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

অন্যদিকে, ইন্টারফেস এবং OOD সহ প্রোগ্রামিং প্রোগ্রামিংয়ের মাঝে মাঝে বাসি নৈপুণ্যে আনন্দটি ফিরিয়ে আনতে পারে।

কিছু লোক বলে এটি জটিলতা যুক্ত করে তবে আমি মনে করি অপোসাইটটি সত্য। এমনকি ছোট প্রকল্পের জন্যও। এটি টেস্টিং / উপহাসকে আরও সহজ করে তোলে। কোনও caseবিবৃতি বা নেস্টেড থাকলে এটি আপনার কোডকে কম রাখে ifs। এটি সাইক্লোমেটিক জটিলতা হ্রাস করে এবং আপনাকে নতুন উপায়ে চিন্তাভাবনা করে। এটি প্রোগ্রামিংকে বাস্তব-বিশ্বের নকশা এবং উত্পাদনকে আরও সমান করে তোলে।

Comments

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

— স্টেফেনবায়ার

যদি প্রশ্নটি ডিআইপি সম্পর্কে হয় তবে এই উত্তরটি ডিআইয়ের বিষয়ে কেন কথা বলছে? ডিআইপি 1990 এর দশকের ধারণা, যখন ডিআই 2004 এর।

— রোগারিও

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

— রোজারিও

@ রোগিরিও সাধারণত ডিআই ব্যবহার করার সময়, প্রতিটি শ্রেণি পৃথক ইন্টারফেস প্রয়োগ করে না। বেশ কয়েকটি ক্লাস দ্বারা প্রয়োগ করা একটি ইন্টারফেস সাধারণ।

— তুলাইনস কর্ডোভা

@ রোগিরিও আমি আমার উত্তর সংশোধন করেছি, প্রতিবার আমি ডিআই উল্লেখ করেছি ডিআইপি meant

— তুলিনস কর্ডোভা

Answer 3

নির্ভরতা বিপরীতমুখী ব্যবহার করুন যেখানে এটি উপলব্ধি করে।

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

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

দুটি জায়গা রয়েছে যেখানে আমার মতে স্বয়ংক্রিয়ভাবে ডিআই ব্যবহার করা উচিত:

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

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

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

ডিআই একটি দুর্দান্ত সরঞ্জাম, তবে যে কোনও * সরঞ্জামের মতো এটিও অতিরিক্ত ব্যবহার বা অপব্যবহার করা যায়।

_{* উপরোক্ত নিয়ম ব্যতীত: একটি প্রতিদানমূলক করাত হ'ল যে কোনও কাজের জন্য উপযুক্ত সরঞ্জাম। এটি যদি আপনার সমস্যার সমাধান না করে তবে এটি এটি সরিয়ে ফেলবে। স্থায়িভাবে.}

Comments

"আপনার সমস্যা" যদি দেয়ালের একটি গর্ত হয় তবে কী হবে? একটি করাত এটি সরাবে না; এটি আরও খারাপ করে দেবে। ;)

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

@ ম্যাসনওহিলার একটি শক্তিশালী এবং মজাদার ব্যবহারের সাথে দেখেছি, "প্রাচীরের গর্ত" "দরজা" রূপান্তর করতে পারে যা একটি দরকারী সম্পদ :-)

গর্তের জন্য প্যাচ তৈরি করতে আপনি কী কর ব্যবহার করতে পারবেন না?

— জেফো

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

— সুপারক্যাট

যদি প্রশ্নটি ডিআইপি সম্পর্কে হয় তবে এই উত্তরটি ডিআইয়ের বিষয়ে কেন কথা বলছে? ডিআইপি 1990 এর দশকের ধারণা, যখন ডিআই 2004 এর।

— রোজিরিও

Answer 4

আমার কাছে মনে হচ্ছে মূল প্রশ্নটি ডিআইপি-র পয়েন্টের কিছু অংশ হারিয়েছে।

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

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

মনে রাখবেন যে ডিআইপি বলেছে যে "উচ্চ-স্তরের মডিউলগুলি নিম্ন-স্তরের মডিউলগুলির উপর নির্ভর করে না Both উভয়েরই বিমূর্ততার উপর নির্ভর করা উচিত" "

আপনি যখন Z এর কী ক্লাসের প্রয়োজন এবং কীভাবে এটি যা প্রয়োজন তা পেতে চায় তার কাজ শেষ করার পরে আপনি বিশদটি পূরণ করতে পারেন। অবশ্যই, কখনও কখনও Z জেনে পরিবর্তন করা দরকার, তবে 99% সময় এটি হবে না।

কখনই ডি ক্লাস হবে না কারণ আপনি লিখেছিলেন যে জেডকে লেখার আগে এ, বি এবং সি দরকার। প্রয়োজনীয়তার পরিবর্তন সম্পূর্ণ আলাদা গল্প।

Answer 5

সংক্ষিপ্ত উত্তরটি "প্রায় কখনই নয়", তবে বাস্তবে এমন কয়েকটি জায়গা রয়েছে যেখানে ডিআইপি কোনও অর্থই দেয় না:

1. কারখানা বা বিল্ডার, যার কাজ এটি অবজেক্ট তৈরি করা। এগুলি মূলত IoC- কে পুরোপুরি আলিঙ্গিত করে এমন একটি সিস্টেমে "লিফ নোডস"। এক পর্যায়ে, কিছুতে আসলে আপনার অবজেক্ট তৈরি করতে হয় এবং এটি করার জন্য অন্য কোনও কিছুর উপর নির্ভর করতে পারে না। অনেক ভাষায়, একটি আইওসি পাত্রে এটি আপনার জন্য করতে পারে তবে কখনও কখনও আপনাকে এটি পুরানো পদ্ধতিতে করা দরকার।

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

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

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

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

আরও থাকতে পারে; এগুলি আমি কিছুটা ঘন ঘন ভিত্তিতে দেখি ।

Comments

কীভাবে "যে কোনও সময় আপনি গতিশীল ভাষায় কাজ করছেন"?

— কেভিন

কোন? আমি জাভাস্ক্রিপ্টে প্রচুর কাজ করি এবং এটি এখনও সেখানে সমানভাবে কার্যকর হয়। যদিও সলিডের "ও" এবং "আমি" কিছুটা ঝাপসা হয়ে উঠতে পারে।

— অ্যারোনআউট

হু ... আমি পাই যে পাইথনের প্রথম শ্রেণির ধরণের হাঁসের টাইপিংয়ের সাথে এটি আরও কম প্রয়োজনীয় করে তোলে।

— কেভিন

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

— অ্যারোনআউট

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

— অ্যারোনআট

Answer 6

কিছু লক্ষণ আপনি একটি স্তরের খুব অণুতে ডিআইপি প্রয়োগ করতে পারেন, যেখানে এটি মান সরবরাহ করে না:

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

আপনি যদি যা দেখছেন এটি যদি হয় তবে আপনি কেবল জেড কল সি সরাসরি করতে এবং ইন্টারফেসটি এড়িয়ে যাওয়াই ভাল।

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

আরও দেখুন এই ব্লগ পোস্টে ।

Answer 7

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

নির্ভরতা বিপরীতকরণের বিষয়টি আপনি কী নির্বাচনকে নির্ভর করে এমন নির্ভরশীলতাগুলি নির্বাচনকে উল্টে দিন । যেগুলি A থেকে B তে সি যেতে হবে তারা এখনও তা করে, এটি সি থেকে A তে যাচ্ছিল যা এখন A থেকে C তে যায় go

ফলাফলটি নির্ভরতা গ্রাফ হওয়া উচিত যা চক্র থেকে মুক্ত - একটি ডিগ। এমন বিভিন্ন সরঞ্জাম রয়েছে যা এই সম্পত্তিটি পরীক্ষা করবে এবং গ্রাফটি আঁকবে।

পূর্ণাঙ্গ ব্যাখ্যার জন্য, এই নিবন্ধটি দেখুন :

নির্ভরতা ইনভার্সন নীতিটি সঠিকভাবে প্রয়োগের সারমর্মটি হ'ল:

কোড / পরিষেবা / ... বিভক্ত করুন আপনি একটি ইন্টারফেস এবং প্রয়োগের উপর নির্ভর করে। ইন্টারফেসটি কোডটি ব্যবহার করে জার্গনে নির্ভরতা পুনর্গঠন করে এটি প্রয়োগ করে এটি এর অন্তর্নিহিত কৌশলগুলির ক্ষেত্রে প্রয়োগ করে।

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