Modularity, coupling আর cohesion — ভালো নকশার মাপকাঠি

১ · Modularity — বড় system কেন টুকরো করে বানাই

মডিউল ৪-এ আমরা ঠিক করেছি কী বানাতে হবে — requirement. মডিউল ৫ থেকে প্রশ্ন বদলায়: কীভাবে সাজাবেন, যাতে আজ বানানো যায় আর কাল বদলানো যায়? এই মডিউলের পথ:

একটি কাল্পনিক স্কুল ম্যানেজমেন্ট system দিয়ে পুরো পর্ব চলবে: উপস্থিতি, পরীক্ষার ফল, বেতন-ফি, অভিভাবককে SMS. প্রথম version-এ সব কোড একটি file-এ — ৪,০০০ লাইন। একদিন হেডস্যার বললেন, “রোল নম্বর এখন থেকে 2026-07-15 (বছর-শ্রেণি-রোল) আকারে হবে।” Developer খুঁজে দেখলেন, রোল নম্বর ৮৭টি জায়গায় সরাসরি ব্যবহার হয়েছে। এক লাইনের নিয়ম বদলাতে তিন দিন লাগল, আর তার পরও ফি-র রসিদে একটি ভুল থেকে গেল।

Modularity মানে system-কে এমন অংশে ভাগ করা, যাতে প্রতিটি অংশ আলাদাভাবে বোঝা, বানানো, বদলানো আর test করা যায়। ISO/IEC 25010-এ modularity হলো maintainability-র একটি উপ-বৈশিষ্ট্য — পর্ব ৩-এ (Software quality) আপনি এটি দেখেছেন। চারটি কাছাকাছি শব্দ প্রায়ই গুলিয়ে যায়:

Abstraction আর encapsulation-এর ভাষাগত রূপ Python-এ class আর object বা Java-তে encapsulation আর access modifier পর্বে দেখতে পারেন। এই পর্বের প্রশ্ন ভাষার নয়, নকশার: কোন জিনিস কোন module-এ যাবে, আর module-রা একে অপরকে কতটা জানবে? এর দুটি মাপকাঠি:

২ · Parnas ১৯৭২ — information hiding আর KWIC

সমস্যাটি KWIC index (Key Word In Context): কিছু লাইন ইনপুট দেওয়া হবে; প্রতিটি লাইনের প্রথম শব্দ বারবার শেষে সরিয়ে সব “circular shift” বানাতে হবে, তারপর সব shift বর্ণানুক্রমে সাজিয়ে ছাপাতে হবে। যেমন “Pather Panchali” থেকে দুটি shift: “Pather Panchali” আর “Panchali Pather”. প্রবন্ধের সারকথা, সংক্ষেপে:

দুটি নকশাই কাজ করে, আকারেও প্রায় সমান। পার্থক্য শুধু তখনই দেখা যায়, যখন কিছু বদলায়। Parnas-এর মূল বাক্যটির ভাবার্থ: প্রতিটি module একটি কঠিন বা বদলাতে-পারে এমন নকশা-সিদ্ধান্তকে বাকিদের কাছ থেকে লুকিয়ে রাখবে; interface এমনভাবে বানাতে হবে যাতে সেই সিদ্ধান্ত interface দিয়ে ফাঁস না হয়।

আমাদের স্কুল system-এ এর মানে: রোল নম্বরের format একটি সিদ্ধান্ত যা বদলাতে পারে, তাই সেটি student module জানবে, বাকিরা শুধু rollLabel(s) ডাকবে। ফি-র হিসাবের নিয়ম আরেকটি সিদ্ধান্ত — fees-এর ভেতরে। SMS কোন কোম্পানির gateway দিয়ে যায় — notify-এর ভেতরে। অংশ ৮-এ এই সিদ্ধান্তের দাম আমরা গুনে দেখব।

৩ · Coupling — নির্ভরতার ছয় স্তর

১৯৭০-এর দশকে IBM-এর Wayne Stevens, Glenford Myers আর Larry Constantine-এর “Structured Design” প্রবন্ধ (IBM Systems Journal, ১৯৭৪), পরে Edward Yourdon ও Constantine-এর একই নামের বই আর Myers-এর বইগুলো coupling আর cohesion-কে নকশার মাপকাঠি হিসেবে প্রতিষ্ঠা করে। Constantine এই ধারণাগুলো ১৯৬০-এর দশকের শেষ থেকেই নিয়ে কাজ করছিলেন বলে জানা যায়। নিচের ছয় স্তরের নাম আর ক্রম মূলত Myers-এর তালিকা থেকে, যা আজকের বেশিরভাগ বইয়ে চলে; Yourdon–Constantine-এর বইয়ে কিছু নাম আলাদা (যেমন stamp-কে কেউ “data-structured coupling” বলেন), আর external coupling কোথায় বসবে, তা নিয়ে বইভেদে মতভেদ আছে।

একই কাজ — একজন ছাত্রের দেরির জরিমানা (late fine) হিসাব করে রিপোর্টে দেখানো — ছয়ভাবে লেখা যায়। “পরে” চাপুন:

import * as fees from "./fees.js";
fees._ledger[15].balance -= 500;  // অন্যের ভেতরে হাত
fees._rates.late = 0;             // অন্যের গোপন নিয়ম বদল

export const SCHOOL = { lateRate: 20, ledger: {} };
// fees.js আর report.js দুজনেই পড়ে আর লেখে
SCHOOL.lateRate = 0;   // কে করল? কখন?

// দুজনেই ব্যাংকের CSV নিজে নিজে পড়ে
const amount = Number(line.split(",")[3]);
// ব্যাংক একটি কলাম সরালে দুজনেই ভাঙে

fees.compute(student, "LATE");
fees.compute(student, "MONTHLY");
// fees-এর ভেতরে: if (mode === "LATE") … else if …

fees.lateFine(student);
// student-এ নাম, ফোন, নম্বর, ঠিকানা…
// lateFine-এর লাগে শুধু student.daysLate

fees.lateFine(student.daysLate, 20);
// lateFine(10, 20) → 200
// শুধু যা লাগে, সরল মান হিসেবে

৪ · Cohesion — একসাথে থাকার সাতটি কারণ

Coupling প্রশ্ন করে “বাইরের সাথে কতটা জড়ানো?”, cohesion প্রশ্ন করে “ভেতরের জিনিসগুলো একসাথে কেন?” Yourdon ও Constantine-এর বইয়ে সাতটি স্তর আছে, দুর্বল থেকে শক্ত। (Myers-এর তালিকায় কিছু নাম আলাদা, যেমন temporal-এর বদলে “classical”, আর একটি “informational” স্তর আছে; communicational আর sequential-এর ক্রম নিয়েও বইভেদে পার্থক্য দেখা যায়।) প্রতিটি ট্যাবে একটি ছোট উদাহরণ:

class SchoolUtils {
  static formatDate(d) { … }
  static calcLateFine(days) { … }
  static sendSms(phone, text) { … }
  static backupDatabase() { … }
}

function readInput(kind) {
  if (kind === "csv") …        // ব্যাংকের file
  else if (kind === "form") …  // ভর্তির ফর্ম
  else if (kind === "card") …  // উপস্থিতির কার্ড-রিডার
}

function startOfDay() {
  openDbConnection();
  resetAttendanceSheet();
  loadSmsTemplates();
  clearPrintQueue();
}

function admitStudent(form) {
  checkSeatAvailable(form.classNo);
  printWelcomeLetter(form.name);
  updateNoticeBoard();
}

function studentSummary(record) {
  const avg = average(record.marks);
  const present = countPresent(record.attendance);
  return { avg, present };
}

function publishResult(rawSheet) {
  const marks = parseSheet(rawSheet);
  const grades = toGrades(marks);
  return renderTable(grades);
}

function gradeFromMarks(marks) {
  if (marks >= 80) return "A+";
  if (marks >= 70) return "A";
  …
}

একটি সহজ পরীক্ষা, Yourdon–Constantine-এর বইয়ের পরামর্শের কাছাকাছি: module-এর কাজ এক বাক্যে লিখুন। বাক্যে “এবং” বা কমা লাগলে (“জরিমানা হিসাব করে এবং SMS পাঠায়”) সম্ভবত sequential বা communicational; “প্রথমে… তারপর…” লাগলে procedural বা temporal; “সব রকম…” বা “নানা…” লাগলে logical বা coincidental; একটি পরিষ্কার ক্রিয়া-কর্মে বলা গেলে (“নম্বর থেকে grade বের করে”) functional. পর্ব ২৭-এর single responsibility principle এই চিন্তারই class-স্তরের রূপ।

এবার সবচেয়ে চেনা রোগটির চিকিৎসা: একটি utility class যেখানে ছয় মাসে আটটি অসম্পর্কিত function জমেছে। “পরে” চাপুন:

৫ · Connascence — নির্ভরতার আরও সূক্ষ্ম ভাষা

Coupling-এর স্তরগুলো structured design-এর যুগের, function আর global data-র কথা ভেবে বানানো। Object-oriented কোডের জন্য Meilir Page-Jones একটি আরও সূক্ষ্ম ভাষা দেন — connascence (১৯৯২-এর একটি প্রবন্ধে, পরে তাঁর OO design-এর বইগুলোতে; ২০০০-এর দশকের শেষে Jim Weirich-এর বক্তৃতায় এটি আবার জনপ্রিয় হয়)। সংজ্ঞা: দুটি অংশ connascent, যদি একটিকে বদলালে system সঠিক রাখতে অন্যটিকেও বদলাতে হয়। ধরনগুলোর প্রচলিত ভাগ (নাম আর তালিকা লেখকভেদে সামান্য আলাদা):

Page-Jones তিনটি মাত্রায় বিচার করতে বলেন: শক্তি (dynamic আর “meaning”-এর মতো ধরন বেশি শক্ত, ভাঙলে ধরা কঠিন), দূরত্ব (একই function-এর ভেতরে শক্ত connascence চলে, দুই service-এর মধ্যে নয়), আর মাত্রা (কতগুলো অংশ জড়িত)। ব্যবহারিক নিয়ম: শক্ত connascence-কে দুর্বলে নামান (magic number 2 → নামযুক্ত constant ON_LEAVE, অর্থাৎ meaning থেকে name), আর শক্ত যা থাকে তা কাছাকাছি রাখুন।

৬ · Coupling মাপা — Ca, Ce, instability, abstractness আর D

“কম coupling” কথাটি সংখ্যায় আনার একটি জনপ্রিয় পদ্ধতি Robert C. Martin-এর (১৯৯৪-এর একটি প্রবন্ধে প্রস্তাব, পরে Agile Software Development: Principles, Patterns, and Practices, ২০০২, আর Clean Architecture, ২০১৭ বইয়ে বিস্তারিত)। একটি package-এর জন্য:

• Ca (afferent, ভেতরে আসা) — বাইরের কতজন এই package-এর ওপর নির্ভর করে।
• Ce (efferent, বাইরে যাওয়া) — এই package কতজনের ওপর নির্ভর করে।
• Instability I = Ce / (Ca + Ce), ০ থেকে ১। ০ = সবাই আমার ওপর নির্ভর করে, আমি কারও ওপর নই — বদলানো কঠিন, তাই “stable”. ১ = আমি অন্যদের ওপর নির্ভর করি, কেউ আমার ওপর নয় — বদলানো সহজ।
• Abstractness A = Na / Nc — মোট class-এর মধ্যে abstract class বা interface কতগুলো।
• Distance D = |A + I − 1| — main sequence রেখা A + I = 1 থেকে দূরত্ব (Martin-এর normalized রূপ, ০ থেকে ১)।

Martin-এর মূল সংজ্ঞায় Ca আর Ce গোনা হয় class ধরে (বাইরের কতগুলো class এই package-এর class-এর ওপর নির্ভর করে)। এই পর্বের কোডে সরল রাখতে আমরা package গুনছি; tool-ভেদেও গোনার নিয়ম আলাদা হয়, তাই দুটি tool-এর সংখ্যা সরাসরি তুলনা করবেন না। এর পেছনে দুটি নীতি: Stable Dependencies Principle — নির্ভরতা কম stable থেকে বেশি stable-এর দিকে যাবে; আর Stable Abstractions Principle — যে package যত stable, তত abstract হওয়া উচিত, যাতে stable হয়েও বাড়ানো যায় (পর্ব ২৮-এর dependency inversion ঠিক এই কাজ করে)।

আমাদের কাল্পনিক স্কুল system-এর আটটি package-এর dependency graph:

এবার প্রতিটি package-এর পাঁচটি সংখ্যা হিসাব করে দেখি, কে main sequence থেকে দূরে:

// Package metrics (Robert C. Martin) for a fictional school system.
// deps = packages this one uses; classes = total; abstract = interfaces/abstract classes.
// Simplification: we count PACKAGES, not classes, when computing Ca and Ce.
const pkgs = {
  ui:         { deps: ["attendance", "exam", "fees"], classes: 6, abstract: 0 },
  attendance: { deps: ["model", "storage", "notify"], classes: 4, abstract: 0 },
  exam:       { deps: ["model", "storage"],           classes: 5, abstract: 1 },
  fees:       { deps: ["model", "storage", "notify"], classes: 4, abstract: 0 },
  notify:     { deps: ["model"],                      classes: 3, abstract: 1 },
  storage:    { deps: ["model"],                      classes: 4, abstract: 3 },
  model:      { deps: [],                             classes: 5, abstract: 0 },
  plugins:    { deps: ["model"],                      classes: 4, abstract: 4 },
};
const ca = {};                                   // afferent: who depends on me
for (const p in pkgs) ca[p] = 0;
for (const p in pkgs) for (const d of pkgs[p].deps) ca[d]++;
const f = x => x.toFixed(2);
console.log("package     Ca Ce    I     A     D   verdict");
for (const [p, v] of Object.entries(pkgs)) {
  const Ce = v.deps.length, Ca = ca[p];
  const I = Ca + Ce === 0 ? 0 : Ce / (Ca + Ce);  // instability
  const A = v.abstract / v.classes;              // abstractness
  const D = Math.abs(A + I - 1);                 // distance from main sequence
  let verdict = "ok";
  if (D >= 0.5) verdict = A + I < 1 ? "ZONE OF PAIN" : "ZONE OF USELESSNESS";
  console.log(p.padEnd(11), String(Ca).padStart(2), String(Ce).padStart(2),
    f(I).padStart(5), f(A).padStart(5), f(D).padStart(5), " " + verdict);
}

package     Ca Ce    I     A     D   verdict
ui           0  3  1.00  0.00  0.00  ok
attendance   1  3  0.75  0.00  0.25  ok
exam         1  2  0.67  0.20  0.13  ok
fees         1  3  0.75  0.00  0.25  ok
notify       2  1  0.33  0.33  0.33  ok
storage      3  1  0.25  0.75  0.00  ok
model        6  0  0.00  0.00  1.00  ZONE OF PAIN
plugins      0  1  1.00  1.00  1.00  ZONE OF USELESSNESS

সংখ্যাগুলো ছবিতে বসালে main sequence দেখা যায়:

একটি package-এর হিসাব হাতে করে দেখি — exam:

৭ · Cohesion মাপা — LCOM, fan-in আর fan-out

Class-এর cohesion মাপার সবচেয়ে পরিচিত পরিবার LCOM (Lack of Cohesion of Methods). নামেই আছে “lack” — তাই সংখ্যা যত বেশি, cohesion তত কম। সমস্যা হলো একই নামে কয়েকটি ভিন্ন সূত্র চলে:

• Chidamber ও Kemerer (১৯৯১-এ প্রস্তাব, ১৯৯৪-এ IEEE Transactions on Software Engineering-এ সংশোধিত রূপ): method-জোড়া গুনুন — P = যে জোড়া কোনো attribute ভাগ করে না, Q = যে জোড়া করে; LCOM = P − Q, ঋণাত্মক হলে ০। প্রায়ই একে LCOM1 বা LCOM2 বলা হয় — সংখ্যাক্রম লেখকভেদে আলাদা।
• Hitz ও Montazeri (১৯৯৫): method-গুলোকে node ধরুন; দুটি method যুক্ত, যদি তারা একটি attribute ভাগ করে বা একটি অন্যটিকে ডাকে। LCOM4 = এই graph-এর connected component-এর সংখ্যা। ১ মানে cohesive; ২ বা বেশি মানে class-টি ততগুলো স্বাধীন টুকরোয় ভাঙা যায়।
• Henderson-Sellers-এর LCOM* (১৯৯৬) সহ আরও কিছু রূপ আছে, যা ০ থেকে ১-এর মধ্যে মান দেয়।

আমরা LCOM4 নেব, কারণ এর অর্থ সবচেয়ে সরাসরি: “কয়টি আলাদা class লুকিয়ে আছে?” কোডে প্রতিটি method কোন attribute ছোঁয় আর কে কাকে ডাকে, তা একটি ঘোষিত map-এ লেখা; আসল tool এই map কোড বিশ্লেষণ করে বানায়।

# LCOM4 (Hitz & Montazeri): number of connected groups of methods, where two
# methods are linked if they use a common attribute or one calls the other.
# 1 = cohesive; 2 or more = the class could be split into that many parts.
def lcom4(cls):
    uses, calls = cls.USES, cls.CALLS          # read the declared maps
    parent = {m: m for m in uses}
    def root(m):
        while parent[m] != m:
            m = parent[m]
        return m
    ms = list(uses)
    links = [(a, b) for i, a in enumerate(ms) for b in ms[i + 1:]
             if uses[a] & uses[b]] + calls
    for a, b in links:
        parent[root(a)] = root(b)
    groups = {}
    for m in ms:
        groups.setdefault(root(m), []).append(m)
    return list(groups.values())
class SchoolOffice:     # before: method -> attributes it touches
    USES = {"add_student": {"students"}, "find_student": {"students"},
            "record_fee": {"ledger"}, "fee_due": {"ledger", "fee_rate"},
            "print_receipt": {"ledger"}, "send_sms": {"gateway"},
            "format_sms": {"template"}}
    CALLS = [("send_sms", "format_sms")]
def part(name, methods):  # after the split: a class with only these methods
    u = {m: SchoolOffice.USES[m] for m in methods}
    c = [p for p in SchoolOffice.CALLS if p[0] in u and p[1] in u]
    return type(name, (), {"USES": u, "CALLS": c})
after = [part("StudentRegistry", ["add_student", "find_student"]),
         part("FeeLedger", ["record_fee", "fee_due", "print_receipt"]),
         part("Notifier", ["send_sms", "format_sms"])]
for c in [SchoolOffice] + after:
    g = lcom4(c)
    print(f"{c.__name__}: LCOM4 = {len(g)}  " + " | ".join(", ".join(p) for p in g))

SchoolOffice: LCOM4 = 3  add_student, find_student | record_fee, fee_due, print_receipt | send_sms, format_sms
StudentRegistry: LCOM4 = 1  add_student, find_student
FeeLedger: LCOM4 = 1  record_fee, fee_due, print_receipt
Notifier: LCOM4 = 1  send_sms, format_sms

Fan-in আর fan-out

আরও পুরোনো আর সরল মাপ: fan-in = কতগুলো module এটিকে ডাকে, fan-out = এটি কতগুলোকে ডাকে। Package-স্তরে এরা প্রায় Ca আর Ce-র মতো, কিন্তু সাধারণত function বা module ধরে গোনা হয়। Sallie Henry ও Dennis Kafura (১৯৮১) এদের দিয়ে একটি “information flow” metric প্রস্তাব করেন, সাধারণত উদ্ধৃত রূপে: দৈর্ঘ্য × (fan-in × fan-out)²। ব্যবহারিক শিক্ষা: বেশি fan-in একটি ছোট, stable, cohesive function-এর জন্য ভালো খবর (অনেকে পুনর্ব্যবহার করছে) — কিন্তু “Utils”-এর মতো coincidental module-এর বেশি fan-in মানে একটি বদলে অনেকের ঝুঁকি। বেশি fan-out মানে module-টি অনেক কিছু জানে — প্রায়ই সে অনেক দায়িত্ব নিয়ে বসে আছে। জটিলতার আরেকটি মাপ, cyclomatic complexity, function-এর ভেতরের শাখা গোনে; সেটি আর অন্য code metric পর্ব ৫০-এ।

৮ · Dependency cycle, পরিবর্তনের ঢেউ আর microservice-এর সীমা

Dependency graph-এ সবচেয়ে ক্ষতিকর আকার হলো চক্র: fees নির্ভর করে student-এর ওপর, আর student নির্ভর করে fees-এর ওপর। তখন দুটিকে আলাদা করে বোঝা, build করা, test করা বা release করা যায় না — কার্যত তারা একটি বড় module. Martin-এর Acyclic Dependencies Principle বলে, package-এর graph একটি DAG হবে। পর্ব ১৯-এ (monorepo) দেখেছেন, “affected build” ঠিক এই graph ধরে চলে — চক্র থাকলে অনেক বেশি কিছু “affected” হয়।

চক্র খোঁজার প্রচলিত উপায় DFS (depth-first search), তিন রঙে: white = এখনো দেখা হয়নি, grey = এখন যে পথে আছি তার ওপর, black = শেষ। Grey কোনো node-এ আবার পৌঁছানো মানে একটি back edge, অর্থাৎ চক্র। DFS-এর মূল কৌশল DSA কোর্সের DFS পর্বে, আর চক্রহীন graph সাজানো topological sort পর্বে।

// Find dependency cycles with depth-first search (white / grey / black colours).
// Grey = "on the current DFS path"; reaching a grey node again closes a cycle.
const graph = {
  ui:       ["fees", "exam"],
  fees:     ["student", "notify"],
  notify:   ["student", "template"],
  student:  ["fees"],              // student -> fees closes a cycle
  exam:     ["student", "report"],
  report:   ["exam"],              // report -> exam closes another cycle
  template: [],
};
function findCycles(g) {
  const colour = {}, path = [], cycles = [];
  for (const n in g) colour[n] = "white";
  function visit(n) {
    colour[n] = "grey"; path.push(n);
    for (const m of g[n]) {
      if (colour[m] === "grey")                       // back edge
        cycles.push([...path.slice(path.indexOf(m)), m].join(" -> "));
      else if (colour[m] === "white") visit(m);
    }
    colour[n] = "black"; path.pop();
  }
  for (const n in g) if (colour[n] === "white") visit(n);
  return cycles;
}
console.log("Cycles found:");
for (const c of findCycles(graph)) console.log("  " + c);
// Fix: student no longer calls fees; report gets exam data passed in.
graph.student = [];
graph.report = [];
const left = findCycles(graph);
console.log("After fix: " + (left.length ? left.join(", ") : "no cycles (graph is a DAG)"));

Cycles found:
  fees -> student -> fees
  exam -> report -> exam
After fix: no cycles (graph is a DAG)

পরিবর্তনের ঢেউ গোনা

অংশ ১-এর সেই রোল নম্বরের সমস্যায় ফিরি। একটি পরিবর্তনের ফলে অন্যত্র পরপর পরিবর্তন করতে হলে তাকে ripple effect বলে — পুকুরে ঢিল ফেলার ঢেউ। একই সাতটি file, দুই রকম নকশা:

// Change ripple: one change, how many files must be EDITED and RE-TESTED?
// Change: the roll number moves from a plain number (15) to "2026-07-15".
// "uses" = what each file touches directly; "imports" = files it depends on.
function ripple(name, files, changed) {
  const edit = Object.keys(files).filter(f => files[f].uses.includes(changed));
  const retest = new Set(edit), queue = [...edit];
  while (queue.length) {                       // walk dependents backwards
    const x = queue.shift();
    for (const f in files)
      if (files[f].imports.includes(x) && !retest.has(f)) { retest.add(f); queue.push(f); }
  }
  console.log(name + ": edit " + edit.length + " " + JSON.stringify(edit) +
    ", re-test " + retest.size + " of " + Object.keys(files).length);
}
// High coupling: everyone reads the raw record field student.roll
const tight = {
  student:    { uses: ["student.roll"], imports: [] },
  attendance: { uses: ["student.roll"], imports: ["student"] },
  exam:       { uses: ["student.roll"], imports: ["student"] },
  fees:       { uses: ["student.roll"], imports: ["student"] },
  idcard:     { uses: ["student.roll"], imports: ["student"] },
  report:     { uses: ["student.roll"], imports: ["exam", "student"] },
  dashboard:  { uses: [], imports: ["report"] },
};
// Low coupling: only student.js knows the format; others call rollLabel(s)
const loose = {
  student:    { uses: ["student.roll"], imports: [] },
  attendance: { uses: ["rollLabel()"], imports: ["student"] },
  exam:       { uses: ["rollLabel()"], imports: ["student"] },
  fees:       { uses: ["rollLabel()"], imports: ["student"] },
  idcard:     { uses: ["rollLabel()"], imports: ["student"] },
  report:     { uses: ["rollLabel()"], imports: ["exam", "student"] },
  dashboard:  { uses: [], imports: ["report"] },
};
ripple("tight", tight, "student.roll"); ripple("loose", loose, "student.roll");

tight: edit 6 ["student","attendance","exam","fees","idcard","report"], re-test 7 of 7
loose: edit 1 ["student"], re-test 7 of 7

Low coupling আর high cohesion — ভারসাম্য

দুটি দিকে বাড়াবাড়ি সম্ভব। এক দিকে “big ball of mud” — সব কিছু সবকিছুকে চেনে। অন্য দিকে এত ছোট ছোট টুকরো আর এত interface যে একটি সরল কাজ বুঝতে দশটি file খুলতে হয়; প্রতিটি টুকরো “cohesive”, কিন্তু কাজটি নিজেই ছড়িয়ে গেছে — যা আসলে নিম্ন cohesion-এর আরেক রূপ। কয়েকটি ব্যবহারিক নিয়ম:

• যা একসাথে বদলায়, তা একসাথে রাখুন; যা আলাদা কারণে বদলায়, তা আলাদা করুন।
• Stable জিনিসের ওপর নির্ভরতা সস্তা, অস্থির জিনিসের ওপর দামি। তাই coupling-এর দিক সংখ্যার মতোই গুরুত্বপূর্ণ।
• Abstraction-এর একটি দাম আছে — প্রতিটি interface পড়তে, খুঁজতে আর রাখতে খরচ। দ্বিতীয় বাস্তব ব্যবহার না আসা পর্যন্ত অনেক দল নতুন interface বানায় না (পর্ব ২৬-এ YAGNI).

Microservice-এর সীমা — একই প্রশ্ন, বড় দামে

যখন module একটি আলাদা microservice হয়, coupling আর cohesion-এর প্রশ্ন বদলায় না, শুধু ভুলের দাম বাড়ে: function call হয়ে যায় network call, যা ধীর আর ব্যর্থ হতে পারে, আর একসাথে বদলানো মানে কয়েকটি দলের সমন্বিত deploy. System Design কোর্সের microservice পর্বে বিস্তারিত আছে; এখানে এই পর্বের ভাষায় মিল:

Melvin Conway-এর পর্যবেক্ষণ (Conway's law, ১৯৬৮) এখানে সরাসরি খাটে: দলের যোগাযোগের কাঠামো system-এর কাঠামোয় প্রতিফলিত হয়। ভুল জায়গায় service-এর সীমা টানলে দুই দলকে প্রতি সপ্তাহে একসাথে release করতে হয়। তাই অনেক অভিজ্ঞ লেখক পরামর্শ দেন: আগে একটি ভালোভাবে module-এ ভাগ করা monolith, তারপর সীমা পরিষ্কার হলে আলাদা service. বড় architecture-এর ধরন পর্ব ৩৮-এ।

৯ · AI-এর যুগে — AI-এর নকশা কতটা জড়ানো?

AI-কে “একটি স্কুল ম্যানেজমেন্ট system-এর কোড দাও” বললে কয়েক মিনিটে পূর্ণ project পাওয়া যায়। প্রায়ই তা চলে, কিন্তু নকশার দিক থেকে কয়েকটি চেনা সমস্যা থাকে:

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

• প্রতিটি module-এর কাজ এক বাক্যে বলতে পারি; “Utils”, “Helper”, “Manager” নামের প্রতিটি file আলাদাভাবে বিচার করেছি
• Dependency graph নিজে বের করে দেখেছি — কোনো চক্র নেই, আর তীর stable জিনিসের দিকে
• AI-এর হিসাব করা Ca, Ce, I বা LCOM অন্তত একটি file-এ হাতে মিলিয়েছি
• প্রতিটি নতুন interface-এর অন্তত একটি বাস্তব কারণ আছে, শুধু “ভবিষ্যতে লাগতে পারে” নয়
• Refactoring একটি আলাদা branch-এ, ছোট commit-এ, প্রতিটির পরে test চালিয়ে করেছি আর diff পড়েছি
• AI-কে পাঠানো কোড থেকে secret আর ব্যক্তিগত তথ্য সরিয়েছি; সুপারিশ করা কোডের licence দেখেছি