নকশার নীতি — DRY, KISS, YAGNI, separation of concerns আর Law of Demeter

১ · নকশার নীতি কেন — নিয়মের তালিকা নয়, বদলের খরচ কমানোর অভ্যাস

আগের পর্বে (পর্ব ২৫, modularity, coupling আর cohesion) নকশা মাপার দুটি মাপকাঠি দেখেছেন: coupling — দুটি অংশ একে অপরের ওপর কতটা নির্ভর করে, আর cohesion — একটি অংশের ভেতরের জিনিসগুলো কতটা একই কাজে লাগে। কিন্তু মাপকাঠি জানলেই হাত চলে না। কোড লেখার মুহূর্তে আপনার দরকার ছোট, মনে রাখার মতো কিছু পরামর্শ: “এই নিয়মটা কি আগেও কোথাও লিখেছি?”, “এটা কি এখনই দরকার?”, “এই function কি অন্য object-এর ভেতরে বেশি ঢুকে পড়ছে?” এই পরামর্শগুলোই নকশার নীতি (design principle).

নিচের মানচিত্রটি পুরো পর্বের সারাংশ। প্রতিটি নীতি আলাদা পথে একই লক্ষ্যে যায় — কম coupling আর বেশি cohesion, যার ফল হলো maintainability (পর্ব ০৩, software quality). লাল ড্যাশ রেখাগুলো টানাপোড়েন: একটি নীতি অতিরিক্ত টানলে অন্য দিক ক্ষতিগ্রস্ত হয়। §৮-এ এগুলো নিয়ে বিস্তারিত।

মনে রাখুন, এই নীতিগুলো উপপাদ্য নয়; কয়েক দশকের অভিজ্ঞতা থেকে আসা heuristic. এগুলো SOLID-এরও ভিত্তি — SOLID আসবে পর্ব ২৭ (single responsibility আর open-closed) ও পর্ব ২৮-এ (Liskov, interface segregation আর dependency inversion); এখানে শুধু নাম ধরে আসবে।

পুরো পর্ব জুড়ে একটি উদাহরণ চলবে: একটি মিষ্টির দোকানের অনলাইন অর্ডার app (কাল্পনিক). গ্রাহক অর্ডার দেন, cart-এ ছাড় হিসাব হয়, invoice তৈরি হয়, SMS-এ রসিদ যায়, আর গ্রাহকের app-এর ভেতরের wallet থেকে টাকা কাটে।

২ · DRY — একটি জ্ঞান, একটি জায়গা

১৯৯৯ সালে Andrew Hunt আর David Thomas তাঁদের বই The Pragmatic Programmer-এ নীতিটির নাম দেন DRY — Don't Repeat Yourself. তাঁদের সংজ্ঞাটি হুবহু মনে রাখার মতো:

লক্ষ্য করুন, বাক্যে “code” শব্দটি নেই — আছে knowledge, জ্ঞান। জ্ঞান মানে একটি ব্যবসায়িক নিয়ম (“৮০০ টাকার বেশি অর্ডারে ১২% ছাড়”), একটি তথ্যের গঠন (অর্ডারে কোন কোন field), একটি algorithm, এমনকি একটি configuration মান। এই জ্ঞানের একটি single source of truth থাকবে; বাকি সব জায়গা সেখান থেকে নেবে। বইটির ২০১৯ সালের ২০তম বার্ষিকী সংস্করণে লেখকেরা নিজেরাই জোর দিয়ে বলেছেন যে অনেকে DRY-কে ভুলভাবে “কোডের লাইন কপি করা নিষেধ” বুঝেছেন; তাঁদের উদ্দেশ্য ছিল জ্ঞান আর উদ্দেশ্যের পুনরাবৃত্তি বন্ধ করা।

Duplication শুধু কোডে থাকে না: একই জ্ঞান থাকতে পারে কোড আর comment-এ (comment বলছে ১০%, কোড করছে ১২%), কোড আর database schema-য়, বা দুটি দলের আলাদা service-এ। যেখানেই দুটি কর্তৃত্বপূর্ণ রূপ, সেখানেই একদিন দুটি আলাদা হয়ে যাবে।

একটি নিয়ম, তিনটি কপি — কী ঘটে

মিষ্টির দোকানে পুরোনো নিয়ম ছিল: ১০০০ টাকা বা তার বেশি অর্ডারে ১০% ছাড়। ঈদের আগে মালিক বললেন, এবার ৮০০ টাকা বা বেশিতে ১২% ছাড়। নিয়মটি কোডে তিন জায়গায় লেখা ছিল — cart, invoice আর SMS রসিদ। Developer দুটি ঠিক করলেন, তৃতীয়টি ভুলে গেলেন।

// DRY: one business rule (the discount) copied into three places.
// Fictional sweet shop. Old rule: 1000 tk or more -> 10% off.
// New Eid rule: 800 tk or more -> 12% off. The developer updated the cart
// and the invoice, but forgot the copy inside the SMS receipt.
function cartTotal(amount) {                 // updated
  return amount >= 800 ? Math.round(amount * 0.88) : amount;
}
function invoiceTotal(amount) {              // updated (written differently)
  const discount = amount >= 800 ? amount * 0.12 : 0;
  return Math.round(amount - discount);
}
function smsReceiptTotal(amount) {           // forgotten: still the old rule
  if (amount >= 1000) return Math.round(amount * 0.9);
  return amount;
}
console.log("--- rule copied in 3 places ---");
for (const a of [700, 900, 1200]) {
  console.log(a + " tk: cart " + cartTotal(a) + ", invoice " + invoiceTotal(a) +
              ", sms " + smsReceiptTotal(a));
}
// Single source of truth: the knowledge lives in ONE place.
const DISCOUNT_RULE = { minAmount: 800, rate: 0.12 };   // change it here only
function discountedTotal(amount, rule = DISCOUNT_RULE) {
  return amount >= rule.minAmount ? Math.round(amount * (1 - rule.rate)) : amount;
}
const places = { cart: discountedTotal, invoice: discountedTotal, sms: discountedTotal };
console.log("--- single source ---");
for (const a of [700, 900, 1200]) {
  const out = Object.entries(places).map(([name, f]) => name + " " + f(a));
  console.log(a + " tk: " + out.join(", "));
}

--- rule copied in 3 places ---
700 tk: cart 700, invoice 700, sms 700
900 tk: cart 792, invoice 792, sms 900
1200 tk: cart 1056, invoice 1056, sms 1080
--- single source ---
700 tk: cart 700, invoice 700, sms 700
900 tk: cart 792, invoice 792, sms 792
1200 tk: cart 1056, invoice 1056, sms 1056

আসল duplication বনাম কাকতালীয় duplication

DRY-এর সবচেয়ে বড় ভুল প্রয়োগ হলো দেখতে একই রকম সব কোড জোড়া লাগানো। দুটি প্রশ্ন জিজ্ঞেস করুন:

1. দুটি কি একই কারণে, একই মানুষের সিদ্ধান্তে বদলায়? হ্যাঁ হলে একই জ্ঞান — এক উৎসে আনুন।
2. একটি বদলালে অন্যটিও কি অবশ্যই বদলাতে হবে? না হলে এটি incidental duplication — আজ মিলে গেছে, কাল আলাদা হবে।

মিষ্টির দোকানে delivery-র নিয়মও ৮০০: “৮০০ টাকার বেশি অর্ডারে delivery ফ্রি।” সংখ্যাটি ছাড়ের সাথে মিলে গেছে, কিন্তু এটি delivery ব্যবস্থাপকের সিদ্ধান্ত, ছাড়টি মার্কেটিংয়ের। কেউ যদি দুটিকে একটি THRESHOLD = 800-এ জুড়ে দেন, তাহলে পরের মাসে মার্কেটিং ছাড়ের সীমা ৫০০ করলে delivery-ও হঠাৎ ৫০০ টাকায় ফ্রি হয়ে যাবে — কেউ চাননি। এটি শুধু কাকতালীয় মিলের ভিত্তিতে জোড়া — পর্ব ২৫-এর coincidental cohesion-এর আত্মীয় — আর ফল অপ্রয়োজনীয় coupling. নিচের stepper-এ পুরো কাজটি ধাপে ধাপে দেখুন।

৩ · কখন কপি ভালো — rule of three, WET আর AHA

যদি দুটি কোড একই জ্ঞান কি না নিশ্চিত না হন? অভিজ্ঞ developer-রা তখন একটু অপেক্ষা করার পরামর্শ দেন। এর পেছনে তিনটি প্রচলিত ধারণা আছে।

এই ধারার সবচেয়ে বেশি উদ্ধৃত বাক্যটি Sandi Metz-এর — ২০১৪ সালের একটি বক্তৃতায় আর ২০১৬ সালের “The Wrong Abstraction” লেখায় তিনি বলেন, duplication ভুল abstraction-এর চেয়ে অনেক সস্তা (“duplication is far cheaper than the wrong abstraction”). কারণটি সহজ: দুটি কপি থাকলে প্রতিটি নিজের মতো বদলাতে পারে, ক্ষতি সীমিত। কিন্তু ভুল abstraction একবার দশটি জায়গায় ছড়িয়ে পড়লে সবাই সেটিকে মানিয়ে নিতে parameter আর flag যোগ করেন, আর সেটি ভাঙতে সাহস লাগে — কারণ “কেউ নিশ্চয়ই কোনো কারণে বানিয়েছিলেন”।

৪ · KISS আর YAGNI — সরল রাখা, আগাম না বানানো

KISS — সবচেয়ে সরল যা কাজ করে

KISS সাধারণত “Keep It Simple, Stupid” হিসেবে পরিচিত (কেউ কেউ ভদ্রভাবে বলেন “Keep It Short and Simple”). নীতিটি প্রায়ই মার্কিন বিমান প্রকৌশলী Kelly Johnson-এর নামে উদ্ধৃত হয়, যিনি Lockheed-এর Skunk Works নামের নকশা দলের প্রধান ছিলেন। প্রচলিত গল্প অনুযায়ী, তিনি চাইতেন যুদ্ধক্ষেত্রে একজন সাধারণ mechanic সাধারণ যন্ত্রপাতি দিয়েই বিমান সারাতে পারবেন — সেই মাপে নকশা সরল রাখতে হবে। গল্পের খুঁটিনাটি উৎসভেদে আলাদা, কিন্তু শিক্ষাটি স্পষ্ট: সরলতা সৌন্দর্য নয়, চাপের মধ্যে মেরামতযোগ্যতা.

Software-এ সরল মানে কম অংশ, কম সংযোগ, কম বিশেষ নিয়ম, আর এমন কোড যা রাত দুইটায় production ভাঙলে একজন ক্লান্ত developer-ও বুঝতে পারেন। পর্ব ০২-এ Brooks-এর ভাষায় দেখেছেন, সমস্যার নিজের জটিলতা (essential complexity) কমানো যায় না, কিন্তু আমাদের বানানো বাড়তি জটিলতা (accidental complexity) কমানো যায়। KISS দ্বিতীয়টির বিরুদ্ধে। সরল আর সহজ যে এক জিনিস নয়, তা ভাবনার প্রশ্ন ৫-এ দেখবেন।

YAGNI — আপনার এটা লাগবে না

YAGNI — “You Aren't Gonna Need It” — এসেছে ১৯৯০-এর দশকের শেষের Extreme Programming (XP) থেকে (পর্ব ০৫-এ XP-র কথা দেখেছেন)। XP-র সহ-প্রতিষ্ঠাতা Ron Jeffries-এর নামে প্রচলিত পরামর্শটি হলো: কোনো জিনিস তখনই বানান যখন সত্যিই দরকার, শুধু “দরকার হতে পারে” ভেবে কখনো নয়। এটি অলসতার পরামর্শ নয়; এটি একটি অর্থনৈতিক যুক্তি। Martin Fowler ২০১৫ সালের একটি লেখায় আগাম (presumptive) feature-এর খরচ চার ভাগে ভাগ করেছেন:

• বানানোর খরচ: যে সময় দরকারি কাজ থেকে সরে গেল।
• দেরির খরচ: দরকারি কাজটি, আর তার মূল্য, দেরিতে পৌঁছাল।
• বহনের খরচ (cost of carry): feature-টি কোডে বসে থাকে; প্রতিটি নতুন বদলে এটিকে বুঝতে, test করতে, মানিয়ে নিতে হয়।
• মেরামতের খরচ: দরকার হলেও আগাম অনুমান প্রায়ই ভুল — তখন নতুন করে বানাতে হয়।

যা আসলে কখনো লাগেনি, সেই কোডের বহনের খরচ যে কত ভয়ংকর হতে পারে, তা পর্ব ০২-এর দুটি ঘটনায় দেখেছেন: Ariane 5-এ Ariane 4 থেকে আনা একটি হিসাব, যা উড্ডয়নের পরে আর দরকার ছিল না, তবু চলছিল; আর Knight Capital-এ বহু বছর পুরোনো অব্যবহৃত কোড একটি পুনর্ব্যবহৃত flag-এ জেগে উঠেছিল (পর্ব ১৭-এও আলোচিত)। প্রতিদিনের project-এ খরচ এত নাটকীয় নয়, কিন্তু নিয়মিত। নিচের প্রোগ্রামটি একটি সরল cost model — অনুমানগুলো প্রথম লাইনগুলোতেই লেখা, আর সংখ্যাগুলো কাল্পনিক।

// YAGNI cost model (fictional numbers, developer-days, 12-month horizon).
// Assumptions: building the feature now costs 10 days; while it sits in the
// code it costs 0.3 day per month (tests, reviews, slower changes). If it is
// really needed, the month of need is uniform 1..12, and an early guess is
// wrong 40% of the time (6 days of rework). Building later costs LATE days,
// plus carrying cost only from the month of need to month 12.
function mulberry32(a) { return function () {
  a |= 0; a = a + 0x6D2B79F5 | 0; let t = Math.imul(a ^ a >>> 15, 1 | a);
  t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t; return ((t ^ t >>> 14) >>> 0) / 4294967296; }; }
const BUILD = 10, CARRY = 0.3, MONTHS = 12, WRONG = 0.4, REWORK = 6, TRIALS = 20000;
function simulate(p, late, rand) {
  let now = 0, later = 0;
  for (let i = 0; i < TRIALS; i++) {
    const needed = rand() < p;
    const month = 1 + Math.floor(rand() * MONTHS);      // month of need
    const wrong = rand() < WRONG;                        // early guess wrong?
    now += BUILD + CARRY * MONTHS + (needed && wrong ? REWORK : 0);
    if (needed) later += late + CARRY * (MONTHS - month);
  }
  return [now / TRIALS, later / TRIALS];
}
for (const late of [12, 25]) {
  const rand = mulberry32(2026);
  console.log("late build cost = " + late + " days");
  for (const p of [0.1, 0.3, 0.5, 0.7, 0.9]) {
    const [now, later] = simulate(p, late, rand);
    console.log("  p=" + p.toFixed(1) + "  build now " + now.toFixed(2) + "  wait " +
                later.toFixed(2) + "  -> " + (now < later ? "build now" : "wait"));
  }
  const be = (BUILD + CARRY * MONTHS) / (late + CARRY * (MONTHS - 1) / 2 - WRONG * REWORK);
  console.log("  break-even p = " + be.toFixed(2) + (be > 1 ? " (> 1: waiting always wins)" : ""));
}

late build cost = 12 days
  p=0.1  build now 13.84  wait 1.38  -> wait
  p=0.3  build now 14.32  wait 4.11  -> wait
  p=0.5  build now 14.80  wait 6.86  -> wait
  p=0.7  build now 15.27  wait 9.56  -> wait
  p=0.9  build now 15.74  wait 12.21  -> wait
  break-even p = 1.21 (> 1: waiting always wins)
late build cost = 25 days
  p=0.1  build now 13.84  wait 2.68  -> wait
  p=0.3  build now 14.32  wait 8.02  -> wait
  p=0.5  build now 14.80  wait 13.40  -> wait
  p=0.7  build now 15.27  wait 18.66  -> build now
  p=0.9  build now 15.74  wait 23.84  -> build now
  break-even p = 0.56

শেষ কথাটিই YAGNI-র সবচেয়ে ভুল-বোঝা অংশ। YAGNI feature-এর বিরুদ্ধে, নকশার মানের বিরুদ্ধে নয়। Refactoring, test আর পরিষ্কার নাম কোনো ভবিষ্যৎ feature নয় — এগুলোই পরে বানানোকে সস্তা রাখে। নিচের stepper-এ একটি আসল সিদ্ধান্ত দেখুন।

৫ · Separation of concerns আর “যা বদলায়, তাকে আলাদা রাখুন”

Separation of concerns (SoC) কথাটি Edsger W. Dijkstra-র ১৯৭৪ সালের একটি লেখা “On the role of scientific thought”-এ (তাঁর হাতে লেখা নোটের ধারায় EWD 447) দেখা যায় বলে সাধারণত উল্লেখ করা হয়। তাঁর বক্তব্য ছিল চিন্তার কৌশল নিয়ে: একটি সমস্যার একটি দিক নিয়ে মনোযোগ দিয়ে ভাবুন — ধরা যাক প্রোগ্রামটি ঠিক কি না — আর সেই সময় অন্য দিক (দ্রুত কি না, সুন্দর কি না) সচেতনভাবে সরিয়ে রাখুন। পরে software-এ এটি নকশার নীতি হয়ে দাঁড়ায়: আলাদা concern (দায়, বিবেচ্য বিষয়) আলাদা অংশে রাখুন।

মিষ্টির দোকানের app-এ concern-গুলো হলো দাম ও ছাড়ের নিয়ম, data সংরক্ষণ, UI, SMS পাঠানো আর লগ। একটি function যদি একসাথে ছাড় হিসাব করে, database-এ লেখে, HTML বানায় আর SMS পাঠায়, তবে SMS সরবরাহকারী বদলালে ছাড়ের কোডও ঝুঁকিতে পড়ে। পরিচিত উদাহরণ: web page-এ HTML (গঠন), CSS (চেহারা) আর JavaScript (আচরণ) আলাদা; বড় আকারে layered architecture (পর্ব ৩৮) আর MVC (পর্ব ৩৯).

SoC-এর ঘনিষ্ঠ আত্মীয় David Parnas-এর ১৯৭২ সালের information hiding: প্রতিটি module এমন একটি নকশা-সিদ্ধান্ত লুকিয়ে রাখবে, যা বদলাতে পারে (পর্ব ২৫-এ বিস্তারিত)। এখান থেকেই আসে একটি বহুল ব্যবহৃত পরামর্শ — encapsulate what varies: নকশার যে অংশ বদলাবে বলে মনে হয়, সেটিকে একটি স্থির interface-এর পেছনে আলাদা করুন। ১৯৯৪ সালের Gang of Four-এর বই (Design Patterns, Gamma, Helm, Johnson ও Vlissides) প্রায় এই ভাষাতেই বলে — নকশায় কী বদলাতে পারে ভাবুন, আর সেই বদলানো ধারণাটিকে encapsulate করুন। মিষ্টির দোকানে ছাড়ের নিয়ম বারবার বদলায় (ঈদ, পয়লা বৈশাখ, পূজা) — তাই §২-এ সেটিকে pricing.js-এ আলাদা করা শুধু DRY নয়, encapsulate what varies-ও।

একই বইয়ের আরেকটি বিখ্যাত পরামর্শ: “Favor object composition over class inheritance” — composition over inheritance. Inheritance child class-কে parent-এর ভেতরের খুঁটিনাটির সাথে বাঁধে — সবচেয়ে শক্ত coupling-গুলোর একটি। Composition-এ একটি object অন্য object-কে নিজের অংশ হিসেবে রেখে তার interface দিয়ে কাজ করায়, তাই অংশটি বদলানো যায়। যেমন EidOrder extends Order, BoishakhOrder extends Order-এর বদলে Order-এর ভেতরে একটি বদলযোগ্য ছাড়ের নিয়ম। কীভাবে আর কখন inheritance-ই ঠিক — পর্ব ৩৭-এ; UML-এ এই সম্পর্কগুলোর চিহ্ন পর্ব ২৯-এ (UML class diagram).

৬ · Law of Demeter — শুধু কাছের বন্ধুর সাথে কথা

Law of Demeter এসেছে যুক্তরাষ্ট্রের Northeastern University-র Demeter নামের একটি গবেষণা project থেকে, ১৯৮৭ সালের দিকে। নীতিটি সাধারণত Ian Holland-এর প্রস্তাব বলে উল্লেখ করা হয়, আর Karl Lieberherr ও Holland ১৯৮৮–৮৯ সালের কয়েকটি লেখায় (OOPSLA ১৯৮৮-এ Riel-সহ, আর IEEE Software ১৯৮৯) এটি প্রকাশ করেন। এর আরেক নাম principle of least knowledge. ছোট করে: “শুধু আপনার কাছের বন্ধুদের সাথে কথা বলুন” (talk only to your immediate friends).

Object-oriented ভাষায় নিয়মটি হলো: একটি method m শুধু এদের method ডাকতে পারে —

1. নিজের object (this/self);
2. m-এর parameter হিসেবে আসা object;
3. m-এর ভেতরে তৈরি করা object;
4. নিজের সরাসরি অংশ (field) হিসেবে রাখা object.

যা নিষেধ: বন্ধুর কাছ থেকে পাওয়া object-এর ভেতরে আবার ঢোকা — “বন্ধুর বন্ধু”। order.customer.wallet.balance -= x লাইনটি checkout কোডকে চারটি জিনিস জানতে বাধ্য করে: order-এ customer আছে, customer-এ wallet আছে, wallet-এ balance নামে একটি সংখ্যা আছে, আর সেটি সরাসরি বদলানো যায়। এমন লম্বা শিকলকে বলা হয় train wreck — রেলের বগির মতো একটির পর একটি বিন্দু, আর একটি বগি লাইনচ্যুত হলে পুরো ট্রেন।

নিচের প্রোগ্রামে Wallet-এর দুটি version: প্রথমটি টাকা রাখে balance field-এ, দ্বিতীয়টি (ভালো কারণে — দশমিকের গোলমাল এড়াতে) পয়সায় পূর্ণসংখ্যা রাখে, field-এর নাম paisa. দুই রকম checkout কোড একই কাজ করার চেষ্টা করে।

// Law of Demeter: reaching through objects vs. telling the object.
class Wallet {                        // version 1: keeps taka in "balance"
  constructor(tk) { this.balance = tk; }
  debit(tk) { if (tk > this.balance) throw new Error("insufficient balance");
              this.balance -= tk; }
  get taka() { return this.balance; }
}
class WalletV2 {                      // version 2: integer paisa, field renamed
  constructor(tk) { this.paisa = tk * 100; }
  debit(tk) { const p = Math.round(tk * 100);
              if (p > this.paisa) throw new Error("insufficient balance");
              this.paisa -= p; }
  get taka() { return this.paisa / 100; }
}
class Customer {
  constructor(name, wallet) { this.name = name; this.wallet = wallet; }
  pay(tk) { this.wallet.debit(tk); }  // the customer talks to its own wallet
}
// Caller A: a "train wreck" -- it knows Order -> Customer -> Wallet -> balance
function checkoutChain(order) { order.customer.wallet.balance -= order.total; }
// Caller B: tell, don't ask -- it only knows that a customer can pay
function checkoutTell(order) { order.customer.pay(order.total); }

for (const W of [Wallet, WalletV2]) {
  const a = { total: 350, customer: new Customer("Rina", new W(1000)) };
  const b = { total: 350, customer: new Customer("Rina", new W(1000)) };
  checkoutChain(a); checkoutTell(b);
  console.log(W.name + ": chain -> " + a.customer.wallet.taka + " tk, tell -> " +
              b.customer.wallet.taka + " tk");
}
const big = { total: 1500, customer: new Customer("Rina", new Wallet(1000)) };
checkoutChain(big);
console.log("chain, 1500 tk order: wallet = " + big.customer.wallet.taka + " tk");
try { checkoutTell({ total: 1500, customer: new Customer("Rina", new Wallet(1000)) }); }
catch (e) { console.log("tell, 1500 tk order: " + e.message); }

Wallet: chain -> 650 tk, tell -> 650 tk
WalletV2: chain -> 1000 tk, tell -> 650 tk
chain, 1500 tk order: wallet = -500 tk
tell, 1500 tk order: insufficient balance

Tell, don't ask

Law of Demeter-এর হাতে-কলমে রূপ হলো tell, don't ask — object-কে প্রশ্ন করে তার data বের করে বাইরে সিদ্ধান্ত নেবেন না; object-কে বলুন কী করতে হবে, সিদ্ধান্ত সে নিক। ধারণাটি Andy Hunt ও Dave Thomas-এর একটি পত্রিকা-কলামের মাধ্যমে (IEEE Software, ২০০৩ সালের দিকে) আর পরে Martin Fowler-এর লেখায় পরিচিত হয়। এতে data আর তার নিয়ম একসাথে থাকে — cohesion বাড়ে, coupling কমে। নিচের stepper-এ একটি train wreck ধাপে ধাপে refactor হচ্ছে।

if (order.customer.wallet.balance >= order.total) {
  order.customer.wallet.balance -= order.total;
  order.customer.wallet.history.push(order.id);
} else {
  showError("টাকা কম");
}

class Wallet {
  debit(tk, ref) {               // নিয়ম এখন নিজের ঘরে
    if (tk > this.balance) throw new Error("insufficient");
    this.balance -= tk;
    this.history.push(ref);
  }
}

try {
  order.customer.wallet.debit(order.total, order.id);
} catch (e) {
  showError("টাকা কম");
}

class Customer {
  pay(tk, ref) { this.wallet.debit(tk, ref); }
}
// checkout.js
order.customer.pay(order.total, order.id);

class Order {
  checkout() { this.customer.pay(this.total, this.id); }
}
// checkout.js
order.checkout();

কখন শিকল ঠিক আছে — fluent API, builder আর stream

Law of Demeter-কে “এক লাইনে একটির বেশি বিন্দু নয়” হিসেবে গুনলে ভুল হবে। প্রশ্নটি বিন্দু গোনার নয়, আপনি কি অন্য object-এর ভেতরের গঠনের ওপর নির্ভর করছেন? নিচের শিকলগুলো সাধারণত ঠিক আছে:

• Fluent interface আর builder: new OrderBuilder().item("rasgulla", 2).address("Mirpur").build() — প্রতিটি method একই builder ফেরত দেয়; আপনি একটিই বন্ধুর সাথে কথা বলছেন, কারও ভেতরে ঢুকছেন না। Builder pattern আসবে পর্ব ৩৩-এ।
• Stream আর collection pipeline: orders.filter(o => o.paid).map(o => o.total).reduce(sum) — প্রতিটি ধাপ একটি নতুন মান ফেরত দেয়, ভেতরের গঠন নয়। JavaScript-এর array method আর Java-র stream এই ধরনের।
• সরল data structure: JSON config বা DTO-র মতো যে জিনিসের কাজই data ধরে রাখা, তার field পড়া (config.db.host) সাধারণত সমস্যা নয়; Robert C. Martin-এর Clean Code (২০০৮) এই পার্থক্য করে — Law of Demeter object-এর জন্য, নিছক data structure-এর জন্য নয়।

৭ · Least astonishment, fail fast আর command–query separation

Principle of least astonishment — কেউ যেন অবাক না হন

Principle of least astonishment (POLA, বা least surprise) বলে: একটি function, API বা screen এমনভাবে আচরণ করবে, যা তার ব্যবহারকারী তার নাম, প্রসঙ্গ আর প্রচলিত রীতি দেখে আশা করেন। ধারণাটি অন্তত ১৯৭০-এর দশক থেকে programming language আর interface নকশার আলোচনায় দেখা যায়; প্রথম উৎস নিয়ে নিশ্চিত দাবি করা কঠিন। উদাহরণ: getTotal() নামের function-এর database-এ কিছু লেখা উচিত নয়; sort() যদি মূল list বদলায়, নামেই তা বোঝা উচিত; একটি “বাতিল” button কখনো অর্ডার নিশ্চিত করবে না। যে আচরণে অবাক হতে হয়, সেখানেই bug জন্মায় — কারণ পরের developer যা ভেবেছেন, কোড তা করে না।

Fail fast — ভুল যত আগে, তত সস্তা

Fail fast মানে ভুল অবস্থা দেখামাত্র স্পষ্টভাবে থেমে যাওয়া বা জানানো, চুপচাপ ভুল মান নিয়ে এগিয়ে যাওয়া নয়। Jim Shore-এর ২০০৪ সালের IEEE Software-এর একটি লেখা (“Fail Fast”) এই ধারণাকে জনপ্রিয় করে। উদাহরণ: অর্ডারের পরিমাণ ঋণাত্মক হলে function-এর শুরুতেই exception তোলা; program শুরুর সময়ে config-এ SMS-এর চাবি না থাকলে তখনই থেমে যাওয়া, প্রথম গ্রাহকের অর্ডারে গিয়ে নয়। §৬-এর প্রোগ্রামে NaN চুপচাপ একটি field-এ বসে গেছিল — এটি fail fast-এর ঠিক উল্টো, “fail silently”. মনে রাখুন, fail fast ডেভেলপারের জন্য; ব্যবহারকারীর সামনে আপনি সুন্দর বার্তা দেখাবেন, কিন্তু ভেতরে ভুলটি গোপন করবেন না। Contract আর error handling-এর বিস্তারিত নকশা পর্ব ৩১-এ (interface আর contract).

Command–query separation — প্রশ্ন করলে উত্তর বদলায় না

Bertrand Meyer তাঁর Object-Oriented Software Construction (১৯৮৮) বইয়ে command–query separation (CQS) প্রস্তাব করেন: প্রতিটি method হয় একটি command (অবস্থা বদলায়, কিছু ফেরত দেয় না), নয়তো একটি query (উত্তর দেয়, কোনো side effect নেই) — দুটি একসাথে নয়। প্রচলিত ভাষায়: “প্রশ্ন করলে উত্তর বদলানো উচিত নয়।” কেন জরুরি, তা দেখুন — একটি loyalty card-এর “getter” গোপনে মাসিক fee কাটে।

# Command-query separation (Meyer): a query answers, a command changes state.
# Fictional sweet-shop loyalty card. get_points() looks like a query...
class LoyaltyCardBad:
    def __init__(self, points):
        self.points = points

    def get_points(self):            # ...but it also charges a 10-point fee
        self.points -= 10
        return self.points

card = LoyaltyCardBad(100)
print("log:", card.get_points())     # a harmless-looking log line
if card.get_points() >= 85:
    print("free sweet")
else:
    print("no free sweet, points =", card.get_points())

# Fixed: the query has no side effect; the change is an explicit command.
class LoyaltyCard:
    def __init__(self, points):
        self._points = points

    def points(self):                # query: safe to call any number of times
        return self._points

    def charge_monthly_fee(self):    # command: changes state, returns nothing
        self._points -= 10

card = LoyaltyCard(100)
card.charge_monthly_fee()            # done once, on purpose
print("log:", card.points())
print("free sweet" if card.points() >= 85 else "no free sweet")
print("points after all checks:", card.points())

log: 90
no free sweet, points = 70
log: 90
free sweet
points after all checks: 90

CQS-এর কিছু স্বীকৃত ব্যতিক্রম আছে: stack-এর pop() (উপাদান সরায় আর ফেরত দেয়), iterator-এর next(), বা একাধিক thread-এর জন্য পড়া আর বাড়ানো একসাথে করা atomic কাজ — এরা ভালো কারণে নিয়ম ভাঙে, আর নামেই তা বোঝা যায়। একই ধারণা system-এর মাপে বড় হলে CQRS (command query responsibility segregation) — লেখা আর পড়ার জন্য আলাদা model; তার আলোচনা System Design কোর্সের event sourcing আর CQRS পর্বে।

৮ · নীতি যখন একে অপরের বিরুদ্ধে — আর over-engineering

প্রতিটি নীতি একা ভালো; একসাথে টানাটানি করে। এটাই নকশার আসল কাজ — নীতি মুখস্থ করা নয়, টানাপোড়েনে যুক্তি দিয়ে সিদ্ধান্ত নেওয়া।

Over-engineering — নীতির অতিরিক্ত প্রয়োগ

নীতির উল্টো দিকের রোগ হলো over-engineering: সমস্যার চেয়ে বড় সমাধান। কয়েকটি পরিচিত চেহারা চিনে রাখুন:

• Speculative generality: “পরে লাগতে পারে” ভেবে বানানো abstract class, অব্যবহৃত parameter, একটিমাত্র implementation-ওয়ালা interface. Fowler ও Beck-এর code smell-এর তালিকায় এর নাম আছে (পর্ব ৪২).
• Premature abstraction: প্রথম উদাহরণেই generic framework — AHA-র ঠিক উল্টো।
• Pattern-জ্বর: সব জায়গায় design pattern বসানো, কারণ সদ্য শিখেছেন। Pattern সমস্যার সমাধান, সাজসজ্জা নয় — পর্ব ৩২-এ “কখন pattern নয়” আলোচনা আছে।
• Architecture astronaut: Joel Spolsky-র ২০০১ সালের একটি লেখার রসিক নাম — যাঁরা এত উঁচু স্তরের abstraction-এ ওঠেন যে আসল সমস্যা আর দেখা যায় না।

উল্টো রোগও আছে — under-engineering: হাজার লাইনের function আর সর্বত্র কপি-পেস্ট। মাঝের পথ: আজকের চাহিদা সবচেয়ে সরলভাবে মেটান, কিন্তু এমন পরিষ্কারভাবে যাতে কাল বদলানো সস্তা হয়; বদলের আসল প্রমাণ এলে তখন refactor করুন। Kent Beck-এর “simple design”-এর প্রচলিত চারটি নিয়মও এই কথা বলে: test পাস করে, উদ্দেশ্য প্রকাশ করে, duplication নেই, আর যত কম অংশ সম্ভব।

৯ · AI-এর যুগে নকশার নীতি

AI coding সহকারী নকশার নীতিগুলোর নাম খুব ভালো জানে, কিন্তু নাম জানা আর প্রসঙ্গ বুঝে প্রয়োগ করা আলাদা। আপনার ব্যবসার নিয়ম কে বদলান, কোন অংশ আগামী মাসে বদলাবে, কোন দুটি কোড কাকতালীয়ভাবে মিলেছে — AI তা জানে না।

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

• প্রতিটি “DRY” জোড়ার পেছনে একই ব্যবসায়িক কারণ আর একই সিদ্ধান্তদাতা খুঁজে পেয়েছি
• প্রতিটি নতুন abstraction-এর আজকের অন্তত দুটি ব্যবহার আছে; না থাকলে সরিয়েছি
• Refactoring-এর আগে আচরণ আটকানো test চালিয়েছি, পরে আবার চালিয়েছি; diff লাইন ধরে পড়েছি
• Query নামের method দুবার ডেকে দেখেছি যে উত্তর বদলায় না
• AI-এর দেওয়া কোড কোথা থেকে এলো, তার license নিয়ে প্রশ্ন থাকলে দলকে জানিয়েছি; prompt-এ কোনো secret বা গ্রাহকের তথ্য দিইনি