8.1 পচন সবকিছু
স্পষ্টতার জন্য, একটি ভাল নিবন্ধ "ডিকপলিং অব অবজেক্ট-ওরিয়েন্টেড সিস্টেম" থেকে একটি ছবি, যা আলোচনা করা হবে এমন মূল বিষয়গুলিকে চিত্রিত করে।
আপনি কি এখনও মনে করেন যে একটি অ্যাপ্লিকেশন আর্কিটেকচার ডিজাইন করা সহজ?
8.2 ইন্টারফেস, বাস্তবায়ন লুকানো
সিস্টেমের কাপলিং হ্রাস করার প্রধান নীতিগুলি হল OOP এর নীতি এবং তাদের পিছনে Encapsulation + Abstraction + Polymorphism এর নীতি।
এই কারণে:
- মডিউলগুলি একে অপরের জন্য "ব্ল্যাক বক্স" হওয়া উচিত (এনক্যাপসুলেশন) । এর মানে হল যে একটি মডিউল অন্য মডিউলে "আরোহণ" করা উচিত নয় এবং এর অভ্যন্তরীণ গঠন সম্পর্কে কিছু জানা উচিত নয়। একটি সাবসিস্টেমের অবজেক্ট অন্য সাবসিস্টেমের অবজেক্টে সরাসরি প্রবেশ করা উচিত নয়।
- মডিউল/সাবসিস্টেমগুলিকে শুধুমাত্র ইন্টারফেসের মাধ্যমে একে অপরের সাথে যোগাযোগ করা উচিত (অর্থাৎ, বিমূর্ততা যা বাস্তবায়নের বিবরণের উপর নির্ভর করে না)। তদনুসারে, প্রতিটি মডিউলের অবশ্যই একটি সু-সংজ্ঞায়িত ইন্টারফেস বা অন্যান্য মডিউলগুলির সাথে ইন্টারঅ্যাক্ট করার জন্য ইন্টারফেস থাকতে হবে।
"ব্ল্যাক বক্স" (এনক্যাপসুলেশন) নীতি আমাদের প্রতিটি সাবসিস্টেমের গঠনকে অন্যান্য সাবসিস্টেম থেকে স্বাধীনভাবে বিবেচনা করতে দেয়। মডিউল, যা একটি "ব্ল্যাক বক্স", তুলনামূলকভাবে অবাধে পরিবর্তন করা যেতে পারে। সমস্যাগুলি শুধুমাত্র বিভিন্ন মডিউল (বা একটি মডিউল এবং একটি পরিবেশ) এর সংযোগস্থলে দেখা দিতে পারে।
এবং এই মিথস্ক্রিয়াটি অবশ্যই সবচেয়ে সাধারণ (বিমূর্ত) আকারে বর্ণনা করা উচিত, অর্থাৎ একটি ইন্টারফেসের আকারে। এই ক্ষেত্রে, কোডটি ইন্টারফেস চুক্তির সাথে সামঞ্জস্যপূর্ণ যে কোনও বাস্তবায়নের সাথে একই কাজ করবে। এটি একটি ইউনিফাইড ইন্টারফেসের মাধ্যমে বিভিন্ন বাস্তবায়নের (মডিউল বা অবজেক্ট) সাথে কাজ করার ক্ষমতা যাকে বলা হয় পলিমরফিজম।
এই কারণেই সার্ভলেট একটি ইন্টারফেস : ওয়েব কন্টেইনার সার্ভলেট সম্পর্কে কিছুই জানে না, এটির জন্য এটি এমন কিছু বস্তু যা সার্ভলেট ইন্টারফেস বাস্তবায়ন করে এবং এটিই। সার্ভলেটগুলি পাত্রের গঠন সম্পর্কেও কিছুটা জানে। সার্ভলেট ইন্টারফেস হল সেই চুক্তি, সেই স্ট্যান্ডার্ড, সেই ন্যূনতম মিথস্ক্রিয়া যা জাভা ওয়েব অ্যাপ্লিকেশনগুলিকে বিশ্ব দখল করতে প্রয়োজনীয়।
পলিমরফিজম পদ্ধতির মোটেও ওভাররাইডিং নয়, যেমনটি কখনও কখনও ভুলভাবে বিশ্বাস করা হয়, তবে প্রথমত, একই ইন্টারফেস বা "এক ইন্টারফেস, অনেকগুলি বাস্তবায়ন" সহ মডিউল/বস্তুর বিনিময়যোগ্যতা। পলিমরফিজম বাস্তবায়নের জন্য, উত্তরাধিকার প্রক্রিয়ার প্রয়োজন নেই। এটি বোঝা গুরুত্বপূর্ণ কারণ সাধারণভাবে উত্তরাধিকার এড়ানো উচিত যখনই সম্ভব ।
ইন্টারফেস এবং পলিমরফিজমের জন্য ধন্যবাদ , এটি ইতিমধ্যে যা লেখা আছে (ওপেন-ক্লোজড প্রিন্সিপল) তা পরিবর্তন না করেই কোডটি সংশোধন এবং প্রসারিত করার ক্ষমতা অর্জিত হয়েছে।
যতক্ষণ না মডিউলগুলির মিথস্ক্রিয়াটি একচেটিয়াভাবে ইন্টারফেসের আকারে বর্ণনা করা হয় এবং নির্দিষ্ট বাস্তবায়নের সাথে আবদ্ধ না হয়, আপনার কাছে সিস্টেমের জন্য একটি মডিউলকে একই ইন্টারফেস প্রয়োগকারী অন্য কোনও মডিউলের সাথে প্রতিস্থাপন করার সুযোগ রয়েছে। একটি নতুন যোগ করুন এবং এর ফলে কার্যকারিতা প্রসারিত করুন।
এটি LEGO কনস্ট্রাক্টরের মতো - ইন্টারফেসটি মিথস্ক্রিয়াকে মানক করে তোলে এবং এক ধরণের সংযোগকারী হিসাবে কাজ করে যেখানে একটি উপযুক্ত সংযোগকারী সহ যেকোনো মডিউল সংযুক্ত করা যেতে পারে।
ডিজাইনারের নমনীয়তা নিশ্চিত করা হয় যে আমরা একই সংযোগকারী (একই ইন্টারফেস সহ) দিয়ে কেবল একটি মডিউল বা অংশ অন্যটির সাথে প্রতিস্থাপন করতে পারি, পাশাপাশি আমাদের পছন্দ মতো অনেকগুলি নতুন অংশ যুক্ত করতে পারি (একই সময়ে, বিদ্যমান অংশগুলি কোনভাবেই পরিবর্তিত বা পরিবর্তিত হয় না)।
ইন্টারফেসগুলি আপনাকে প্রতিটি সাবসিস্টেমকে সামগ্রিকভাবে বিবেচনা করে এবং এর অভ্যন্তরীণ কাঠামো উপেক্ষা করে একটি সহজ সিস্টেম তৈরি করতে দেয়। তারা মডিউলগুলিকে ইন্টারঅ্যাক্ট করার অনুমতি দেয় এবং একই সাথে একে অপরের অভ্যন্তরীণ কাঠামো সম্পর্কে কিছুই জানে না, যার ফলে ন্যূনতম জ্ঞানের নীতিটি সম্পূর্ণরূপে বাস্তবায়ন করে, যা আলগা সংযোগের ভিত্তি।
ইন্টারফেসগুলিকে যত বেশি সাধারণ/বিমূর্ত সংজ্ঞায়িত করা হবে এবং তারা মিথস্ক্রিয়াতে যত কম বিধিনিষেধ আরোপ করবে, সিস্টেম তত বেশি নমনীয় হবে। এখান থেকে, SOLID-এর আরও একটি নীতি আসলে অনুসরণ করে - ইন্টারফেস সেগ্রিগেশন নীতি , যা "পুরু ইন্টারফেস" এর বিরোধিতা করে।
তিনি বলেছেন যে বড়, ভারী ইন্টারফেসগুলিকে আরও ছোট, আরও নির্দিষ্টগুলির মধ্যে বিভক্ত করা উচিত, যাতে ছোট ইন্টারফেসের ক্লায়েন্টরা (নির্ভরশীল মডিউল) শুধুমাত্র তাদের সাথে কাজ করার পদ্ধতিগুলি সম্পর্কে জানে৷
এই নীতিটি নিম্নরূপ প্রণয়ন করা হয়েছে: "ক্লায়েন্টদের এমন পদ্ধতির উপর নির্ভর করা উচিত নয় (পদ্ধতি সম্পর্কে সচেতন হওয়া) যা তারা ব্যবহার করে না" বা "অনেক বিশেষায়িত ইন্টারফেস একটি সর্বজনীন একের চেয়ে ভাল"।
এটা দেখা যাচ্ছে যে দুর্বল সংযোগ প্রদান করা হয় শুধুমাত্র যখন মডিউলগুলির মিথস্ক্রিয়া এবং নির্ভরতা শুধুমাত্র ইন্টারফেসের সাহায্যে বর্ণনা করা হয়, অর্থাৎ, বিমূর্ততা, তাদের অভ্যন্তরীণ গঠন এবং গঠন সম্পর্কে জ্ঞান ব্যবহার না করে। এবং প্রকৃতপক্ষে, এনক্যাপসুলেশন এইভাবে প্রয়োগ করা হয়। প্লাস, আমাদের বিভিন্ন বাস্তবায়ন যোগ করে এবং ব্যবহার করে সিস্টেমের আচরণকে প্রসারিত/পরিবর্তন করার ক্ষমতা আছে, অর্থাৎ পলিমরফিজমের কারণে। হ্যাঁ, আমরা আবার ওওপি-তে এসেছি - এনক্যাপসুলেশন, অ্যাবস্ট্রাকশন, পলিমরফিজম।
8.3 সম্মুখভাগ: মডিউল ইন্টারফেস
এখানে একজন অভিজ্ঞ প্রোগ্রামার জিজ্ঞাসা করবেন: যদি ডিজাইনটি এমন বস্তুর স্তরে না হয় যা সংশ্লিষ্ট ইন্টারফেসগুলিকে প্রয়োগ করে, তবে মডিউলগুলির স্তরে, তাহলে মডিউল ইন্টারফেসের বাস্তবায়ন কী?
উত্তর: ডিজাইনের প্যাটার্নের ভাষায় কথা বললে, একটি বিশেষ বস্তু মডিউল ইন্টারফেস বাস্তবায়নের জন্য দায়ী হতে পারে - ফ্যাকাড । আপনি যদি এমন একটি বস্তুর পদ্ধতিতে কল করছেন যাতে গেটওয়ে প্রত্যয় রয়েছে (উদাহরণস্বরূপ, MobileApiGateway), তাহলে এটি সম্ভবত একটি মুখোশ।
একটি সম্মুখভাগ একটি ইন্টারফেস বস্তু যা একটি নির্দিষ্ট সাবসিস্টেমের সাথে কাজ করার জন্য একটি উচ্চ-স্তরের ক্রিয়াকলাপ জমা করে, এর অভ্যন্তরীণ গঠন এবং এর পিছনে প্রকৃত জটিলতা লুকিয়ে রাখে । সাবসিস্টেম বাস্তবায়নে পরিবর্তনের বিরুদ্ধে সুরক্ষা প্রদান করে। একটি একক এন্ট্রি পয়েন্ট হিসাবে কাজ করে - "আপনি সম্মুখভাগে লাথি মারেন, এবং তিনি জানেন যে তার যা প্রয়োজন তা পেতে এই সাবসিস্টেমে কাকে লাথি মারতে হবে।"
আপনাকে সবেমাত্র একটি সবচেয়ে গুরুত্বপূর্ণ ডিজাইনের প্যাটার্নের সাথে পরিচয় করিয়ে দেওয়া হয়েছে যা আপনাকে মডিউল ডিজাইন করার সময় ইন্টারফেসের ধারণা ব্যবহার করতে দেয় এবং এর ফলে সেগুলিকে দ্বিগুণ করে - "ফেসেড"।
এছাড়াও, "ফেসেড" মডিউলগুলির সাথে সাধারণ বস্তুর মতো একইভাবে কাজ করা এবং মডিউল ডিজাইন করার সময় ক্লাসের নকশায় ব্যবহৃত সমস্ত দরকারী নীতি এবং কৌশলগুলি প্রয়োগ করা সম্ভব করে তোলে।
দ্রষ্টব্য : যদিও বেশিরভাগ প্রোগ্রামাররা ক্লাস (বস্তু) ডিজাইন করার সময় ইন্টারফেসের গুরুত্ব বোঝেন, তবে মনে হয় অনেকেই মডিউল স্তরেও ইন্টারফেস ব্যবহার করার ধারণা আবিষ্কার করেন।