পাইথন অ্যাবস্ট্রাক্ট বেস ক্লাস: প্রোটোকল ইমপ্লিমেন্টেশন বনাম ইন্টারফেস ডিজাইন আয়ত্ত করা

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

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

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

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

ভিত্তি: অ্যাবস্ট্রাক্ট বেস ক্লাসগুলি আসলে কী?

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

পাইথনের বিল্ট-ইন `abc` মডিউল এবিসি তৈরির জন্য সরঞ্জাম সরবরাহ করে। দুটি প্রাথমিক উপাদান হল:

• `ABC`: একটি এবিসি তৈরি করতে মেটাক্লাস হিসাবে ব্যবহৃত একটি সহায়ক ক্লাস। আধুনিক পাইথনে (3.4+), আপনি কেবল `abc.ABC` থেকে ইনহেরিট করতে পারেন।
• `@abstractmethod`: অ্যাবস্ট্রাক্ট পদ্ধতি হিসাবে চিহ্নিত করার জন্য ব্যবহৃত একটি ডেকোরেটর। এবিসি-র কোনও সাবক্লাসকে অবশ্যই এই পদ্ধতিগুলি প্রয়োগ করতে হবে।

দুটি মৌলিক নিয়ম রয়েছে যা এবিসি নিয়ন্ত্রণ করে:

1. আপনি একটি এবিসি-র একটি ইনস্ট্যান্স তৈরি করতে পারবেন না যাতে অপরিপূর্ণ অ্যাবস্ট্রাক্ট পদ্ধতি থাকে। এটি একটি টেমপ্লেট, একটি সমাপ্ত পণ্য নয়।
2. কোনও কংক্রিট সাবক্লাসকে অবশ্যই সমস্ত ইনহেরিট করা অ্যাবস্ট্রাক্ট পদ্ধতি প্রয়োগ করতে হবে। যদি এটি ব্যর্থ হয়, তবে এটিও একটি অ্যাবস্ট্রাক্ট ক্লাসে পরিণত হবে, এবং আপনি এর একটি ইনস্ট্যান্স তৈরি করতে পারবেন না।

আসুন একটি ক্লাসিক উদাহরণ দিয়ে এটি কাজ করতে দেখি: মিডিয়া ফাইলগুলি পরিচালনা করার জন্য একটি সিস্টেম।

উদাহরণ: একটি সাধারণ MediaFile এবিসি

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

import abc

class MediaFile(abc.ABC):
    def __init__(self, filepath: str):
        self.filepath = filepath
        print(f"Base init for {self.filepath}")
    @abc.abstractmethod
    def play(self) -> None:
        """Play the media file."""
        raise NotImplementedError
    @abc.abstractmethod
    def get_metadata(self) -> dict:
        """Return a dictionary of media metadata."""
        raise NotImplementedError

যদি আমরা সরাসরি `MediaFile` এর একটি ইনস্ট্যান্স তৈরি করার চেষ্টা করি, তবে পাইথন আমাদের থামিয়ে দেবে:

# This will raise a TypeError
# media = MediaFile("path/to/somefile.txt")
# TypeError: Can't instantiate abstract class MediaFile with abstract methods get_metadata, play

এই ব্লুপ্রিন্টটি ব্যবহার করার জন্য, আমাদের অবশ্যই কংক্রিট সাবক্লাস তৈরি করতে হবে যা `play()` এবং `get_metadata()` এর জন্য বাস্তবায়ন সরবরাহ করে।

class AudioFile(MediaFile):
    def play(self) -> None:
        print(f"Playing audio from {self.filepath}...")
    def get_metadata(self) -> dict:
        return {"codec": "mp3", "duration_seconds": 180}
class VideoFile(MediaFile):
    def play(self) -> None:
        print(f"Playing video from {self.filepath}...")
    def get_metadata(self) -> dict:
        return {"codec": "h264", "resolution": "1920x1080"}

এখন, আমরা `AudioFile` এবং `VideoFile` এর ইনস্ট্যান্স তৈরি করতে পারি কারণ তারা `MediaFile` দ্বারা সংজ্ঞায়িত চুক্তিটি পূরণ করে। এটি এবিসি-র মৌলিক প্রক্রিয়া। কিন্তু আসল শক্তি আসে কিভাবে আমরা এই প্রক্রিয়াটি ব্যবহার করি।

প্রথম দর্শন: ফর্মাল ইন্টারফেস ডিজাইন হিসাবে এবিসি (নমিনাল টাইপিং)

এবিসি ব্যবহার করার প্রথম এবং সবচেয়ে ঐতিহ্যবাহী উপায় হল ফর্মাল ইন্টারফেস ডিজাইনের জন্য। এই পদ্ধতিটি নমিনাল টাইপিং-এর উপর ভিত্তি করে তৈরি, যা জাভা, সি++, বা সি# এর মতো ভাষা থেকে আসা ডেভেলপারদের কাছে একটি পরিচিত ধারণা। একটি নমিনাল সিস্টেমে, একটি টাইপের সামঞ্জস্য তার নাম এবং স্পষ্ট ঘোষণার মাধ্যমে নির্ধারিত হয়। আমাদের প্রেক্ষাপটে, একটি ক্লাস `MediaFile` হিসাবে বিবেচিত হয় শুধুমাত্র যদি এটি স্পষ্টভাবে `MediaFile` এবিসি থেকে ইনহেরিট করে।

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

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

উদাহরণ: একটি ডেটা এক্সপোর্টার ফ্রেমওয়ার্ক

কল্পনা করুন আমরা একটি ফ্রেমওয়ার্ক তৈরি করছি যা ব্যবহারকারীদের বিভিন্ন বিন্যাসে ডেটা রপ্তানি করার অনুমতি দেয়। আমরা নিশ্চিত করতে চাই যে প্রতিটি এক্সপোর্টার প্লাগইন একটি কঠোর কাঠামো মেনে চলে। আমরা একটি `DataExporter` ইন্টারফেস সংজ্ঞায়িত করতে পারি।

import abc
from datetime import datetime
class DataExporter(abc.ABC):
    """A formal interface for data exporting classes."""
    @abc.abstractmethod
    def export(self, data: list[dict]) -> str:
        """Exports data and returns a status message."""
        pass
    def get_timestamp(self) -> str:
        """A concrete helper method shared by all subclasses."""
        return datetime.utcnow().isoformat()
class CSVExporter(DataExporter):
    def export(self, data: list[dict]) -> str:
        filename = f"export_{self.get_timestamp()}.csv"
        print(f"Exporting {len(data)} rows to {filename}")
        # ... actual CSV writing logic ...
        return f"Successfully exported to {filename}"
class JSONExporter(DataExporter):
    def export(self, data: list[dict]) -> str:
        filename = f"export_{self.get_timestamp()}.json"
        print(f"Exporting {len(data)} records to {filename}")
        # ... actual JSON writing logic ...
        return f"Successfully exported to {filename}"

এখানে, `CSVExporter` এবং `JSONExporter` স্পষ্টভাবে এবং যাচাইযোগ্যভাবে `DataExporter`। আমাদের অ্যাপ্লিকেশনটির মূল যুক্তি এই চুক্তির উপর নিরাপদে নির্ভর করতে পারে:

def run_export_process(exporter: DataExporter, data_to_export: list[dict]):
    print("---"" Starting export process ---")
    if not isinstance(exporter, DataExporter):
        raise TypeError("Exporter must be a valid DataExporter implementation.")
    status = exporter.export(data_to_export)
    print(f"Process finished with status: {status}")
# Usage
data = [{"id": 1, "name": "Alice"}, {"id": 2, "name": "Bob"}]
run_export_process(CSVExporter(), data)
run_export_process(JSONExporter(), data)

লক্ষ্য করুন যে এবিসি একটি কংক্রিট পদ্ধতিও সরবরাহ করে, `get_timestamp()`, যা তার সমস্ত শিশুদের কাছে ভাগ করা কার্যকারিতা সরবরাহ করে। এটি ইন্টারফেস-ভিত্তিক ডিজাইনে একটি সাধারণ এবং শক্তিশালী প্যাটার্ন।

ফর্মাল ইন্টারফেস পদ্ধতির সুবিধা এবং অসুবিধা

সুবিধা:

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

অসুবিধা:

• টাইট কাপলিং: কংক্রিট ক্লাসটি এখন সরাসরি এবিসি-র সাথে যুক্ত। যদি এবিসি সরানো বা পরিবর্তন করার প্রয়োজন হয়, তবে সমস্ত সাবক্লাস প্রভাবিত হবে।
• দৃঢ়তা: এটি একটি কঠোর অনুক্রমিক সম্পর্ক জোর করে। কি হবে যদি একটি ক্লাস যৌক্তিকভাবে একটি এক্সপোর্টার হিসাবে কাজ করতে পারে কিন্তু ইতিমধ্যে একটি ভিন্ন, অপরিহার্য বেস ক্লাস থেকে ইনহেরিট করে? পাইথনের মাল্টিপল ইনহেরিটেন্স এটি সমাধান করতে পারে, তবে এটি নিজের জটিলতাও (যেমন ডায়মন্ড প্রবলেম) তৈরি করতে পারে।
• আক্রমণাত্মক: এটি তৃতীয় পক্ষের কোড মানিয়ে নিতে ব্যবহার করা যাবে না। যদি আপনি একটি `export()` পদ্ধতি সহ একটি ক্লাস সরবরাহকারী একটি লাইব্রেরি ব্যবহার করেন, আপনি এটিকে সাবক্লাসিং (যা সম্ভব বা কাঙ্ক্ষিত নাও হতে পারে) ছাড়া `DataExporter` বানাতে পারবেন না।

দ্বিতীয় দর্শন: প্রোটোকল ইমপ্লিমেন্টেশন হিসাবে এবিসি (স্ট্রাকচারাল টাইপিং)

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

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

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

যখন আপনি `isinstance(obj, MyABC)` বা `issubclass(SomeClass, MyABC)` কল করেন, তখন পাইথন প্রথমে স্পষ্ট ইনহেরিটেন্সের জন্য পরীক্ষা করে। যদি এটি ব্যর্থ হয়, তবে এটি `MyABC`-এর `__subclasshook__` পদ্ধতি আছে কিনা তা পরীক্ষা করে। যদি এটি থাকে, তবে পাইথন এটিকে কল করে, জিজ্ঞাসা করে, "আচ্ছা, আপনি কি এই ক্লাসটিকে আপনার সাবক্লাস হিসাবে বিবেচনা করেন?" এটি এবিসি-কে কাঠামোর উপর ভিত্তি করে তার সদস্যতার মানদণ্ড নির্ধারণের অনুমতি দেয়।

উদাহরণ: একটি `Serializable` প্রোটোকল

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

import abc
class Serializable(abc.ABC):
    @abc.abstractmethod
    def to_dict(self) -> dict:
        pass
    @classmethod
    def __subclasshook__(cls, C):
        if cls is Serializable:
            # Check if 'to_dict' is in the method resolution order of C
            if any("to_dict" in B.__dict__ for B in C.__mro__):
                return True
        return NotImplemented

এখন, আসুন কিছু ক্লাস তৈরি করি। গুরুত্বপূর্ণভাবে, তাদের কোনটিই `Serializable` থেকে ইনহেরিট করবে না।

class User:
    def __init__(self, name: str, email: str):
        self.name = name
        self.email = email
    def to_dict(self) -> dict:
        return {"name": self.name, "email": self.email}
class Product:
    def __init__(self, sku: str, price: float):
        self.sku = sku
        self.price = price
    # This class does NOT conform to the protocol
class Configuration:
    def __init__(self, setting: str):
        self.setting = setting

আসুন এগুলিকে আমাদের প্রোটোকলের বিরুদ্ধে পরীক্ষা করি:

print(f"Is User serializable? {isinstance(User('Test', 't@t.com'), Serializable)}")
print(f"Is Product serializable? {isinstance(Product('T-1000', 99.99), Serializable)}")
print(f"Is Configuration serializable? {isinstance(Configuration('ON'), Serializable)}")
# Output:
# Is User serializable? True
# Is Product serializable? False <- Wait, why? Let's fix this.
# Is Configuration serializable? False

আহ, একটি আকর্ষণীয় বাগ! আমাদের `Product` ক্লাসে `to_dict` পদ্ধতি নেই। আসুন এটি যোগ করি।

class Product:
    def __init__(self, sku: str, price: float):
        self.sku = sku
        self.price = price
    def to_dict(self) -> dict: # Adding the method
        return {"sku": self.sku, "price": self.price}
print(f"Is Product now serializable? {isinstance(Product('T-1000', 99.99), Serializable)}")
# Output:
# Is Product now serializable? True

যদিও `User` এবং `Product` কোনো সাধারণ প্যারেন্ট ক্লাস ( `object` ব্যতীত) ভাগ করে না, আমাদের সিস্টেম উভয়কেই `Serializable` হিসাবে বিবেচনা করতে পারে কারণ তারা প্রোটোকলটি পূরণ করে। এটি ডিকাপলিংয়ের জন্য অবিশ্বাস্যভাবে শক্তিশালী।

প্রোটোকল পদ্ধতির সুবিধা এবং অসুবিধা

সুবিধা:

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

অসুবিধা:

• অন্তর্নিহিত চুক্তি: একটি ক্লাস এবং একটি প্রোটোকলের মধ্যে সম্পর্ক যা এটি প্রয়োগ করে তা ক্লাসের সংজ্ঞা থেকে তত্ক্ষণাত স্পষ্ট নয়। একজন ডেভেলপারকে `User` বস্তুকে `Serializable` হিসাবে কেন বিবেচনা করা হচ্ছে তা বোঝার জন্য কোডবেস অনুসন্ধান করতে হতে পারে।
• রানটাইম ওভারহেড: `isinstance` পরীক্ষা ধীর হতে পারে কারণ এটি `__subclasshook__` কল করতে এবং ক্লাসের পদ্ধতিগুলিতে পরীক্ষা সম্পাদন করতে হয়।
• জটিলতার সম্ভাবনা: `__subclasshook__` এর মধ্যেকার যুক্তি একাধিক পদ্ধতি, আর্গুমেন্ট বা রিটার্ন টাইপ জড়িত থাকলে বেশ জটিল হতে পারে।

আধুনিক সংশ্লেষণ: `typing.Protocol` এবং স্ট্যাটিক অ্যানালাইসিস

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

এটি `typing.Protocol` (PEP 544-এ) প্রবর্তনের দিকে পরিচালিত করেছে। এটি প্রোটোকলগুলি সংজ্ঞায়িত করার জন্য একটি প্রমিত এবং মার্জিত উপায় সরবরাহ করে যা প্রাথমিকভাবে Mypy, Pyright বা PyCharm's Inspector এর মতো স্ট্যাটিক টাইপ চেকারদের জন্য উদ্দিষ্ট।

একটি `Protocol` ক্লাস আমাদের `__subclasshook__` উদাহরণের মতো কাজ করে কিন্তু বয়লারপ্লেট ছাড়াই। আপনি কেবল পদ্ধতি এবং তাদের স্বাক্ষর সংজ্ঞায়িত করেন। যে কোনও ক্লাসে মিলে যাওয়া পদ্ধতি এবং স্বাক্ষর রয়েছে তা একটি স্ট্যাটিক টাইপ চেকার দ্বারা কাঠামোগতভাবে সামঞ্জস্যপূর্ণ বলে বিবেচিত হবে।

উদাহরণ: একটি `Quacker` প্রোটোকল

আসুন আধুনিক সরঞ্জাম ব্যবহার করে ক্লাসিক ডাক টাইপিং উদাহরণটি পুনরায় দেখি।

from typing import Protocol
class Quacker(Protocol):
    def quack(self, volume: int) -> str:
        """Produces a quacking sound."""
        ... # Note: The body of a protocol method is not needed
class Duck:
    def quack(self, volume: int) -> str:
        return f"QUACK! (at volume {volume})"
class Dog:
    def bark(self, volume: int) -> str:
        return f"WOOF! (at volume {volume})"
def make_sound(animal: Quacker):
    print(animal.quack(10))
make_sound(Duck()) # Static analysis passes
make_sound(Dog()) # Static analysis fails!

আপনি যদি Mypy এর মতো একটি টাইপ চেকার দিয়ে এই কোড চালান, তবে এটি `make_sound(Dog())` লাইনে একটি ত্রুটি পতাকাঙ্কিত করবে: `Argument 1 to "make_sound" has incompatible type "Dog"; expected "Quacker"`। টাইপ চেকার বুঝতে পারে যে `Dog` `Quacker` প্রোটোকল পূরণ করে না কারণ এটিতে `quack` পদ্ধতি নেই। এটি কোড চালানোর আগেই ত্রুটি ধরে।

`@runtime_checkable` সহ রানটাইম প্রোটোকল

ডিফল্টভাবে, `typing.Protocol` কেবল স্ট্যাটিক বিশ্লেষণের জন্য। আপনি যদি এটি রানটাইম `isinstance` চেক-এ ব্যবহার করার চেষ্টা করেন, তাহলে আপনি একটি ত্রুটি পাবেন।

# isinstance(Duck(), Quacker) # -> TypeError: Protocol 'Quacker' cannot be instantiated

তবে, আপনি `@runtime_checkable` ডেকোরেটর ব্যবহার করে স্ট্যাটিক বিশ্লেষণ এবং রানটাইম আচরণের মধ্যে ব্যবধান পূরণ করতে পারেন। এটি মূলত পাইথনকে আপনার জন্য স্বয়ংক্রিয়ভাবে `__subclasshook__` যুক্তি তৈরি করতে বলে।

from typing import Protocol, runtime_checkable
@runtime_checkable
class Quacker(Protocol):
    def quack(self, volume: int) -> str: ...
class Duck:
    def quack(self, volume: int) -> str: return "..."
print(f"Is Duck an instance of Quacker? {isinstance(Duck(), Quacker)}")
# Output:
# Is Duck an instance of Quacker? True

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

ব্যবহারিক সিদ্ধান্ত গ্রহণ: একটি বিশ্বব্যাপী ডেভেলপারের গাইড

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

দৃশ্যকল্প ১: একটি গ্লোবাল SaaS পণ্যের জন্য প্লাগইন আর্কিটেকচার তৈরি করা

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

• সুপারিশ: ফর্মাল ইন্টারফেস (নমিনাল `abc.ABC`)।
• যুক্তি: স্পষ্টতা, স্থিতিশীলতা এবং স্পষ্টতা অপরিহার্য। আপনার একটি অ-আলোচনামূলক চুক্তি প্রয়োজন যা প্লাগইন ডেভেলপারদের আপনার `BasePlugin` এবিসি থেকে ইনহেরিট করে ইচ্ছাকৃতভাবে অপ্ট-ইন করতে হবে। এটি আপনার API কে দ্ব্যর্থহীন করে তোলে। আপনি বেস ক্লাসে প্রয়োজনীয় সহায়ক পদ্ধতিগুলিও (যেমন, লগিং, কনফিগারেশন অ্যাক্সেস, আন্তর্জাতিকীকরণ) সরবরাহ করতে পারেন, যা আপনার ডেভেলপার ইকোসিস্টেমের জন্য একটি বিশাল সুবিধা।

দৃশ্যকল্প ২: একাধিক, সম্পর্কহীন API থেকে আর্থিক ডেটা প্রক্রিয়াকরণ

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

• সুপারিশ: প্রোটোকল (`typing.Protocol`)।
• যুক্তি: আপনি `Transaction` বেস ক্লাস থেকে ইনহেরিট করার জন্য এই তৃতীয় পক্ষের SDK গুলিগুলির সোর্স কোড পরিবর্তন করতে পারবেন না। তবে, আপনি জানেন যে তাদের প্রতিটি লেনদেন বস্তুর `get_id()`, `get_amount()`, এবং `get_currency()` এর মতো পদ্ধতি রয়েছে, এমনকি যদি তাদের নাম সামান্য ভিন্ন হয়। আপনি `TransactionProtocol` সহ অ্যাডাপ্টার প্যাটার্ন ব্যবহার করে একটি ইউনিফাইড ভিউ তৈরি করতে পারেন। একটি প্রোটোকল আপনাকে আপনার প্রয়োজনীয় ডেটার আকৃতি সংজ্ঞায়িত করার অনুমতি দেয়, যা আপনাকে যেকোনো ডেটা উত্সের সাথে কাজ করার জন্য প্রক্রিয়াকরণ যুক্তি লিখতে সক্ষম করে, যতক্ষণ না এটি প্রোটোকলের সাথে সামঞ্জস্যপূর্ণ হওয়ার জন্য মানিয়ে নেওয়া যায়।

দৃশ্যকল্প ৩: একটি বড়, মনোলিথিক লিগ্যাসি অ্যাপ্লিকেশন রিফ্যাক্টর করা

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

• সুপারিশ: একটি মিশ্রণ, তবে প্রোটোকলের উপর প্রবলভাবে নির্ভর করুন।
• যুক্তি: প্রোটোকলগুলি ধীরে ধীরে রিফ্যাক্টরিং করার জন্য একটি ব্যতিক্রমী সরঞ্জাম। আপনি `typing.Protocol` ব্যবহার করে নতুন পরিষেবাগুলির মধ্যে আদর্শ ইন্টারফেসগুলি সংজ্ঞায়িত করে শুরু করতে পারেন। তারপর, আপনি মূল লিগ্যাসি কোডটি অবিলম্বে পরিবর্তন না করে এই প্রোটোকলগুলির সাথে সামঞ্জস্যপূর্ণ করার জন্য মনোলিথের অংশগুলির জন্য অ্যাডাপ্টার লিখতে পারেন। এটি আপনাকে পর্যায়ক্রমে উপাদানগুলিকে ডিকাপল করতে দেয়। একবার একটি উপাদান সম্পূর্ণরূপে ডিকাপল হয়ে গেলে এবং কেবল প্রোটোকলের মাধ্যমে যোগাযোগ করলে, এটি তার নিজস্ব পরিষেবাতে নিষ্কাশিত হওয়ার জন্য প্রস্তুত। আনুষ্ঠানিক এবিসিগুলি নতুন, পরিষ্কার পরিষেবাগুলির মধ্যেকার মূল মডেলগুলি সংজ্ঞায়িত করতে পরে ব্যবহার করা যেতে পারে।

উপসংহার: আপনার কোডে অ্যাবস্ট্রাকশন বুনন

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

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

মূল বিষয়গুলির সারসংক্ষেপ:

• ফর্মাল ইন্টারফেস ডিজাইন (নমিনাল টাইপিং): যখন আপনার একটি স্পষ্ট, দ্ব্যর্থহীন এবং আবিষ্কারযোগ্য চুক্তির প্রয়োজন হয় তখন সরাসরি ইনহেরিটেন্স সহ `abc.ABC` ব্যবহার করুন। এটি ফ্রেমওয়ার্ক, প্লাগইন সিস্টেম এবং যেখানে আপনি ক্লাস হায়ারার্কি নিয়ন্ত্রণ করেন তার জন্য আদর্শ। এটি ঘোষণার মাধ্যমে একটি ক্লাস কী তা নিয়ে।
• প্রোটোকল ইমপ্লিমেন্টেশন (স্ট্রাকচারাল টাইপিং): যখন আপনার নমনীয়তা, ডিকাপলিং এবং বিদ্যমান কোড মানিয়ে নেওয়ার ক্ষমতা প্রয়োজন তখন `typing.Protocol` ব্যবহার করুন। এটি বাহ্যিক লাইব্রেরিগুলির সাথে কাজ করার জন্য, লিগ্যাসি সিস্টেমগুলি রিফ্যাক্টর করার জন্য এবং আচরণগত পলিমরফিজমের জন্য ডিজাইন করার জন্য উপযুক্ত। এটি একটি ক্লাস কী করতে পারে তার কাঠামোর মাধ্যমে তা নিয়ে।

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