SOLID ১ — single responsibility আর open-closed principle

১ · SOLID — পাঁচটি অক্ষর, একটি লক্ষ্য

পর্ব ২৫-এ (Modularity, coupling আর cohesion) আপনি ভালো নকশার দুটি মাপকাঠি দেখেছেন: module-গুলো একে অপরের ওপর যত কম নির্ভর করে (কম coupling), আর একটি module-এর ভেতরের অংশগুলো যত বেশি একই উদ্দেশ্যে কাজ করে (বেশি cohesion), নকশা তত সহজে বদলানো যায়। পর্ব ২৬-এ (নকশার নীতি) DRY, KISS, YAGNI আর separation of concerns দেখেছেন। সেগুলো ছিল সাধারণ উপদেশ। এবার object-oriented নকশার জন্য সবচেয়ে পরিচিত পাঁচটি নীতি — একসাথে যাদের নাম SOLID.

পাঁচটির পেছনে একটিই লক্ষ্য: বদল যেন সস্তা আর নিরাপদ হয়। বড় খরচ প্রথমবার লেখায় নয়, পরের বছরগুলোর বদলে (পর্ব ৩). একটি অনুরোধ এলে কতগুলো file খুলতে হয়, কতগুলো test আবার চালাতে হয়, আর কতজনের কোড ভাঙার ভয় থাকে — SOLID এই প্রশ্নগুলোর উত্তর ছোট রাখার কৌশল।

২ · SRP-এর আসল কথা — “এক কাজ” নয়, “এক actor”

সবচেয়ে বেশি শোনা ব্যাখ্যা: “একটি class একটিই কাজ করবে।” শুনতে সহজ, কিন্তু Martin নিজেই বলেছেন এটি ভুল পড়া। “একটি function একটি কাজ করবে” — এটি function ছোট রাখার আলাদা একটি পরামর্শ (পর্ব ৪১-এ clean code). Single responsibility principle-এর কথা অন্য জায়গায়: কে এই কোডের বদল চায়।

সংজ্ঞাটি সময়ের সাথে পরিষ্কার হয়েছে:

• পুরোনো রূপ (Martin-এর Agile Software Development: Principles, Patterns, and Practices, ২০০২-এর কাছাকাছি): “A class should have only one reason to change.” — একটি class-এর বদলানোর কারণ থাকবে একটিই।
• পরের রূপ (Clean Architecture, ২০১৭): “A module should be responsible to one, and only one, actor.” — একটি module-এর জবাবদিহি থাকবে একটি, এবং কেবল একটি, actor-এর কাছে।

“কারণ” শব্দটি ঝাপসা ছিল: bug ঠিক করা কি একটি কারণ? নতুন library? Martin তাই কারণটিকে মানুষের সাথে বাঁধলেন। এখানে actor মানে একজন ব্যক্তি নয়, একদল মানুষ (বা একটি ভূমিকা), যাঁরা একই ধরনের বদল চান — হিসাব বিভাগ, মানবসম্পদ, অপারেশন দল, পরীক্ষা বোর্ড। পর্ব ২২-২৩-এর use case-এর actor-এর সাথে মিল আছে (দুটিই ভূমিকা), কিন্তু প্রশ্ন আলাদা: use case-এ “কে system ব্যবহার করেন”, SRP-তে “কে এই অংশের বদল চাইবেন”।

একটি পরিচিত উদাহরণের ভাবনা

Clean Architecture-এ Martin একটি বেতন-ব্যবস্থার উদাহরণ দেন, যার ভাবনাটি আমরা সাধারণভাবে বলি: একটি Employee class-এ তিনটি method — calculatePay() (হিসাব বিভাগ ঠিক করে বেতন কীভাবে হবে), reportHours() (মানবসম্পদ বিভাগ ঠিক করে কাজের ঘণ্টার report কেমন হবে), আর save() (database দেখেন যাঁরা, তাঁরা ঠিক করেন কীভাবে সংরক্ষণ হবে)। তিনটি method, তিনটি actor. ধরুন দুটি method একটি সাধারণ helper ব্যবহার করে — “নিয়মিত ঘণ্টা” হিসাবের একই function. হিসাব বিভাগের অনুরোধে developer helper-টি বদলালেন; মানবসম্পদের report-এর সংখ্যাও চুপচাপ বদলে গেল, আর কেউ টের পেলেন না, কারণ মানবসম্পদ দলের কাছে কেউ জিজ্ঞেসই করেনি।

Martin এই ধরনের ভুলের নাম দিয়েছেন accidental duplication: দুটি জিনিস আজ একই রকম দেখায় বলে আমরা এক করে ফেলি, অথচ তাদের বদলের কারণ আলাদা। পর্ব ২৬-এর DRY বলে জ্ঞানের পুনরাবৃত্তি করবেন না — কিন্তু দুটি দলের দুটি আলাদা নিয়ম আকস্মিকভাবে একই সূত্রে লেখা হলে সেটা একই “জ্ঞান” নয়।

চালিয়ে দেখুন — একটি অনুরোধ, দুটি নকশা

একটি কাল্পনিক courier কোম্পানির মাসিক report. ReportService তিনটি কাজ করে: মোট টাকা যোগ (finance দল), report-এর চেহারা (accounts দল), আর archive file-এর নাম (ops দল)। তারিখের format একটি setting-এ রাখা, যা দুই জায়গায় লাগে। Accounts দল চাইল তারিখ 05-01-2026-এর বদলে 05/01/2026 দেখাতে। নিচের কোড একই অনুরোধ দুটি নকশায় চালায়, আর দেখায় কী কী বদলাল।

from datetime import date
ROWS = [("P-101", 450, date(2026, 1, 5)), ("P-102", 1200, date(2026, 1, 5))]

class ReportService:                 # BEFORE: one class, three actors
    date_fmt = "%d-%m-%Y"            # one setting shared by two actors
    def total(self, rows):           # finance team: how money is added
        return sum(fee for _, fee, _ in rows)
    def format(self, rows):          # accounts team: what the sheet looks like
        r = rows[0]
        return f"{r[2].strftime(self.date_fmt)} {r[0]} {r[1]} ... TOTAL {self.total(rows)}"
    def save(self, rows):            # ops team: archive file name
        return f"report_{rows[0][2].strftime(self.date_fmt)}.txt"

class TotalCalculator:               # AFTER: one class per actor
    def total(self, rows): return sum(fee for _, fee, _ in rows)
class ReportFormatter:
    def __init__(self, fmt="%d-%m-%Y"): self.fmt = fmt
    def format(self, rows):
        r = rows[0]
        return f"{r[2].strftime(self.fmt)} {r[0]} {r[1]} ... TOTAL {TotalCalculator().total(rows)}"
class ReportArchive:
    def save(self, rows): return f"report_{rows[0][2].strftime('%d-%m-%Y')}.txt"

def compare(title, old, new):
    print(title)
    for part, a, b in zip(("total", "sheet", "archive"), old, new):
        print(f"  {part:8}: {a}  ->  {b}  " + ("same" if a == b else "CHANGED"))

svc = ReportService(); old = (svc.total(ROWS), svc.format(ROWS), svc.save(ROWS))
svc.date_fmt = "%d/%m/%Y"            # accounts team asks for slashes
compare("BEFORE: one ReportService", old, (svc.total(ROWS), svc.format(ROWS), svc.save(ROWS)))
calc, fmt, arc = TotalCalculator(), ReportFormatter(), ReportArchive()
old = (calc.total(ROWS), fmt.format(ROWS), arc.save(ROWS))
fmt = ReportFormatter("%d/%m/%Y")    # the same request, now in one class
compare("AFTER: split by actor", old, (calc.total(ROWS), fmt.format(ROWS), arc.save(ROWS)))

BEFORE: one ReportService
  total   : 1650  ->  1650  same
  sheet   : 05-01-2026 P-101 450 ... TOTAL 1650  ->  05/01/2026 P-101 450 ... TOTAL 1650  CHANGED
  archive : report_05-01-2026.txt  ->  report_05/01/2026.txt  CHANGED
AFTER: split by actor
  total   : 1650  ->  1650  same
  sheet   : 05-01-2026 P-101 450 ... TOTAL 1650  ->  05/01/2026 P-101 450 ... TOTAL 1650  CHANGED
  archive : report_05-01-2026.txt  ->  report_05-01-2026.txt  same

৩ · Actor আর পরিবর্তনের কারণ খোঁজা

SRP মানার কাজ আসলে একটি অনুসন্ধান: প্রতিটি অংশের বদল কে চাইবেন? কয়েকটি ব্যবহারিক প্রশ্ন সাহায্য করে:

• “এই method-এর আচরণ বদলাতে হলে কার অনুমতি লাগবে?” যাঁর অনুমতি, তিনিই actor. বেতনের সূত্রের জন্য হিসাব বিভাগ, receipt-এর নকশার জন্য সামনের ডেস্ক।
• “কোন meeting-এ এই বদলের সিদ্ধান্ত হবে?” দুটি method-এর সিদ্ধান্ত যদি দুটি আলাদা meeting-এ, দুটি আলাদা বিভাগে হয়, তারা আলাদা actor-এর।
• Git-এর ইতিহাস দেখুন। কোন file কারা, কোন অনুরোধে বদলেছেন — অংশ ৯-এ বাস্তব একটি git log দেখবেন।
• নাম পরীক্ষা। Class-এর নাম দিতে “and” বা “Manager”, “Helper”, “Util” লাগলে সন্দেহ করুন: FeeAndReceiptAndSmsManager নিজেই নিজের সমস্যা বলে দিচ্ছে।

এখন একটি ছোট বিশ্লেষক। একটি কাল্পনিক স্কুলের বেতন-ব্যবস্থার প্রতিটি method-এর পাশে লেখা আছে কোন actor তার বদল চান। প্রোগ্রামটি class ধরে actor গোনে, একাধিক actor হলে SRP লঙ্ঘন বলে কীভাবে ভাঙা যায় দেখায়, আর উল্টো দিকের একটি সতর্কসংকেতও খোঁজে — একই actor-এর জন্য খুব ছোট ছোট আলাদা class.

// "Reasons to change" analyser for a fictional school-fee system.
// Each method is tagged with the actor (the group of people) who asks
// for its changes. A class that serves more than one actor is flagged.
const classes = {
  FeeManager: { calculateFee: "accounts", applyScholarship: "accounts",
                printReceipt: "front-desk", sendSmsReminder: "guardian-office",
                exportBoardCsv: "exam-board" },
  StudentRepo: { findById: "it", save: "it" },
  ReceiptLayout: { header: "front-desk" },
  ReceiptFooter: { footer: "front-desk" },
};
const actorsOf = {};                      // actor -> [class.method]
for (const [cls, methods] of Object.entries(classes)) {
  const byActor = {};
  for (const [m, actor] of Object.entries(methods)) {
    (byActor[actor] ??= []).push(m);
    (actorsOf[actor] ??= new Set()).add(cls);
  }
  const n = Object.keys(byActor).length;
  console.log(`${cls}: ${n} actor(s) ${n > 1 ? "-> SRP violation" : "ok"}`);
  if (n > 1) for (const [a, ms] of Object.entries(byActor))
    console.log(`   split -> ${a}: ${ms.join(", ")}`);
}
for (const [actor, set] of Object.entries(actorsOf)) {
  const solo = [...set].filter(c => Object.keys(classes[c]).length === 1 &&
    Object.values(classes[c]).every(a => a === actor));
  if (solo.length > 1)
    console.log(`hint: ${solo.join(" + ")} change together for "${actor}"` +
                " -> maybe over-split, consider merging");
}

FeeManager: 4 actor(s) -> SRP violation
   split -> accounts: calculateFee, applyScholarship
   split -> front-desk: printReceipt
   split -> guardian-office: sendSmsReminder
   split -> exam-board: exportBoardCsv
StudentRepo: 1 actor(s) ok
ReceiptLayout: 1 actor(s) ok
ReceiptFooter: 1 actor(s) ok
hint: ReceiptLayout + ReceiptFooter change together for "front-desk" -> maybe over-split, consider merging

এবার ReportService-কে হাতে ধরে ভাঙি — শুধু কোড নয়, প্রতিটি সিদ্ধান্তের কারণসহ। “পরে” চাপুন।

৪ · SRP-এর তিন স্তর — আর বেশি ভাঙার বিপদ

“Module” শব্দটি Martin ইচ্ছা করেই ব্যবহার করেছেন: এক file, এক class, এক package বা এক service — যেকোনো স্তরে একই প্রশ্ন চলে। তবে প্রতিটি স্তরে প্রশ্নের চেহারা একটু আলাদা।

SRP-এর সাথে পুরোনো একটি ধারণার গভীর মিল আছে: David Parnas-এর ১৯৭২ সালের বিখ্যাত প্রবন্ধ “On the Criteria to Be Used in Decomposing Systems into Modules”. Parnas বলেছিলেন, module ভাগ করুন যে সিদ্ধান্তগুলো বদলাতে পারে সেগুলো ধরে — প্রতিটি module একটি সিদ্ধান্ত লুকিয়ে রাখবে, যাতে সিদ্ধান্ত বদলালে শুধু সেই module বদলায়। এর নাম information hiding. Martin-এর actor সেই সিদ্ধান্তের মালিককে নাম দিল।

বেশি ভাঙা — উল্টো দিকের রোগ

SRP শেখার পরে অনেকে এমন কোড লেখেন: InvoiceTotalAdder, InvoiceTaxAdder, InvoiceLineCounter, InvoiceRounder — প্রতিটিতে একটি করে method. সমস্যা কী?

• একটি বদলে অনেক file. VAT-এর নিয়ম বদলালে tax, total আর rounding তিনটি file খুলতে হয়, কারণ তারা আসলে একই নিয়মের অংশ। Martin Fowler এই অবস্থার নাম দিয়েছেন shotgun surgery — একটি বদলের জন্য অনেক জায়গায় ছোট ছোট কাটাছেঁড়া (পর্ব ৪২-এ code smell).
• Cohesion কমে যায়। যে জিনিসগুলো একসাথে বদলায়, সেগুলো ছড়িয়ে পড়লে module-এর ভেতরের মিল কমে, বাইরের নির্ভরতা বাড়ে — পর্ব ২৫-এর ঠিক উল্টো লক্ষ্য।

৫ · OCP — Meyer থেকে Martin

Open-closed principle-এর ধারণা Meyer-এর; তাঁর ১৯৮৮-এর বইয়ের ভাষা ছিল “Modules should be both open and closed.” আজকের প্রচলিত বাক্যটি Martin-এর ১৯৯৬-এর লেখায় Meyer-এর নামে উদ্ধৃত: “Software entities (classes, modules, functions…) should be open for extension, but closed for modification.” — বাড়ানোর জন্য খোলা, বদলানোর জন্য বন্ধ। প্রথম শুনলে স্ববিরোধী মনে হয়: বদল না করে নতুন আচরণ আসবে কীভাবে?

Meyer-এর OCP (১৯৮৮) — inheritance দিয়ে

Meyer-এর যুগে একটি বড় সমস্যা ছিল: একটি module compile হয়ে library হয়ে গেলে অনেক দল সেটি ব্যবহার করছে। তাকে বদলালে সবাইকে আবার compile, test আর release করতে হয়। Meyer-এর সমাধান: module-টি “closed” — স্থির, documentation-সহ, অন্যরা ব্যবহার করছে। নতুন আচরণ চাইলে তার একটি subclass বানান (inheritance), পুরোনোটি অক্ষত রেখে। অর্থাৎ Meyer-এর OCP-তে বাড়ানোর পথ ছিল implementation inheritance — parent-এর কোড উত্তরাধিকারে নিয়ে কিছু অংশ বদলে দেওয়া।

Martin-এর polymorphic OCP — abstraction আর বদলযোগ্য implementation

১৯৯০-এর দশকে Martin আর অন্যরা দেখলেন, implementation inheritance-এর নিজস্ব বিপদ আছে — parent বদলালে child-রা অপ্রত্যাশিতভাবে ভাঙে (“fragile base class” সমস্যা), আর গভীর উত্তরাধিকারের গাছ বোঝা কঠিন। Gang of Four-এর বইও (১৯৯৪) পরামর্শ দেয় “inheritance-এর চেয়ে composition” পছন্দ করতে। তাই Martin-এর রূপে OCP দাঁড়াল এভাবে:

• যে কোড স্থির থাকবে (ব্যবসার মূল ধারা), সে একটি abstraction-এর ওপর নির্ভর করবে — abstract class বা interface, যা শুধু বলে “কী করা যায়”, কীভাবে নয়।
• প্রতিটি রূপ (variant) সেই abstraction-এর একটি আলাদা implementation — নতুন class, নতুন file.
• Polymorphism — একই ডাকে ভিন্ন object-এর ভিন্ন আচরণ — দিয়ে মূল কোড না জেনেই সঠিক implementation চালায়।

Python-এ abstraction লেখা যায় abc.ABC বা typing.Protocol দিয়ে, Java-তে interface দিয়ে, JavaScript-এ প্রায়ই শুধু একটি চুক্তি — “এই object-এ cost() method থাকবে”। বিস্তারিত দেখুন Python কোর্সের ABC, duck typing আর Protocol আর Java কোর্সের polymorphism আর dynamic dispatch পর্বে। Interface-কে একটি চুক্তি হিসেবে কীভাবে লিখবেন, তা পর্ব ৩১-এ (Interface আর contract).

৬ · Type-switch থেকে registry — OCP হাতেকলমে

OCP লঙ্ঘনের সবচেয়ে চেনা চেহারা হলো type-এর ওপর if/switch: “যদি standard হয় তবে এই, express হলে ওই, same-day হলে আরেকটি।” একটি জায়গায় একবার থাকলে তেমন ক্ষতি নেই। সমস্যা শুরু হয় যখন একই switch তিন-চার জায়গায় দেখা দেয় — দাম, পৌঁছানোর সময়, label, ফেরতের নিয়ম। নতুন একটি courier type এলে প্রতিটি switch খুঁজে বের করে একটি শাখা যোগ করতে হয়; একটি ভুলে গেলে চুপচাপ ভুল ফল। Fowler-এর Refactoring-এ একে repeated switch code smell বলা হয়, আর সমাধান হিসেবে “conditional-কে polymorphism দিয়ে বদলানো” refactoring দেওয়া আছে।

নিচের কোডে একটি কাল্পনিক courier-এর shipping খরচ দুইভাবে: আগে একটি type-switch, পরে strategy object-এর একটি registry — নাম থেকে object-এর একটি dictionary, যেখানে নতুন রূপ নিজেকে নিবন্ধন করে। তারপর “cold chain” (ঠান্ডা রেখে পাঠানো) নামে নতুন একটি type যোগ হয় — কোনো পুরোনো লাইন না বদলে।

from typing import Protocol

def cost_switch(kind, kg):           # BEFORE: every new courier edits this
    if kind == "standard":   return 60 + 15 * kg
    elif kind == "express":  return 120 + 25 * kg
    elif kind == "same_day": return 250 + 30 * kg
    raise ValueError(f"unknown courier: {kind}")

class Rate(Protocol):                # AFTER: a stable abstraction
    def cost(self, kg: int) -> int: ...
RATES: dict[str, Rate] = {}
def register(name):                  # plug-in point: add, never edit
    def wrap(cls):
        RATES[name] = cls()
        return cls
    return wrap

@register("standard")
class Standard:
    def cost(self, kg): return 60 + 15 * kg
@register("express")
class Express:
    def cost(self, kg): return 120 + 25 * kg
@register("same_day")
class SameDay:
    def cost(self, kg): return 250 + 30 * kg
def cost(kind, kg): return RATES[kind].cost(kg)   # closed: never edited
for k in RATES: print(f"{k:9} 2 kg: switch={cost_switch(k, 2)} registry={cost(k, 2)}")

@register("cold_chain")              # NEW courier type, added later in a
class ColdChain:                     # new file; nothing above is edited
    def cost(self, kg): return 300 + 40 * kg + (100 if kg > 5 else 0)
print("cold_chain 2 kg:", cost("cold_chain", 2), "| 6 kg:", cost("cold_chain", 6))
try: cost_switch("cold_chain", 2)
except ValueError as e: print("switch version:", e)

standard  2 kg: switch=90 registry=90
express   2 kg: switch=170 registry=170
same_day  2 kg: switch=310 registry=310
cold_chain 2 kg: 380 | 6 kg: 640
switch version: unknown courier: cold_chain

এবার একটি পূর্ণ গল্প: একটি কাল্পনিক courier-এর checkout-এ নতুন পেমেন্ট পদ্ধতি যোগ করা। লক্ষ করুন, OCP-তে পৌঁছাতে একবার পুরোনো কোড বদলাতেই হয় — সেটা refactoring; OCP-র সুফল আসে তার পরের বদলগুলোতে।

৭ · Extension point-এর নানা রূপ

নতুন আচরণ ঢোকানোর জায়গাকে প্রায়ই extension point বলা হয় (পর্ব ২৩-এর use case-এর extension point-এর সাথে নামের মিল কাকতালীয় নয় — চিন্তাটা একই)। কোডে এটি কয়েকভাবে বানানো যায়:

শেষ কোড একটি কাল্পনিক স্কুলের বেতনে ছাড়ের নিয়ম — plugin-ধাঁচে, function-এর একটি Map দিয়ে। মূল function জানে শুধু একটি চুক্তি: “নিয়ম মানে একটি function, যে ছাত্রের তথ্য নিয়ে ছাড়ের পরিমাণ ফেরত দেয়।” কোন নিয়ম কোন ক্রমে চলবে, তা আসে configuration থেকে। JavaScript-এ function-কে মান হিসেবে ব্যবহারের ভিত্তি দেখুন functional programming পর্বে।

// Plugin-style OCP for a fictional school-fee system.
// The core knows only "a rule is a function (student) -> discount".
const rules = new Map();                         // name -> function
const addRule = (name, fn) => rules.set(name, fn);

function monthlyFee(student, enabled) {          // CORE: closed
  let fee = student.base, log = [];
  for (const name of enabled) {                  // order comes from config
    const d = rules.get(name)?.(student, fee) ?? 0;
    if (d > 0) { fee -= d; log.push(`${name} -${d}`); }
  }
  return `${student.name}: ${student.base} -> ${fee}  [${log.join(", ") || "none"}]`;
}

// built-in plugins
addRule("merit",  s => (s.gpa >= 4.5 ? 500 : 0));
addRule("staff",  (s, fee) => (s.staffChild ? Math.round(fee * 0.5) : 0));

const kids = [
  { name: "Mitu",  base: 3000, gpa: 4.8, staffChild: false, siblings: 1 },
  { name: "Rafi",  base: 3000, gpa: 3.9, staffChild: true,  siblings: 2 },
  { name: "Tanha", base: 2500, gpa: 4.6, staffChild: true,  siblings: 0 },
];
const config1 = ["merit", "staff"];
kids.forEach(k => console.log(monthlyFee(k, config1)));

// a new plugin, added later from another file -- monthlyFee is untouched
addRule("sibling", s => s.siblings * 200);
const config2 = ["sibling", "merit", "staff", "unknown-rule"];
console.log("-- after adding the sibling plugin --");
kids.forEach(k => console.log(monthlyFee(k, config2)));

Mitu: 3000 -> 2500  [merit -500]
Rafi: 3000 -> 1500  [staff -1500]
Tanha: 2500 -> 1000  [merit -500, staff -1000]
-- after adding the sibling plugin --
Mitu: 3000 -> 2300  [sibling -200, merit -500]
Rafi: 3000 -> 1300  [sibling -400, staff -1300]
Tanha: 2500 -> 1000  [merit -500, staff -1000]

৮ · OCP পরম নয় — বদল কোন দিকে আসবে, তা অনুমান

একটি প্রোগ্রাম সব ধরনের বদলের বিরুদ্ধে “closed” হতে পারে না। Courier-এর কোড নতুন courier type-এর জন্য খোলা রাখলেন — কিন্তু হঠাৎ অনুরোধ এলো, খরচ ওজনে নয়, দূরত্বে হবে। এবার Rate চুক্তিটাই (cost(kg)) ভুল; সব implementation বদলাতে হবে। Martin নিজেও লিখেছেন, কোনো উল্লেখযোগ্য প্রোগ্রাম ১০০% closed হয় না; closure হতে হবে কৌশলগত — যেদিকে বদল আসার সম্ভাবনা বেশি, সেদিকে।

সেই দিক কীভাবে অনুমান করবেন?

• ইতিহাস: গত এক-দুই বছরে কোন ধরনের বদল বারবার এসেছে? Git log আর issue tracker সবচেয়ে সৎ সাক্ষী।
• Requirement আর roadmap: পর্ব ২৪-এর backlog-এ কি দ্বিতীয় রূপের কোনো story আছে? “আগামী quarter-এ আরও দুটি courier partner” — এটা শক্ত প্রমাণ।

Martin-এর একটি পরামর্শ প্রায়ই “প্রথম গুলিটা খান” (take the first bullet) নামে উল্লেখ হয়: প্রথমে সরলভাবে লিখুন, যেন কোনো বদল আসবে না। প্রথমবার যে ধরনের বদল আসে, তখন সেই ধরনের বিরুদ্ধে abstraction বানান। এর সাথে মেলে Don Roberts-এর rule of three (Fowler-এর Refactoring-এ উল্লেখ): তৃতীয়বার একই জিনিস করতে গেলে refactor করুন। আর পর্ব ২৬-এর YAGNI — “You aren't gonna need it” — মনে করিয়ে দেয়, আজ লাগছে না এমন নমনীয়তার দাম আজই দিতে হয়: বেশি file, বেশি indirection, পড়তে বেশি সময়।

৯ · দুই নীতি একসাথে — test, review আর Git-এর ইতিহাস

SRP আর OCP একে অপরকে সাহায্য করে। SRP বদলকে এক জায়গায় আনে; OCP সেই জায়গায় বদলকে যোগ বানায়, কাটাছেঁড়া নয়। দুটোর সবচেয়ে বাস্তব লাভ দেখা যায় test-এ:

• ছোট, স্বাধীন unit test. TotalCalculator-এর test-এ file system বা তারিখের format লাগে না। প্রতিটি class একটি actor-এর নিয়ম, তাই test-এর নামও ব্যবসার ভাষায়: “VAT সহ মোট টাকা ঠিক”।
• Regression-এর ঝুঁকি কম। নতুন courier type নতুন class হলে পুরোনো class-এর কোড ছোঁয়া হয়নি; তাদের test-এর পাস করা মানে পুরোনো আচরণ অক্ষত।
• Review সহজ। Pull request-এর diff যদি শুধু নতুন file হয় (পর্ব ১৬), reviewer-এর প্রশ্ন ছোট হয়: “নতুন class কি চুক্তি মানে?”

Git দিয়ে actor খোঁজা

কোন file কয়টি actor-এর কাছে দায়বদ্ধ, তা Git ইতিহাস থেকেও আন্দাজ করা যায় — যদি commit-এ অনুরোধকারী লেখা থাকে। নিচের কাল্পনিক repository-তে প্রতিটি commit message-এর শেষে একটি trailer আছে: Requested-by: …। (Trailer-এর নিয়ম পর্ব ১৬-১৮-এ দেখেছেন; “Requested-by” এখানে আমাদের বানানো নাম, কোনো মানদণ্ড নয়।) একটি file-এর ইতিহাস থেকে trailer-গুলো তুলে গোনা হলো। উদাহরণটি Git ২.৫৩-এ বানানো:

$ git log --format="%h %s | %(trailers:key=Requested-by,valueonly,separator=%x2C)" -- report_service.py
fb2a63a feat: add VAT line to total | finance
99c877e fix: archive file name without slashes | ops
7d699b1 feat: show date as dd/mm/yyyy | accounts
fab61c5 fix: round COD fee to whole taka | finance
f0b71ae feat: add monthly parcel report | accounts
$ git log --format="%(trailers:key=Requested-by,valueonly,separator=%x2C)" -- report_service.py | sort | uniq -c
      2 accounts
      2 finance
      1 ops

১০ · AI-এর যুগে — AI-এর “SOLID” কোড যাচাই

AI-কে “এই কোড SOLID বানাও” বললে সাধারণত দ্রুত, পরিপাটি, অনেক interface-ওয়ালা কোড আসে। পরিপাটি মানেই ভালো নকশা নয়। এই বিষয়ে AI-এর চেনা ভুলগুলো:

AI-এর দেওয়া refactor হাতে পেলে — চেকলিস্ট

• প্রতিটি নতুন class-এর একটি স্পষ্ট actor আছে; একই actor-এর জিনিস অকারণে ছড়ায়নি
• প্রতিটি নতুন interface-এর পক্ষে ইতিহাস বা backlog-এর প্রমাণ আছে, নইলে সরিয়েছি
• পুরোনো test রেখে চালিয়েছি; আগে-পরে একই input-এ একই output
• Test-গুলো ফল যাচাই করে; একটি ইচ্ছাকৃত bug ঢুকিয়ে দেখেছি test ব্যর্থ হয়
• Diff পুরোটা পড়েছি, একটি আলাদা branch-এ; চোখ বন্ধ করে merge করিনি
• উদ্ধৃতি, বই আর বছর মূল উৎসে মিলিয়েছি; কোডের license আর prompt-এর গোপনীয়তা দেখেছি