ISP — এটি কী, ডেভেলপমেন্টে ইন্টারফেস বিভাজনের নীতি

ISP (Interface Segregation Principle) কী?

ISP (Interface Segregation Principle) হল ইন্টারফেস বিভাজনের নীতি যা “মোটা” ইন্টারফেস তৈরি করতে নিষেধ করে যাতে এমন পদ্ধতি থাকে যা সব ক্লায়েন্ট ব্যবহার করে না। এক ডজন পদ্ধতি বিশিষ্ট একটি ইন্টারফেসের পরিবর্তে, বেশ কয়েকটি ছোট ইন্টারফেস ডিজাইন করা হয়, প্রতিটি তার নিজস্ব ক্লায়েন্ট গ্রুপের জন্য।

নীতিটি রবার্ট মার্টিন “ইন্টারফেস দূষণ” সমস্যার সমাধান হিসেবে প্রবর্তন করেছিলেন, যখন একটি শ্রেণীকে এমন পদ্ধতি বাস্তবায়ন করতে বাধ্য করা হয় যা তার প্রয়োজন নেই, শুধুমাত্র সেগুলি একটি সাধারণ ইন্টারফেসে ঘোষিত বলেই। স্ট্যাটিক্যালি টাইপ করা ভাষায়, এর ফলে খালি বাস্তবায়ন বা ব্যতিক্রম নিক্ষেপ হয় — ISP লঙ্ঘনের সরাসরি লক্ষণ।

ISP এবং SRP একে অপরের পরিপূরক: SRP শ্রেণীর দায়িত্ব নিয়ে, ISP ইন্টারফেস চুক্তি নিয়ে। SRP বলে “একটি শ্রেণী — পরিবর্তনের একটি কারণ”, ISP বলে “একটি ইন্টারফেস — একটি ক্লায়েন্ট দৃশ্যকল্প”। একসাথে তারা একটি মডুলার আর্কিটেকচার গঠন করে যেখানে সিস্টেমের প্রতিটি উপাদানের স্পষ্ট সীমানা থাকে।

মোটা ইন্টারফেস এবং তাদের পরিণতি

Fat Interface — একটি ইন্টারফেস যা নির্দিষ্ট ক্লায়েন্টের প্রয়োজনীয়তার চেয়ে বেশি পদ্ধতি ধারণ করে। উদাহরণস্বরূপ, work, eat, sleep পদ্ধতি সহ একটি Worker ইন্টারফেস। একটি রোবট কর্মীর eat এবং sleep বাস্তবায়ন করা উচিত নয়, কিন্তু বাধ্য করা হয়। সমাধান — Workable, Eatable, Sleepable এ ভাগ করা। প্রত্যেক ক্লায়েন্ট ঠিক যা প্রয়োজন তা পায়।

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

ইন্টারফেস বিভাজনের নীতি কীভাবে কাজ করে

ISP বাস্তবায়ন প্রতিটি ইন্টারফেসের ক্লায়েন্ট বিশ্লেষণের মাধ্যমে শুরু হয়। যদি দুটি ক্লায়েন্ট একটি ইন্টারফেসের বিভিন্ন পদ্ধতির সেট ব্যবহার করে — তাহলে ইন্টারফেসটি ভাগ করা উচিত। প্রতিটি নতুন ইন্টারফেস সেই পদ্ধতিগুলিকে গ্রুপ করে যা একটি দৃশ্যকল্পের মধ্যে একসাথে কল করা হয়।

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

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

ISP লঙ্ঘনের লক্ষণ

ISP লঙ্ঘনের প্রধান লক্ষণগুলির মধ্যে রয়েছে: খালি পদ্ধতি সহ ইন্টারফেস বাস্তবায়নকারী শ্রেণী (নকল বাস্তবায়ন), বাস্তবায়নে UnsupportedOperationException নিক্ষেপ, বিপুল সংখ্যক প্যারামিটার বা রিটার্ন টাইপ যা কিছু ক্লায়েন্ট ব্যবহার করে না, এবং ইন্টারফেসে ঘন ঘন পরিবর্তন যা শুধুমাত্র কিছু ক্লায়েন্টকে প্রভাবিত করে।

Android ডেভেলপমেন্টে, ISP লঙ্ঘনের একটি সাধারণ উদাহরণ হল OnItemClickListener ইন্টারফেস, যাতে ক্লিক, লং ক্লিক এবং সোয়াইপের জন্য পদ্ধতি অন্তর্ভুক্ত। যদি একটি নির্দিষ্ট স্ক্রিন শুধুমাত্র ক্লিক ব্যবহার করে — বাকি পদ্ধতিগুলি খালি থাকে। সমাধান — OnItemClickListener, OnItemLongClickListener, OnItemSwipeListener এ ভাগ করা।

iOS ডেভেলপমেন্টে, ISP লঙ্ঘন UIKit ডেলিগেট এ প্রকাশ পায়: একটি প্রোটোকলে বিভিন্ন উপাদানের অবস্থার জন্য পদ্ধতি থাকে। UITableViewDelegate-এ প্রদর্শন, নির্বাচন, সম্পাদনা এবং সোয়াইপ-অ্যাকশনের জন্য পদ্ধতি অন্তর্ভুক্ত। ডেভেলপাররা প্রায়ই এক ডজন খালি পদ্ধতি সহ সম্পূর্ণ প্রোটোকল বাস্তবায়ন করে। দায়িত্ব গ্রুপ অনুযায়ী একাধিক প্রোটোকলে বিভাজন সমস্যার সমাধান করে।

অব্যবহৃত পদ্ধতির উপর নির্ভরতা

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

অন্তর্নিহিত ISP লঙ্ঘন কনফিগারেশন প্যারামিটারের মাধ্যমে ঘটে। যদি একটি পদ্ধতি অনেকগুলি ফিল্ড সহ একটি অবজেক্ট গ্রহণ করে, এবং ক্লায়েন্ট সেগুলির মধ্যে মাত্র 2-3টি ব্যবহার করে — এটি বিভাজনের সংকেত। বিকল্প: প্যারামিটারের ন্যূনতম সেট সহ একাধিক বিশেষায়িত পদ্ধতি।

Android ডেভেলপমেন্টে, সমস্ত অ্যাপ্লিকেশন সেটিংস পড়া এবং লেখার জন্য একটি একক SharedPreferencesManager ব্যবহার করলে ISP লঙ্ঘিত হয়। Fragment যার শুধুমাত্র থিম পড়া প্রয়োজন, সে বিভিন্ন ডেটা টাইপের জন্য ডজন ডজন পদ্ধতি সহ একটি বিশ্বব্যাপী ম্যানেজারের উপর নির্ভরতা পায়। ThemePreferenceProvider, AuthPreferenceProvider, FeatureFlagProvider এ বিভাজন — কনফিগারেশন পরিষেবা স্তরে ISP প্রয়োগ। প্রত্যেক প্রদানকারী তার ক্লায়েন্টদের প্রয়োজনীয় পদ্ধতিগুলিই ধারণ করে।

মোবাইল অ্যাপ্লিকেশনে ISP-এর উদাহরণ

ডেটার সাথে কাজ করার জন্য ইন্টারফেস সহ একটি Android উদাহরণ বিবেচনা করুন। ISP লঙ্ঘন — সমস্ত CRUD অপারেশনের জন্য একটি ইন্টারফেস, যদিও সব ক্লায়েন্টের সব অপারেশনের প্রয়োজন নেই।

// ISP লঙ্ঘন: মোটা ইন্টারফেস
interface UserRepository {
    fun getAll(): List<User>
    fun getById(id: Int): User
    fun save(user: User)
    fun delete(id: Int)
}

// ISP প্রয়োগের পর: সংকীর্ণ ইন্টারফেস
interface UserReader {
    fun getAll(): List<User>
    fun getById(id: Int): User
}

interface UserWriter {
    fun save(user: User)
    fun delete(id: Int)
}

// ReadOnlyViewModel লেখার পদ্ধতির উপর নির্ভর করে না
class ReadOnlyViewModel(
    private val reader: UserReader
)

মিডিয়ার সাথে কাজ করার জন্য প্রোটোকল বিভাজন সহ একটি iOS উদাহরণ:

// ISP লঙ্ঘন: সমস্ত মিডিয়া কাজের জন্য একটি প্রোটোকল
protocol MediaService {
    func play(url: URL)
    func pause()
    func stop()
    func upload(data: Data) async -> URL
    func download(url: URL) async -> Data
}

// ISP-এর পর: দায়িত্ব অনুযায়ী প্রোটোকলে বিভাজন
protocol MediaPlayer {
    func play(url: URL)
    func pause()
    func stop()
}

protocol MediaTransfer {
    func upload(data: Data) async -> URL
    func download(url: URL) async -> Data
}

// PlayerViewModel ডাউনলোড পদ্ধতির উপর নির্ভর করে না
class PlayerViewModel {
    private let player: MediaPlayer
}

ব্যবহারিক উপসংহার: ISP ক্লায়েন্টকে ইন্টারফেসের অসম্পর্কিত অংশে পরিবর্তন থেকে রক্ষা করে। UserRepository কে UserReader এবং UserWriter এ বিভক্ত করার অর্থ হল save-এ পরিবর্তন ReadOnlyViewModel কে প্রভাবিত করে না, এবং এর বিপরীত। প্রত্যেক ক্লায়েন্ট সে ব্যবহার করে না এমন কার্যকারিতা থেকে বিচ্ছিন্ন এবং সিস্টেমের অন্যান্য অংশ পরিবর্তন করার সময় পরিবর্তনের প্রয়োজন হয় না।

ISP এবং SOLID: অন্যান্য নীতির সাথে সম্পর্ক

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

ISP এবং OCP সম্পর্কিত: সংকীর্ণ ইন্টারফেস প্রসারিত করা সহজ। একটি সংকীর্ণ ইন্টারফেসে একটি নতুন পদ্ধতি যোগ করা শুধুমাত্র তার ক্লায়েন্টদের প্রভাবিত করে। একটি মোটা ইন্টারফেসে একটি পদ্ধতি যোগ করা সমস্ত ক্লায়েন্টকে প্রভাবিত করে — সম্ভাব্যভাবে OCP লঙ্ঘন করে যদি ক্লায়েন্টদের তাদের বাস্তবায়ন পরিবর্তন করতে বাধ্য করা হয়।

ISP এবং DIP একসাথে কাজ করে: DIP-এর জন্য বিমূর্ততার উপর নির্ভরতা প্রয়োজন। ISP এই বিমূর্ততাগুলিকে সংকীর্ণ এবং কেন্দ্রীভূত করে। একটি বিস্তৃত ইন্টারফেসের উপর নির্ভরতা এখনও একটি বিমূর্ততার উপর নির্ভরতা, কিন্তু ISP দৃষ্টিকোণ থেকে একটি “খারাপ” বিমূর্ততা। চারটি নীতি (SRP, OCP, ISP, DIP) “মডুলারিটি পিরামিড” গঠন করে: SRP এবং ISP সীমানা নির্ধারণ করে, OCP এবং DIP সম্প্রসারণ এবং কাপলিংয়ের পদ্ধতি নির্ধারণ করে।

কম্পোনেন্ট আর্কিটেকচারে ISP-এর প্রয়োগ

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

Clean Architecture সহ Android প্রজেক্টে, ISP UseCases এ প্রয়োগ করা হয়: প্রতিটি UseCase একটি একক invoke বা execute পদ্ধতি সহ একটি পৃথক ইন্টারফেস। ক্লায়েন্ট (ViewModel) একটি সম্পূর্ণ রিপোজিটরির পরিবর্তে শুধুমাত্র প্রয়োজনীয় UseCase-এর উপর নির্ভর করে। এটি নির্ভরতাগুলিকে স্বচ্ছ এবং পরীক্ষাযোগ্য করে।