ABC, duck typing আর Protocol — interface-এর তিন রূপ

১ · Interface মানে একটি চুক্তি

পর্ব ২৯ থেকে আপনি class বানাচ্ছেন, পর্ব ৩১-এ দেখেছেন একটি class আরেকটি থেকে কীভাবে inheritance পায়। এবার একটি গভীর প্রশ্ন: একটি ফাংশন যখন কোনো object হাতে পায়, তখন সে আসলে কী চায়? একটি নির্দিষ্ট class? নাকি শুধু কয়েকটি কাজ করার ক্ষমতা?

একটি অনলাইন দোকানের কথা ভাবুন। অর্ডার নিশ্চিত হলে ক্রেতাকে একটি বার্তা পাঠাতে হবে। আজ সেটি SMS, কাল হয়তো ইমেইল, পরশু কোনো অ্যাপের notification. অর্ডারের কোডের কিন্তু এসব জানার দরকার নেই। তার দরকার শুধু একটি জিনিস — এমন কেউ, যাকে “এই নম্বরে এই বার্তা পাঠাও” বললে সে পাঠিয়ে দেবে. এই “বললে করে দেবে” প্রতিশ্রুতিটিকেই বলে interface: কোন কোন method থাকবে, কী নেবে, কী ফেরত দেবে — একটি চুক্তি।

চুক্তিটির একটি নাম দিই: Notifier — “যার send(to, text) method আছে”। Python-এ এই চুক্তি প্রকাশ করার তিনটি উপায় আছে, আর তিনটির দর্শন আলাদা:

তিনটিই একই প্রশ্নের উত্তর দেয় — “এই object কি আমার কাজে চলবে?” — কিন্তু কখন আর কীভাবে সেটি যাচাই হয়, তাতে পার্থক্য। Duck typing যাচাই করে একদম শেষ মুহূর্তে, method ডাকার সময়। ABC যাচাই করে object বানানোর সময়। Protocol যাচাই করে কোড চালানোর আগেই, একটি আলাদা টুল দিয়ে। এই পর্বের বাকিটা এই তিনটি পথ একে একে দেখা, আর শেষে কোনটি কখন বেছে নেবেন তা ঠিক করা।

২ · Duck typing — হাঁসের মতো ডাকলেই হাঁস

পর্ব ০৬-এ duck typing-এর নাম শুনেছিলেন। পুরো কথাটি একটি পুরোনো প্রবাদ থেকে: “যদি দেখতে হাঁসের মতো, হাঁটে হাঁসের মতো, আর ডাকে হাঁসের মতো — তাহলে এটা হাঁসই”। Python-এর ভাষায়: object-টি কোন class-এর, তা জিজ্ঞেস করবেন না; দেখুন সে দরকারি কাজটি করতে পারে কি না.

আপনি না জেনেই এতদিন duck typing ব্যবহার করছেন। কয়েকটি উদাহরণ:

• যেকোনো iterable: for x in ... লুপ list, tuple, string, dict, set, ফাইল, range, generator — সবকিছুর ওপর চলে। লুপ কখনো জিজ্ঞেস করে না “এটা কি list?” সে শুধু iter() ডাকে (পর্ব ৩৪-এ এর ভেতরের গল্প)।
• File-like object: print("হ্যালো", file=x) লিখলে x কোনো আসল ফাইল হতে হবে না — যার একটি write() method আছে, সে-ই চলবে। json.dump(data, x)-ও একই রকম। পর্ব ২৫-এর file object, মেমরিতে লেখার জন্য io.StringIO, নেটওয়ার্ক socket-এর মোড়ক — সবাই এই চুক্তি মানে।
• len(), in, +: পর্ব ৩০-এ দেখেছেন, len(x) আসলে x.__len__() ডাকে। যার __len__ আছে, তার দৈর্ঘ্য মাপা যায় — class যা-ই হোক। এই dunder method-গুলোই Python-এর অলিখিত interface.

এবার অর্ডারের উদাহরণে duck typing:

class SmsNotifier:
    def send(self, to, text):
        print(f"SMS → {to}: {text}")

class EmailNotifier:                 # SmsNotifier-এর সাথে কোনো সম্পর্ক নেই
    def send(self, to, text):
        print(f"Email → {to}: {text}")

def confirm_order(notifier, phone):
    notifier.send(phone, "অর্ডার নিশ্চিত")   # শুধু ডেকে দেখা

confirm_order(SmsNotifier(), "01700-000000")
confirm_order(EmailNotifier(), "rina@example.com")

দুটি class-এর কোনো সাধারণ পূর্বপুরুষ নেই, কেউ কোনো চুক্তিতে সই করেনি। তবু confirm_order দুজনের সাথেই কাজ করে, কারণ দুজনেরই send আছে। একই ফাংশন ভিন্ন ভিন্ন class-এর object-এর সাথে চলা — একে বলে polymorphism, আর Python-এ এর সবচেয়ে হালকা রূপ duck typing.

Duck typing আর EAFP — জিজ্ঞেস না করে চেষ্টা

পর্ব ২৪-এ দুটি নীতি দেখেছিলেন: LBYL (“লাফ দেওয়ার আগে দেখুন”) আর EAFP (“অনুমতির চেয়ে ক্ষমা চাওয়া সহজ”)। Duck typing স্বাভাবিকভাবেই EAFP-এর সঙ্গী। কেউ যদি ভুল জিনিস পাঠায়, সেটি আগে থেকে পরীক্ষা না করে সরাসরি ডাকুন, আর সমস্যা হলে exception ধরুন:

def save_report(report, out):
    try:
        out.write(report)            # ফাইল, StringIO, socket — যা-ই হোক
    except AttributeError:
        raise TypeError("out-এর একটি write() method থাকতে হবে") from None

এর বিপরীত ধরন, যা অন্য ভাষা থেকে আসা মানুষ (আর AI) প্রায়ই লেখে: if isinstance(out, io.TextIOWrapper): .... এতে কোডটি শুধু আসল ফাইলের সাথে চলে — StringIO বা নিজের বানানো logger পাঠালে প্রত্যাখ্যান করে, যদিও তারা দিব্যি লিখতে পারত। isinstance দিয়ে class পরীক্ষা করা মানে duck typing-এর সুবিধা নিজের হাতে বন্ধ করা।

৩ · abc.ABC আর @abstractmethod — লিখিত চুক্তি

ধরুন আপনার অনলাইন দোকান কয়েকটি পেমেন্ট পদ্ধতি নেয় — কার্ড, মোবাইল ওয়ালেট, ক্যাশ অন ডেলিভারি। প্রতিটির জন্য একটি class, আর সব class-কে দুটি কাজ পারতেই হবে: টাকা কাটা (charge) আর ফেরত দেওয়া (refund). এই নিয়মটি লিখে রাখা যায় একটি abstract base class (সংক্ষেপে ABC) দিয়ে:

from abc import ABC, abstractmethod

class PaymentGateway(ABC):
    @abstractmethod
    def charge(self, amount: int) -> str:
        """টাকা কেটে একটি transaction id ফেরত দেয়।"""

    @abstractmethod
    def refund(self, txn_id: str) -> bool:
        """টাকা ফেরত দেয়; সফল হলে True."""

দুটি জিনিস নতুন। প্রথমত, PaymentGateway inherit করেছে ABC থেকে — এটি abc module-এর একটি সহায়ক class, যা চুক্তি-যাচাইয়ের যন্ত্রটি চালু করে। দ্বিতীয়ত, @abstractmethod decorator দিয়ে চিহ্নিত method-গুলো হলো abstract method — “এর কাজ এখানে লেখা নেই, প্রতিটি subclass-কে নিজে লিখতে হবে”। শরীরে শুধু docstring, কারণ এখানে কাজ করার কিছু নেই।

এর ফল: যতক্ষণ কোনো class-এ অন্তত একটি abstract method অপূর্ণ থাকে, ততক্ষণ সেটি একটি abstract class — তার object বানানো (instantiate করা) যায় না। সব abstract method লেখা হলে class-টি হয় concrete class. ধাপে ধাপে দেখুন — একজন ডেভেলপার কার্ড পেমেন্টের class লিখছেন, কিন্তু প্রথমে refund লিখতে ভুলে গেছেন:

1class PaymentGateway(ABC):2    @abstractmethod3    def charge(self, amount): ...4    @abstractmethod5    def refund(self, txn_id): ...67class CardGateway(PaymentGateway):8    def charge(self, amount): return "TX-1"9    def refund(self, txn_id): return True   # পরে যোগ1011g = CardGateway()12print(g.charge(500), g.refund("TX-1"))

Python 3.14-এ পুরো error বার্তাটি এমন (Python 3.12 থেকে এই ভাষা; আগের version-এ লেখা ছিল with abstract method refund):

TypeError: Can't instantiate abstract class CardGateway without an implementation for abstract method 'refund'

একাধিক method বাকি থাকলে বার্তায় সবগুলোর নাম আসে — abstract methods 'charge', 'refund'. এটি একটি ছোট কিন্তু দামি সুবিধা: ভুলটা ধরা পড়ে প্রোগ্রাম শুরুর প্রথম মুহূর্তেই, যে বিরল পথে refund ডাকা হয় সেখানে পৌঁছানোর অনেক আগে।

Abstract property — শুধু method নয়, বৈশিষ্ট্যও চুক্তিতে

কখনো চুক্তিতে একটি মান থাকা দরকার, method নয় — যেমন প্রতিটি পেমেন্ট পদ্ধতির একটি নাম, যা রসিদে ছাপা হবে। পর্ব ৩২-এর property-র সাথে @abstractmethod মিলিয়ে এটি লেখা যায়। ক্রম গুরুত্বপূর্ণ: @property থাকবে বাইরে (ওপরে), @abstractmethod ভেতরে:

class PaymentGateway(ABC):
    @property
    @abstractmethod
    def name(self) -> str: ...

class WalletGateway(PaymentGateway):
    @property
    def name(self) -> str:
        return "মোবাইল ওয়ালেট"

এখন name না লিখলে subclass-এর object তৈরি হবে না — ঠিক method-এর মতোই। একে বলে abstract property. (পুরোনো কোডে @abstractproperty দেখতে পারেন; সেটি Python 3.3 থেকে বাতিলের পথে — নতুন কোডে ওপরের ধরনই লিখুন।)

৪ · ABC-র ভেতরে সাধারণ method — template method আর register()

ABC মানে শুধু খালি method-এর তালিকা নয়। এর ভেতরে পুরোপুরি কাজ করা সাধারণ method-ও রাখা যায় — আর সেই method abstract method-গুলোকে ডাকতে পারে। এটাই ABC-র আসল শক্তি।

অনলাইন দোকানে প্রতিটি checkout-এ কয়েকটি ধাপ একই: টাকার পরিমাণ যাচাই, টাকা কাটা, রসিদ তৈরি, লগ লেখা। শুধু “টাকা কাটা” ধাপটি পেমেন্ট পদ্ধতিভেদে আলাদা। তাহলে একই ধাপগুলো ABC-তে একবার লিখুন, আর আলাদা অংশটি abstract রাখুন:

class PaymentGateway(ABC):
    @abstractmethod
    def charge(self, amount: int) -> str: ...

    def checkout(self, amount: int) -> str:      # সাধারণ method
        if amount <= 0:
            raise ValueError("টাকার পরিমাণ শূন্যের বেশি হতে হবে")
        txn = self.charge(amount)                 # subclass-এর কাজ
        return f"রসিদ: {txn}, {amount} টাকা"

checkout হলো কাঠামো — কোন ধাপ কখন হবে, তা এখানে স্থির। charge হলো সেই কাঠামোর একটি ফাঁকা ঘর, যা প্রতিটি subclass পূরণ করে। এই নকশার নাম template method pattern — ১৯৯৪ সালের বিখ্যাত “Design Patterns” বই (যার চার লেখককে “Gang of Four” বলা হয়) এটিকে নাম দিয়েছিল। এর লাভ: যাচাইয়ের নিয়ম বদলাতে হলে একটি জায়গায় বদলালেই সব পেমেন্ট পদ্ধতিতে কার্যকর হয়; কোনো নতুন পদ্ধতি যাচাই বাদ দিতে পারে না।

register() — inheritance ছাড়া সদস্যপদ

ধরুন একটি তৃতীয় পক্ষের library-তে LegacyGateway নামে একটি class আছে, যার charge আর refund দুটিই আছে, কিন্তু সেটি আপনার PaymentGateway থেকে inherit করেনি — করবেই বা কীভাবে, সেটি আপনার চুক্তি সম্পর্কে জানেই না। আপনি তার কোড বদলাতে পারবেন না। তবু চান isinstance(x, PaymentGateway) তার জন্য True হোক। এর জন্য আছে:

PaymentGateway.register(LegacyGateway)
isinstance(LegacyGateway(), PaymentGateway)    # True

এভাবে নিবন্ধিত class-কে বলে virtual subclass. তবে সাবধান — এখানে Python কিছুই যাচাই করে না. LegacyGateway-এর refund না থাকলেও register চুপচাপ মেনে নেবে। এটি আপনার একটি ঘোষণা মাত্র: “আমি কথা দিচ্ছি, এই class চুক্তি মানে”। আর virtual subclass ABC-র সাধারণ method (যেমন checkout) পায় না, কারণ আসল inheritance হয়নি। Python নিজে এটি ব্যবহার করে: list, tuple, str কোনো ABC থেকে inherit করে না, কিন্তু collections.abc-এর Sequence-পরিবারে নিবন্ধিত (list আসলে MutableSequence-এ, যা Sequence-এরই subclass) — তাই isinstance([1, 2], Sequence) হয় True.

৫ · collections.abc — দুটি method লিখুন, পাঁচটি বিনামূল্যে

নিজে ABC লেখার আগে জেনে রাখুন, Python-এর standard library-তে আগে থেকেই একগুচ্ছ তৈরি ABC আছে, collections.abc module-এ। এগুলো Python-এর নিজের অলিখিত interface-গুলোকে লিখিত রূপ দেয় — “iterable হওয়া মানে কী”, “sequence হওয়া মানে কী”। সবচেয়ে কাজের কয়েকটি:

তৃতীয় কলামটিই আসল উপহার। এগুলোকে বলে mixin method — ABC নিজেই আপনার লেখা কয়েকটি মৌলিক method ব্যবহার করে বাকিগুলো তৈরি করে দেয়। উদাহরণ: একটি গানের অ্যাপের read-only Playlist, যেটি দেখতে-শুনতে tuple-এর মতো আচরণ করবে। Sequence থেকে inherit করে মাত্র দুটি method লিখি:

1class Playlist(Sequence):2    def __init__(self, songs):3        self._songs = tuple(songs)4    def __getitem__(self, i):5        return self._songs[i]6    def __len__(self):7        return len(self._songs)89p = Playlist(["Nodi", "Megh", "Brishti"])10print("Megh" in p)11print(p.index("Brishti"), list(reversed(p)))

এখানে একটি দক্ষতার কথা মনে রাখুন: mixin method সাধারণ, তাই সবসময় সবচেয়ে দ্রুত নয়। Sequence-এর __contains__ প্রতিবার শুরু থেকে খোঁজে; আপনার ডেটা যদি set-এ রাখা থাকে, তাহলে নিজের দ্রুত __contains__ লিখে mixin-টিকে override করতে পারেন। ABC শুধু ন্যূনতম দেয়, সীমা টানে না।

isinstance(x, Iterable) — আর তার সীমা

কিছু ছোট ABC — Iterable, Sized, Container, Hashable, Callable — একটু অন্যভাবে কাজ করে। এদের জন্য inherit বা register কিছুই লাগে না; class-এ দরকারি dunder method থাকলেই isinstance True দেয়। যেমন __len__ আছে এমন যেকোনো class-এর object-এর জন্য isinstance(obj, Sized) সত্য। (এটি হয় __subclasshook__ নামের একটি বিশেষ class method দিয়ে।) অর্থাৎ এই ছোট ABC-গুলো ভেতরে ভেতরে duck typing-ই করছে, শুধু একটি নাম দিয়ে।

তবে Sequence বা Mapping-এর ক্ষেত্রে এটি হয় না। শুধু __getitem__ আর __len__ লিখলেই isinstance(obj, Sequence) সত্য হবে না — inherit বা register করতে হবে। কারণ “sequence” হওয়ার অর্থ শুধু method-এর নামে নয়: __getitem__ একটি dict-এরও আছে, কিন্তু dict sequence নয়।

এবার প্রথম runnable প্রোগ্রাম: একটি অসম্পূর্ণ পেমেন্ট class-এর TypeError ধরা, সম্পূর্ণ class দিয়ে template method চালানো, আর দুটি method-এর Playlist থেকে বিনামূল্যের method ব্যবহার। চালানোর আগে শেষ লাইনের চারটি মান অনুমান করুন:

from abc import ABC, abstractmethod
from collections.abc import Sequence

class PaymentGateway(ABC):
    @abstractmethod
    def charge(self, amount): ...
    def checkout(self, amount):               # সাধারণ method
        return f"[{self.charge(amount)}] রসিদ তৈরি"

class Draft(PaymentGateway): pass             # charge লেখা হয়নি
try:
    Draft()
except TypeError as e:
    print("TypeError:", e)

class CardGateway(PaymentGateway):
    def charge(self, amount): return f"card {amount} tk"
print(CardGateway().checkout(500))

class Playlist(Sequence):                     # শুধু দুটি method
    def __init__(self, songs): self._songs = tuple(songs)
    def __getitem__(self, i): return self._songs[i]
    def __len__(self): return len(self._songs)

p = Playlist(["Nodi", "Megh", "Brishti"])
print("Megh" in p, p.index("Brishti"), p.count("Nodi"), list(reversed(p)))

৬ · typing.Protocol — আকার দেখে চুক্তি

ABC শক্তিশালী, কিন্তু তার একটি শর্ত আছে: চুক্তি মানতে হলে inherit করতেই হবে (অথবা কাউকে register করতে হবে)। এই ধরনকে বলে nominal typing — সদস্যপদ নাম ধরে, বংশপরিচয় দেখে। এতে দুটি সমস্যা:

• তৃতীয় পক্ষের library-র class আপনার ABC থেকে inherit করে না, আর আপনি তাদের কোড বদলাতে পারেন না।
• ছোট একটি চাহিদার জন্য (“শুধু একটি area() method চাই”) সবাইকে একটি নির্দিষ্ট বংশে বাঁধা ভারী মনে হয় — বিশেষ করে Python-এ, যেখানে duck typing-ই স্বাভাবিক।

এর সমাধান Protocol, যা এসেছে Python 3.8-এ (PEP 544). Protocol দেখতে একটি class-এর মতো, কিন্তু অর্থ ভিন্ন: “যে class-এ এই method-গুলো আছে, সে-ই আমার সদস্য — inherit করুক বা না করুক”। একে বলে structural typing — সদস্যপদ আকার দেখে। এক কথায়, Protocol হলো লিখিত duck typing.

import math
from typing import Protocol

class HasArea(Protocol):
    def area(self) -> float: ...

class Circle:                          # HasArea-র নামও জানে না
    def __init__(self, r: float) -> None:
        self.r = r
    def area(self) -> float:
        return math.pi * self.r ** 2

class Label:                           # area নেই
    def __init__(self, text: str) -> None:
        self.text = text

def describe(shape: HasArea) -> str:
    return f"ক্ষেত্রফল {shape.area():.1f}"

এখানে : HasArea একটি type hint. পর্ব ০৬-এ দেখেছিলেন, Python নিজে চালানোর সময় type hint যাচাই করে না। যাচাই করে একটি আলাদা টুল — type checker, যেমন mypy বা pyright — কোড না চালিয়েই, শুধু পড়ে। তাহলে Protocol-এর চুক্তি বাস্তবে কার্যকর হয় type checker-এর চোখে। নিচের ডায়াগ্রামে দেখুন, একই কোড type checker কীভাবে দেখে, আর ABC হলে কী হতো:

class HasArea(Protocol):
    def area(self) -> float: ...      # শরীর ফাঁকা: শুধু আকার

Success: no issues found in 1 source file
# Circle-এর area() -> float আছে — আকার মিলেছে

error: Argument 1 to "describe" has incompatible type "Label";
expected "HasArea"  [arg-type]
# কোড চালানোর আগেই ধরা পড়ল

describe(Circle(2))
error: ... incompatible type "Circle"; expected "Shape"
isinstance(Circle(2), Shape)   # False
# area() থাকলেও Circle "Shape বংশের" নয়

isinstance(Circle(2), HasArea)     # True
isinstance(Label("x"), HasArea)    # False
class Odd:
    def area(self, unit, scale): ...
isinstance(Odd(), HasArea)         # True (!)

Protocol থেকে inherit করা নিষেধ নয় — চাইলে class Circle(HasArea): লিখে স্পষ্ট করতে পারেন, তাতে type checker নিশ্চিত করবে আপনি চুক্তি ঠিকমতো পূরণ করেছেন। কিন্তু দরকার নেই, আর সেটাই Protocol-এর মূল আকর্ষণ। এভাবে আপনি এমন class-এর জন্যও চুক্তি লিখতে পারেন যা অন্য কেউ, অন্য কোথাও, আপনার চুক্তির কথা না জেনে লিখেছে।

@runtime_checkable কখন

কখনো সত্যিই চালানোর সময় পরীক্ষা দরকার — যেমন একটি plugin সিস্টেম, যেখানে বাইরে থেকে আসা object-এর ধরন জানা নেই। তখন Protocol-এর ওপরে @runtime_checkable লিখলে isinstance কাজ করে। কিন্তু ডায়াগ্রামের শেষ ধাপটি মনে রাখুন: এটি শুধু method-এর নাম আছে কি না দেখে। এটি একটি দ্রুত ছাঁকনি, পূর্ণ যাচাই নয়। আর দুটি ব্যবহারিক কথা: (১) এই পরীক্ষা সাধারণ isinstance-এর চেয়ে বেশ ধীর, তাই গরম লুপের ভেতরে ব্যবহার করবেন না; (২) পরীক্ষাটি “পাস” করলেই ধরে নেবেন না যে method ঠিকমতো ডাকা যাবে।

৭ · Dependency injection — চুক্তি দিয়ে অংশ বদলানো

এবার সব মিলিয়ে একটি বাস্তব নকশা। ধরুন OrderService অর্ডার নেয় আর ক্রেতাকে বার্তা পাঠায়। প্রথম চেষ্টায় অনেকে লেখেন:

class OrderService:
    def __init__(self):
        self.notifier = SmsNotifier()       # নিজেই বানিয়ে নিল

সমস্যা কোথায়? OrderService এখন চিরকালের জন্য SMS-এর সাথে বাঁধা। ইমেইলে বদলাতে এই class খুলে বদলাতে হবে। আর সবচেয়ে বড় কথা — টেস্ট চালালেই আসল SMS যাবে, প্রতিটি SMS-এর খরচ আছে, আর পরীক্ষার নম্বরে অচেনা মানুষের ফোনে “অর্ডার নিশ্চিত” পৌঁছাবে।

সমাধান: OrderService নিজে notifier বানাবে না; বাইরে থেকে কেউ একটি দেবে। আর OrderService শুধু জানবে চুক্তিটি — Notifier. এই কৌশলকে বলে dependency injection — নির্ভরতা (dependency) বাইরে থেকে “ঢুকিয়ে” দেওয়া:

এখানে FakeNotifier একটি fake object — আসল জিনিসের একটি হালকা, পরীক্ষাযোগ্য বদলি। পর্ব ৩৯-এ pytest দিয়ে unit test লেখার সময় এই কৌশল বারবার কাজে লাগবে। এবার দ্বিতীয় runnable প্রোগ্রাম — একটি Protocol চুক্তি, inheritance ছাড়া একটি fake, dependency injection, আর @runtime_checkable-এর সীমা হাতেনাতে:

from typing import Protocol, runtime_checkable

@runtime_checkable
class Notifier(Protocol):
    def send(self, to: str, text: str) -> None: ...

class FakeNotifier:                     # Notifier-কে inherit করেনি
    def __init__(self) -> None:
        self.sent: list[tuple[str, str]] = []
    def send(self, to: str, text: str) -> None:
        self.sent.append((to, text))

class OrderService:
    def __init__(self, notifier: Notifier) -> None:
        self.notifier = notifier
    def place(self, phone: str, item: str) -> None:
        self.notifier.send(phone, f"{item}: অর্ডার নিশ্চিত")

fake = FakeNotifier()
OrderService(fake).place("01700-000000", "চা")
print(fake.sent)

class Broken:
    def send(self) -> None: ...          # ভুল signature!
print(isinstance(fake, Notifier), isinstance(Broken(), Notifier))

৮ · কোনটি কখন — আর অন্য ভাষার সাথে তুলনা

তিনটি হাতিয়ারই জানলেন। এবার সবচেয়ে গুরুত্বপূর্ণ দক্ষতা — ঠিক জায়গায় ঠিকটি বেছে নেওয়া:

একটি সহজ নিয়মে বলা যায়: শুরু করুন duck typing দিয়ে. চুক্তিটি যখন কয়েক জায়গায় ব্যবহার হতে শুরু করে আর দলের অন্যদের বোঝা দরকার, তখন Protocol লিখুন — এটি কাউকে বাধ্য করে না, শুধু চুক্তিটি দৃশ্যমান করে। আর যখন একই পরিবারের class-গুলোর মধ্যে কোড ভাগ করতে চান, বা object বানানোর সময়েই অসম্পূর্ণতা আটকাতে চান, তখন ABC. প্রতিটি ছোট class-এর জন্য ABC বানানো Python-এর ধরন নয়।

Java, C++ আর Go কী করে

Java-তে interface একটি আলাদা ভাষা-উপাদান: interface Notifier { void send(String to, String text); }, আর class-কে স্পষ্ট লিখতে হয় implements Notifier. এটি পুরোপুরি nominal — একই method থাকলেও implements না লিখলে মিলবে না, আর যাচাই হয় compile-এর সময়। Python-এর ABC এর সবচেয়ে কাছের আত্মীয়, তবে Python-এ যাচাই হয় object বানানোর সময়। Go উল্টো পথে গেছে: সেখানে interface পূরণ হয় নিঃশব্দে — কোনো type-এর ঠিক method থাকলেই সে interface মানে, কোনো implements লাগে না। এটি Python-এর Protocol-এর খুব কাছের ধারণা, শুধু Go-তে compiler নিজেই যাচাই করে। TypeScript-ও structural typing ব্যবহার করে।

৯ · AI-এর যুগে — interface নকশায় AI-এর ভুল ধরা

“একটি পেমেন্ট সিস্টেম বানিয়ে দাও” বললে AI প্রায়ই একগাদা ABC, interface আর factory class নিয়ে হাজির হয় — যেন Java-র কোনো বড় প্রজেক্ট। কারণ তার প্রশিক্ষণের ডেটায় Java আর C#-এর “enterprise” ধাঁচের কোড প্রচুর। কোডটি চলে, কিন্তু ভারী, আর কিছু সূক্ষ্ম ভুল লুকিয়ে থাকে:

AI-এর লেখা কোড পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি ABC গুনেছি — প্রতিটির অন্তত দুটি subclass বা ভাগ করা কোড আছে; না থাকলে সরল করতে বলেছি
• যে class-এ @abstractmethod আছে, সেটি ABC থেকে inherit করেছে কি না দেখেছি
• একটি abstract method মুছে subclass-এর object বানিয়ে দেখেছি — TypeError আসে কি না
• isinstance আর type(x) == খুঁজেছি (Ctrl+F); প্রতিটির জায়গায় duck typing চলত কি না ভেবেছি
• @runtime_checkable-এর ওপর কোনো নিরাপত্তা বা সঠিকতা নির্ভর করছে না, নিশ্চিত হয়েছি
• mypy বা pyright চালিয়ে দেখেছি Protocol-এর চুক্তি সব জায়গায় মিলছে
• নির্ভরতাগুলো constructor-এ আসছে কি না, আর টেস্টে fake বসানো যায় কি না দেখেছি