ইন্টারফেস বিচ্ছিন্নতার নীতি বলে:
কোনও ক্লায়েন্টকে যে পদ্ধতিগুলি ব্যবহার করে না তার উপর নির্ভর করতে বাধ্য করা উচিত। আইএসপি ইন্টারফেসগুলি বিভক্ত করে তোলে যা খুব ছোট এবং আরও নির্দিষ্ট একটিতে খুব বড় হয় যাতে ক্লায়েন্টদের কেবল তাদের আগ্রহী পদ্ধতিগুলি সম্পর্কে জানতে হবে।
এখানে কয়েকটি উত্তরবিহীন প্রশ্ন রয়েছে। এক:
কত ছোট?
তুমি বলো:
বর্তমানে আমি মডিউলটির ক্লায়েন্টগুলির প্রয়োজনীয়তার উপর নির্ভর করে নেমস্পেসকে ভাগ করে এটি মোকাবিলা করছি।
আমি এই ম্যানুয়াল হাঁস টাইপিং কল । আপনি ইন্টারফেসগুলি তৈরি করেন যা কেবল ক্লায়েন্টের প্রয়োজন তা প্রকাশ করে। ইন্টারফেস পৃথককরণের নীতিটি কেবল ম্যানুয়াল হাঁসের টাইপিং নয়।
তবে আইএসপি কেবল "সুসংগত" রোল ইন্টারফেসের জন্য কল নয় যা পুনরায় ব্যবহার করা যেতে পারে। কোনও "সুসঙ্গত" রোল ইন্টারফেস ডিজাইন তার নিজস্ব ভূমিকা প্রয়োজনের সাথে কোনও নতুন ক্লায়েন্ট সংযোজন থেকে নিখুঁতভাবে রক্ষা করতে পারে না।
আইএসপি হ'ল পরিষেবাগুলিতে পরিবর্তনের প্রভাব থেকে ক্লায়েন্টদের বিচ্ছিন্ন করার একটি উপায়। আপনি পরিবর্তনগুলি করার সাথে সাথে বিল্ডটি আরও দ্রুতগতিতে পরিচালিত করার উদ্দেশ্যে করা হয়েছিল। অবশ্যই এটির অন্যান্য সুবিধাগুলি রয়েছে, যেমন ক্লায়েন্টদের ভাঙা নয়, তবে এটি ছিল মূল বিষয়। যদি আমি পরিষেবাদি count()ফাংশনের স্বাক্ষর পরিবর্তন করি তবে এটি দুর্দান্ত যে ক্লায়েন্টগুলি ব্যবহার count()করে না তাদের সম্পাদনা এবং পুনরায় সংকলনের প্রয়োজন হয় না।
এটি কেন আমি ইন্টারফেস বিভাজন নীতি সম্পর্কে যত্নশীল। এটি বিশ্বাসকে গুরুত্বপূর্ণ হিসাবে গ্রহণ করা এমন কিছু নয়। এটি একটি আসল সমস্যা সমাধান করে।
সুতরাং এটি যেভাবে প্রয়োগ করা উচিত তা আপনার জন্য একটি সমস্যার সমাধান করা উচিত। আইএসপি প্রয়োগের জন্য ব্রেন ডেড রট উপায় নেই যা প্রয়োজনীয় পরিবর্তনের সঠিক উদাহরণ দিয়ে পরাস্ত হতে পারে না। আপনার সিস্টেমটি কীভাবে পরিবর্তিত হচ্ছে সেদিকে নজর দেওয়ার এবং এমন পছন্দগুলি করার সিদ্ধান্ত নেওয়া হবে যা জিনিসগুলিকে শান্ত করে দেবে। বিকল্পগুলি অন্বেষণ করা যাক।
প্রথমে নিজেকে জিজ্ঞাসা করুন: এখনই পরিষেবা ইন্টারফেসে কী পরিবর্তন করা কঠিন? যদি তা না হয় তবে বাইরে যান এবং শান্ত না হওয়া পর্যন্ত খেলুন। এটি কোনও বৌদ্ধিক অনুশীলন নয়। দয়া করে নিশ্চিত হয়ে নিন যে রোগটি রোগের চেয়ে খারাপ নয়।
যদি অনেক ক্লায়েন্ট একই ফাংশনগুলির একই উপসর্গ ব্যবহার করে, তবে এটি "সুসংগত" পুনরায় ব্যবহারযোগ্য ইন্টারফেসের পক্ষে যুক্তি দেয়। সাবসেটটি সম্ভবত একটি ধারণাকে কেন্দ্র করে যা আমরা ক্লায়েন্টকে পরিষেবাটি যে ভূমিকা দিচ্ছে তার ভূমিকা হিসাবে আমরা ভাবতে পারি। এটি যখন কাজ করে তখন দুর্দান্ত। এটি সবসময় কাজ করে না।
যদি অনেক ক্লায়েন্ট বিভিন্ন ধরণের ফাংশন ব্যবহার করে থাকে তবে ক্লায়েন্ট প্রকৃতপক্ষে একাধিক ভূমিকার মাধ্যমে পরিষেবাটি ব্যবহার করছে তা সম্ভব। এটি ঠিক আছে তবে ভূমিকাগুলি দেখতে শক্ত করে তোলে। তাদের সন্ধান করুন এবং তাদের আলাদা করার চেষ্টা করুন। এটি আমাদের কেস 1 এ ফিরিয়ে দিতে পারে ক্লায়েন্ট কেবল একাধিক ইন্টারফেসের মাধ্যমে পরিষেবাটি ব্যবহার করে। দয়া করে পরিষেবাটি ingালাই শুরু করবেন না। যদি এমন কোনও কিছু হয় যা ক্লায়েন্টের কাছে পরিষেবাটি একাধিকবার পাস করার অর্থ। এটি কাজ করে তবে এটি আমাকে প্রশ্ন করে তোলে যদি পরিষেবাটি কাদা মাটির একটি বড় বল না হয় যা ভেঙে ফেলা দরকার।
যদি অনেক ক্লায়েন্ট বিভিন্ন সাবসেট ব্যবহার করেন তবে আপনি এমন কোনও ভূমিকাও দেখতে পান না যাতে ক্লায়েন্টরা একাধিক ব্যবহার করতে পারে তবে আপনার ইন্টারফেসগুলি চারপাশে ডিজাইনের জন্য হাঁসের টাইপিংয়ের চেয়ে ভাল আর কিছু আপনার নেই। ইন্টারফেসগুলি ডিজাইনের এই পদ্ধতিটি নিশ্চিত করে যে ক্লায়েন্ট এমনকি এটি ব্যবহার করছে না এমন একটি ক্রিয়াকলাপের মুখোমুখি হয় নি তবে এটি প্রায় গ্যারান্টি দেয় যে একটি নতুন ক্লায়েন্ট যুক্ত করা সর্বদা একটি নতুন ইন্টারফেস যুক্ত করা জড়িত যা পরিষেবা বাস্তবায়নের জানার দরকার নেই এটি সম্পর্কে ভূমিকাটি ইন্টারফেসকে একত্রিত করে এমন ইন্টারফেস। আমরা কেবল একটি ব্যথার জন্য অন্যের জন্য ব্যবসা করেছি।
যদি অনেক ক্লায়েন্ট বিভিন্ন সাবসেট ব্যবহার করে, ওভারল্যাপ করে, নতুন ক্লায়েন্টদের যোগ করা প্রত্যাশিত যা অপ্রত্যাশিত সাবসেটগুলির প্রয়োজন হবে এবং আপনি পরিষেবাটি ভেঙে ফেলতে ইচ্ছুক নন তবে আরও কার্যকরী সমাধান বিবেচনা করুন। যেহেতু প্রথম দুটি অপশন কাজ করে না এবং আপনি সত্যিই এমন খারাপ জায়গায় আছেন যেখানে কোনও ধরণের অনুসরণ করা হচ্ছে না এবং আরও পরিবর্তন আসছে তখন প্রতিটি ক্রিয়াকে এটির নিজস্ব ইন্টারফেস সরবরাহ করার বিষয়টি বিবেচনা করুন। এখানে শেষ হওয়ার অর্থ এই নয় যে আইএসপি ব্যর্থ হয়েছে। যদি কিছু ব্যর্থ হয় তবে এটি ছিল অবজেক্ট অরিয়েন্টেড দৃষ্টান্ত। একক পদ্ধতি ইন্টারফেস চূড়ান্তভাবে আইএসপি অনুসরণ করে। এটি কীবোর্ড টাইপিংয়ের মোটামুটি বিষয় তবে আপনি হঠাৎ এটি ইন্টারফেসগুলি পুনরায় ব্যবহারযোগ্য করে তুলতে পারেন। আবারও নিশ্চিত হোন
সুতরাং দেখা যাচ্ছে যে তারা সত্যই খুব ছোট পেতে পারে।
আমি এই প্রশ্নটি সবচেয়ে চরম ক্ষেত্রে আইএসপি প্রয়োগ করার চ্যালেঞ্জ হিসাবে গ্রহণ করেছি। তবে মনে রাখবেন যে চরমপন্থা সর্বোত্তমভাবে এড়ানো যায়। অন্যান্য সলিড নীতিগুলি প্রয়োগ করে এমন একটি সুচিন্তিত নকশায় এই সমস্যাগুলি প্রায়শই ঘটে না বা হয় না।
আর একটি উত্তর না দেওয়া প্রশ্ন হ'ল:
এই ইন্টারফেসের মালিক কে?
বারবার আমি "লাইব্রেরি" মানসিকতা বলি তাই ডিজাইন করা ইন্টারফেস দেখতে পাই। আমরা সকলেই বানর-দেখুন-বানর-কর কোডিংয়ের জন্য দোষী হয়েছি যেখানে আপনি কেবল কিছু করছেন কারণ আপনি এটি দেখতে পেলেন। ইন্টারফেসের সাথে আমরা একই জিনিস জন্য দোষী।
যখন আমি একটি লাইব্রেরিতে কোনও শ্রেণীর জন্য নকশাকৃত ইন্টারফেসটি দেখি তখন আমি ভাবতাম: ওহ, এই ছেলেরা ভাল। এটি একটি ইন্টারফেস করার সঠিক উপায় হতে হবে। আমি যা বুঝতে ব্যর্থ হয়েছি তা হ'ল একটি লাইব্রেরির সীমানার নিজস্ব চাহিদা এবং সমস্যা রয়েছে। একটি জিনিস, একটি গ্রন্থাগার তার ক্লায়েন্টদের নকশা সম্পর্কে সম্পূর্ণ অজ্ঞ। প্রতিটি সীমানা এক নয়। এবং কখনও কখনও একই সীমানাও এটি অতিক্রম করার বিভিন্ন উপায় রয়েছে।
ইন্টারফেস ডিজাইনটি দেখার জন্য এখানে দুটি সহজ উপায়:
পরিষেবার মালিকানাধীন ইন্টারফেস। কিছু লোক প্রতিটি ইন্টারফেস ডিজাইন করে কোনও পরিষেবা যা করতে পারে তার সমস্ত কিছুই প্রকাশ করতে। এমনকি আপনি IDE এর মধ্যেও রিফ্যাক্টরিং বিকল্পগুলি সন্ধান করতে পারেন যা আপনি যে শ্রেণীতে এটি খাওয়াবেন তা ব্যবহার করে আপনার জন্য একটি ইন্টারফেস লিখবে।
ক্লায়েন্টের মালিকানাধীন ইন্টারফেস। আইএসপি যুক্তিযুক্ত বলে মনে হচ্ছে এটি সঠিক এবং মালিকানাধীন পরিষেবাটি ভুল। ক্লায়েন্টদের মাথায় রেখে আপনার প্রতিটি ইন্টারফেস ভাঙা উচিত। যেহেতু ক্লায়েন্ট ইন্টারফেসের মালিক এটি এটি সংজ্ঞায়িত করা উচিত।
তাহলে কে ঠিক আছে?
প্লাগিনগুলি বিবেচনা করুন:
এখানে ইন্টারফেসের মালিক কে? ক্লায়েন্টদের? সেবা?
দুটোই বেরিয়ে আসে।
এখানকার রঙগুলি স্তর। লাল স্তর (ডানদিকে) সবুজ স্তর (বাম) সম্পর্কে কিছু জানার কথা নয়। লাল স্তরটি স্পর্শ না করেই সবুজ স্তর পরিবর্তন বা প্রতিস্থাপন করা যেতে পারে। এইভাবে যে কোনও সবুজ স্তরকে লাল স্তরটিতে প্লাগ করা যায়।
আমার কী জানতে হবে এবং কোনটি জানা উচিত নয় তা জানা উচিত knowing আমার কাছে, "কী সম্পর্কে জানে?", এটি একক গুরুত্বপূর্ণ স্থাপত্য সংক্রান্ত প্রশ্ন।
আসুন কিছু শব্দভাণ্ডার পরিষ্কার করা যাক:
[Client] --> [Interface] <|-- [Service]
----- Flow ----- of ----- control ---->
ক্লায়েন্ট এমন কিছু যা ব্যবহার করে।
একটি পরিষেবা এমন কিছু যা ব্যবহার করা হয়।
Interactor উভয় হতে পারে।
আইএসপি বলছে ক্লায়েন্টদের জন্য ব্রেকআপ ইন্টারফেস। ভাল, এখানে এটি প্রয়োগ করুন:
Presenter(একটি পরিষেবা) Output Port <I>ইন্টারফেসে নির্দেশ না দেওয়া উচিত । ইন্টারফেসটি Interactor(এখানে ক্লায়েন্ট হিসাবে অভিনয় করে) যা প্রয়োজন তা সংকীর্ণ করা উচিত । তার মানে ইন্টারফেসটি সম্পর্কে জেনে রাখা Interactorএবং আইএসপি অনুসরণ করতে অবশ্যই এটির সাথে পরিবর্তন করতে হবে। এবং এই ঠিক আছে।
Interactor(এখানে একটি পরিষেবা হিসাবে অভিনয় করে) Input Port <I>ইন্টারফেসের নির্দেশ না দেওয়া উচিত । ইন্টারফেসটি কী Controller(ক্লায়েন্ট) প্রয়োজন তা সংকুচিত করা উচিত । তার মানে ইন্টারফেসটি সম্পর্কে জেনে রাখা Controllerএবং আইএসপি অনুসরণ করতে অবশ্যই এটির সাথে পরিবর্তন করতে হবে। আর এই হল না ঠিক আছে।
দ্বিতীয়টি ঠিক নেই কারণ লাল স্তরটি সবুজ স্তর সম্পর্কে জানার কথা নয়। তাহলে আইএসপি কি ভুল? ভাল কিন্ডা। কোনও নীতিই পরম নয়। এটি এমন একটি ক্ষেত্রে যেখানে পরিষেবাটি সমস্ত কিছু দেখানোর ইন্টারফেস পছন্দ করে এমন বোকারা সঠিক হতে পারে।
কমপক্ষে, যদি তারা Interactorব্যবহারের ক্ষেত্রে এটির প্রয়োজন ছাড়া অন্য কিছু না করে তবে তারা ঠিক । তাহলে Interactorঅন্যান্য ব্যবহারের ক্ষেত্রে জন্য কিছু করে কোনো কারণ এই নেই Input Port <I>হয়ে গেছে তাদের সম্পর্কে জানতে। নিশ্চিত কেনInteractor কেবল একটি ব্যবহারের ক্ষেত্রে মনোনিবেশ করা যায় না এটি এটি একটি নন ইস্যু, তবে জিনিসগুলি ঘটে।
তবে input port <I>ইন্টারফেসটি কেবল নিজেকে দাস করতে পারে নাController ক্লায়েন্টের এবং এটি একটি সত্য প্লাগইন হতে পারে। এটি একটি 'লাইব্রেরি' সীমানা। একটি সম্পূর্ণ ভিন্ন প্রোগ্রামিং শপ লাল স্তর প্রকাশের কয়েক বছর পরে সবুজ স্তর লিখতে পারে।
যদি আপনি একটি 'লাইব্রেরি' সীমানা অতিক্রম করে থাকেন এবং আপনি অন্যদিকে ইন্টারফেসটির মালিক না হন তবুও আপনি ইন্টারফেসটি পরিবর্তন না করে সংকীর্ণ করার উপায় খুঁজে পেতে চলেছেন যদিও আইএসপি প্রয়োগের প্রয়োজনীয়তা অনুভব করছেন।
এটিকে টানানোর একটি উপায় অ্যাডাপ্টার। এটিকে ক্লায়েন্ট Controlerএবং Input Port <I>ইন্টারফেসের মধ্যে রাখুন । অ্যাডাপ্টার Interactorএকটি হিসাবে গ্রহণ করে Input Port <I>এবং এটি এতে কাজ করে দেয়। যাইহোক, এটি কেবল গ্রাহকরা Controllerগ্রীন স্তরের মালিকানাধীন কোনও ইন্টারফেস বা ইন্টারফেসের মাধ্যমে যা পছন্দ করে তা কেবল প্রকাশ করে। অ্যাডাপ্টার নিজেই আইএসপি অনুসরণ করে না তবে আরও জটিল শ্রেণিকে Controllerআইএসপি উপভোগ করতে দেয় like যদি এটির মতো ক্লায়েন্টগুলির চেয়ে কম অ্যাডাপ্টার থাকে Controllerএবং আপনি যখন অস্বাভাবিক পরিস্থিতিতে থাকেন যেখানে আপনি একটি লাইব্রেরির সীমানা অতিক্রম করছেন এবং প্রকাশিত সত্ত্বেও, গ্রন্থাগারটি পরিবর্তন করা বন্ধ করবে না এটি কার্যকর। আপনার দিকে ফায়ারফক্স। এখন এই পরিবর্তনগুলি কেবল আপনার অ্যাডাপ্টারগুলিকেই ভেঙে দেয়।
তাহলে এর অর্থ কি? এর অর্থ সততার সাথে আপনি আমার কি করতে হবে তা বলার জন্য আপনি পর্যাপ্ত তথ্য সরবরাহ করেন নি। আমি জানি না আইএসপি অনুসরণ না করা আপনাকে সমস্যার সৃষ্টি করছে কিনা। আমি জানি না এটির অনুসরণটি যদি আপনার আরও সমস্যার কারণ হয় না।
আমি জানি আপনি একটি সহজ গাইডিং নীতি খুঁজছেন। আইএসপি তা হওয়ার চেষ্টা করে। কিন্তু এটি অনেক অপ্রয়োজনীয় ছেড়ে যায়। আমি এতে বিশ্বাস করি। হ্যাঁ, দয়া করে কোনও ভাল কারণ ছাড়াই ক্লায়েন্টদের তারা যে পদ্ধতিগুলি ব্যবহার করেন না তার উপর নির্ভর করতে বাধ্য করবেন না!
আপনার যদি কোনও যুক্তিসঙ্গত কারণ থাকে যেমন প্লাগিনগুলি গ্রহণ করার জন্য আপনার ডিজাইন করার মতো কিছু, তবে আইএসপি কারণগুলি অনুসরণ না করা সমস্যাগুলি সম্পর্কে অবহিত হন (ক্লায়েন্টকে না ভেঙে ফেলা শক্ত) এবং সেগুলি প্রশমিত করার উপায়গুলি (রাখুন Interactorবা কমপক্ষে কোনও Input Port <I>স্থিতিশীলের দিকে ফোকাস করুন) ব্যবহারের ক্ষেত্রে).
