MVC, MVP আর MVVM — UI-র কোড সাজানো

১ · UI আর logic কেন আলাদা — একটি জট পাকানো screen

একটি কাল্পনিক বিশ্ববিদ্যালয়ের ফলাফল পোর্টালের কথা ভাবুন। প্রথম সংস্করণে একজন developer একটি button-এর click handler-এর ভেতরেই সব লিখলেন: text box থেকে roll নম্বর পড়া, সেটি ঠিক আছে কি না দেখা, server থেকে নম্বর আনা, GPA হিসাব করা, ২.০০-এর নিচে হলে “fail” লেখা, আর শেষে একটি HTML টেবিল বানিয়ে screen-এ বসানো। কাজ চলল। ছয় মাস পরে তিনটি অনুরোধ এলো: একটি mobile অ্যাপ, যেখানে একই ফলাফল দেখাবে; GPA-র নিয়মে একটি বদল; আর নিয়মটির automated test. তিনটি কাজই আটকে গেল একই কারণে — নিয়মটি button-এর handler-এর ভেতরে, HTML বানানোর লাইনের ফাঁকে ফাঁকে বসে আছে।

এই পর্বের সব নকশার মূল চিন্তা একটাই: separation of concerns (পর্ব ২৬) — UI-তে প্রয়োগ করা। User interface (UI) মানে ব্যবহারকারী যা দেখেন আর যা চাপেন। এর কোডে দুই ধরনের প্রশ্ন মিশে থাকে: “কী দেখাব আর কোথায়” (রং, টেবিল, button) আর “নিয়মটা কী” (GPA কীভাবে হিসাব হয়, কোন roll বৈধ)। প্রথমটি ঘন ঘন বদলায় — designer-এর ইচ্ছায়, নতুন device-এ। দ্বিতীয়টি বদলায় ব্যবসা বা নিয়মের সিদ্ধান্তে। দুটির বদলের কারণ আলাদা, তাই পর্ব ২৭-এর single responsibility principle-এর ভাষায় এদের আলাদা ঘরে থাকা উচিত।

আলাদা করার তিনটি লাভ

এই পর্বে চারটি নকশা দেখবেন — MVC, MVP, MVVM আর একমুখী data flow. চারটিই একই প্রশ্নের ভিন্ন উত্তর: screen আর নিয়মের মাঝে কে বসবে, কে কাকে চিনবে, আর বদলের খবর কোন দিকে যাবে। পুরো system-এর স্তর ভাগ (layered, client-server) পর্ব ৩৮-এর (Software architecture) বিষয়; এখানে আমরা শুধু UI-র অংশটুকুর ভেতরে ঢুকছি। এগুলোকে কখনো “architectural pattern” বলা হয়, কখনো “UI pattern” — নামের এই দ্বিধা নিজেই একটি শিক্ষা, যা অংশ ৩-এ দেখবেন।

২ · Classic MVC — Reenskaug, Smalltalk আর observer

MVC-এর তিনটি ভূমিকা:

• Model — data আর তার নিয়ম। বাজারের তালিকায় কোন জিনিস কত পরিমাণ, কোনটি কেনা হয়ে গেছে, খালি নাম গ্রহণযোগ্য কি না। Model কোনো view-কে চেনে না।
• View — model-এর একটি চেহারা। একই model-এর অনেক view হতে পারে: পুরো তালিকা, আর কোণে একটি ছোট badge “২টি বাকি”। View model থেকে পড়ে, কিন্তু model-এ লেখে না।
• Controller — ব্যবহারকারীর input (keyboard, mouse) নিয়ে তাকে model-এর ভাষায় অনুবাদ করে: “row 0-তে click” মানে model.toggle(0).

মূল কৌশলটি হলো খবর দেওয়ার দিক। Model বদলালে সে view-দের সরাসরি ডাকে না, বরং observer pattern-এর মতো নিবন্ধিত শ্রোতাদের জানায় “আমি বদলেছি”; প্রতিটি view তখন নিজে model থেকে পড়ে আবার আঁকে। Observer-এর পুরো কাঠামো, unsubscribe আর memory leak-এর ফাঁদ পর্ব ৩৫-এ (Behavioral pattern ১) দেখেছেন; এখানে শুধু তার ব্যবহার। Smalltalk-এ এই সম্পর্ককে বলা হতো “dependents” — model-এর ওপর নির্ভরশীলদের তালিকা। ফলে model-এর কোডে কোনো view-এর নাম নেই, আর নতুন view যোগ করতে model খুলতে হয় না।

নিচের stepper-এ বাজারের তালিকায় দুটি জিনিস আছে — চাল (২) আর পেঁয়াজ (১), কোনোটিই কেনা হয়নি। ব্যবহারকারী চালের row-তে click করলেন। দেখুন click কোন পথে যায়।

এবার একই নকশা চালানো যায় এমন কোডে। DOM বা browser লাগবে না — প্রতিটি “view” শুধু একটি লাইন ছাপে, যাতে প্রবাহটি পরিষ্কার দেখা যায়। Controller একটি text box থেকে "নাম,পরিমাণ" পায়।

// Classic MVC for a fictional bazaar list. No DOM: each "view" prints text.
class ListModel {                                // data + rules; knows no view
  #items = []; #subs = []; subscribe(fn) { this.#subs.push(fn); }
  #notify(change) { for (const fn of this.#subs) fn(change); }  // Observer
  add(name, qty) {
    name = name.trim();
    if (!name) throw new Error("empty name");           // business rules live here
    if (!(qty >= 1)) throw new Error("qty must be >= 1");
    this.#items.push({ name, qty, done: false });
    this.#notify(`add ${name}`);
  }
  toggle(i) { this.#items[i].done = !this.#items[i].done; this.#notify(`toggle ${i}`); }
  get items() { return this.#items.map(x => ({ ...x })); }  // copies only
  get left() { return this.#items.filter(x => !x.done).length; }
}
class ListView {                                 // reads the model, never writes
  constructor(m) { m.subscribe(c => console.log(`list  <- ${c}: ` +
    m.items.map((x, i) => `${i}[${x.done ? "x" : " "}]${x.name} x${x.qty}`).join(", "))); }
}
class BadgeView {                                // a second view of the same model
  constructor(m) { m.subscribe(() => console.log(`badge <- ${m.left} left`)); }
}
class ListController {                           // user input -> model calls
  constructor(model) { this.m = model; }
  onSubmit(text) {                               // "name,qty" from a text box
    const [name, qty = "1"] = text.split(",");
    try { this.m.add(name, Number(qty)); }
    catch (e) { console.log(`ctrl  : rejected "${text}" (${e.message})`); }
  }
  onRowClick(i) { this.m.toggle(i); }
}
const model = new ListModel(); new ListView(model); new BadgeView(model);  // two views
const ctrl = new ListController(model);
ctrl.onSubmit("rice,2"); ctrl.onSubmit("  ,3"); ctrl.onSubmit("dal,0"); ctrl.onSubmit("onion");
ctrl.onRowClick(0);

list  <- add rice: 0[ ]rice x2
badge <- 1 left
ctrl  : rejected "  ,3" (empty name)
ctrl  : rejected "dal,0" (qty must be >= 1)
list  <- add onion: 0[ ]rice x2, 1[ ]onion x1
badge <- 2 left
list  <- toggle 0: 0[x]rice x2, 1[ ]onion x1
badge <- 1 left

৩ · MVC-র অনেক অর্থ — web framework-এর MVC

“MVC” সম্ভবত software-এ সবচেয়ে বেশি অর্থে ব্যবহৃত শব্দগুলোর একটি। Martin Fowler তাঁর “GUI Architectures” প্রবন্ধে (২০০৬) প্রায় এরকম মন্তব্য করেছেন যে MVC-কে সবচেয়ে বেশি উদ্ধৃত করা হয়, আর সবচেয়ে বেশি ভুলভাবে। দুটি বড় অর্থ পাশাপাশি রাখুন।

১৯৯০-এর দশকের শেষ থেকে web application-এর জগতে “MVC” নামটি একটি ভিন্ন কাঠামোর জন্য ব্যবহৃত হতে থাকে — Java-র JSP “Model 2” নকশা, পরে Struts, আর ২০০৪ সালে প্রকাশিত Ruby on Rails এটিকে ব্যাপক জনপ্রিয় করে। এই web MVC-তে:

• Controller একটি HTTP request গ্রহণ করে — যেমন GET /results/240101. Router ঠিক করে কোন controller-এর কোন method (action) চলবে।
• Model সাধারণত database-এর একটি টেবিলের সাথে যুক্ত class (Rails-এ ActiveRecord), সাথে validation আর নিয়ম।
• View একটি template — HTML-এর ফাঁকে ফাঁকে data বসানোর জায়গা। Controller data জোগাড় করে template-কে দেয়, template একটি পূর্ণ HTML পাতা বানায়, পাতা browser-এ যায়।

বড় পার্থক্যটি হলো: এখানে model view-কে খবর দেয় না। HTTP-র প্রতিটি request আলাদা — পাতা একবার বানিয়ে পাঠানো হয়ে গেলে server আর সেই পাতার সাথে যুক্ত থাকে না। Observer-এর সম্পর্ক নেই; প্রবাহটি request → controller → model → view → response, প্রতিবার নতুন করে। Python-এর Django framework (২০০৫) নিজের নকশাকে বলে MTV — Model, Template, View. Django-র ভাষায় “view” হলো যে function request সামলায় (অর্থাৎ অন্যদের controller), আর “template” হলো যা অন্যরা view বলে; Django-র নিজের FAQ-এ বলা আছে, framework নিজেই অনেকটা controller-এর কাজ করে। নাম আলাদা, ভূমিকা প্রায় এক।

তাহলে কোনটি “আসল” MVC? প্রশ্নটি ভাবনার প্রশ্ন ১-এ বিস্তারিত আছে। কাজের কথা হলো, কেউ “আমাদের অ্যাপ MVC” বললে জিজ্ঞেস করুন — কোন MVC? Server-এ পাতা বানানো, না browser-এ চলা interactive UI? দুটির test, bug আর সীমাবদ্ধতা আলাদা। Web-এ request কীভাবে route হয় আর controller কেমন দেখায়, তা হাতেকলমে দেখতে পারেন JavaScript কোর্সের Express দিয়ে REST API পর্বে; URL আর resource-এর নকশা System Design কোর্সের REST API design পর্বে।

৪ · MVP — presenter, passive view আর UI ছাড়া test

Desktop-এর widget যখন নিজেই input ধরতে শুরু করল, তখন প্রশ্ন দাঁড়াল: “ব্যবহারকারী এই button চাপলে কী হবে” — এই সিদ্ধান্তের কোড কোথায় থাকবে? MVP (Model-View-Presenter)-এর উত্তর: একটি presenter-এ। সূত্রমতে নকশাটি ১৯৯০-এর দশকের মাঝামাঝি Taligent-এ (Apple, IBM আর HP-র একটি যৌথ প্রতিষ্ঠান) বর্ণিত হয় — Mike Potel-এর ১৯৯৬ সালের একটি প্রবন্ধে — আর প্রায় একই সময়ে Dolphin Smalltalk-এর নির্মাতারা এটিকে গ্রহণ করেন। সাল আর খুঁটিনাটি সূত্রভেদে কিছুটা আলাদা।

MVP-তে view ঘটনাটি ধরে সঙ্গে সঙ্গে presenter-কে জানায়: “search চাপা হয়েছে, roll এই”. Presenter model বা service-কে ডাকে, ফল সাজায়, তারপর view-কে বলে কী দেখাতে হবে — কিন্তু view-এর আসল class নয়, একটি interface-এর মাধ্যমে: showResult(text), showError(msg), setBusy(flag). এই interface-ই MVP-র শক্তি। Presenter জানে না view একটি web পাতা, Android screen না একটি নকল object — তাই test-এ একটি নকল view বসানো যায়।

দুই রূপ: passive view আর supervising controller

Martin Fowler ২০০৬ সালে MVP-কে দুটি আলাদা নকশায় ভাগ করে বর্ণনা করেন:

নিচের কোডে ফলাফল পোর্টালের search screen-এর presenter. View হিসেবে বসানো হয়েছে একটি spy — একধরনের test double, যে প্রতিটি ডাক লিখে রাখে — আর server-এর বদলে একটি fake service, যার কাছে দুজন কাল্পনিক ছাত্রের ফল আছে। Test runner-টিও কোডের ভেতরেই লেখা, তাই কোনো library লাগে না। Test double-এর নামকরণ (stub, spy, mock, fake) নিয়ে লেখকদের মধ্যে কিছু মতভেদ আছে; বিস্তারিত পর্ব ৪৯-এ (Test double).

// MVP: test a presenter with a fake view and a fake service. No UI at all.
class ResultPresenter {                        // fictional result portal
  constructor(view, service) { this.view = view; this.service = service; }
  onSearch(roll) {
    if (!/^\d{6}$/.test(roll)) return this.view.showError("Roll must be 6 digits");
    this.view.setBusy(true);
    const r = this.service.find(roll);
    this.view.setBusy(false);
    if (!r) return this.view.showError(`No result for ${roll}`);
    this.view.showResult(`${r.name}: GPA ${r.gpa.toFixed(2)}${r.gpa >= 2 ? "" : " (fail)"}`);
  }
}
class FakeView { calls = [];                   // records every call (a spy)
  showError(m) { this.calls.push(`error:${m}`); }
  showResult(t) { this.calls.push(`result:${t}`); }
  setBusy(b) { this.calls.push(`busy:${b}`); }
}
const fakeService = { asked: [], find(roll) { this.asked.push(roll);
  return { "240101": { name: "Mitu", gpa: 3.5 }, "240102": { name: "Rafi", gpa: 1.75 } }[roll]; } };
let passed = 0, failed = 0;
function test(name, fn) {
  const view = new FakeView(); fakeService.asked = [];
  fn(new ResultPresenter(view, fakeService), view);
  console.log(`${name.padEnd(24)} -> ${view.calls.join(" | ")}`);
}
function expect(cond, what) { cond ? passed++ : (failed++, console.log(`  FAIL: ${what}`)); }
test("bad roll", (p, v) => { p.onSearch("24A1");
  expect(v.calls.length === 1 && fakeService.asked.length === 0, "no service call"); });
test("found, formats GPA", (p, v) => { p.onSearch("240101");
  expect(v.calls.at(-1) === "result:Mitu: GPA 3.50", "two decimals"); });
test("below 2.00 marked fail", (p, v) => { p.onSearch("240102");
  expect(v.calls.at(-1).endsWith("(fail)"), "fail mark"); });
test("not found", (p, v) => { p.onSearch("999999");
  expect(v.calls.join() === "busy:true,busy:false,error:No result for 999999", "busy off first"); });
console.log(`${passed} passed, ${failed} failed`);

bad roll                 -> error:Roll must be 6 digits
found, formats GPA       -> busy:true | busy:false | result:Mitu: GPA 3.50
below 2.00 marked fail   -> busy:true | busy:false | result:Rafi: GPA 1.75 (fail)
not found                -> busy:true | busy:false | error:No result for 999999
4 passed, 0 failed

৫ · MVVM — view model, data binding আর two-way binding-এর ফাঁদ

MVP-তে presenter-কে প্রতিটি বদলের পরে view-কে আলাদা করে বলতে হয়: “এখানে এই লেখা, ওই button বন্ধ”. Screen বড় হলে এই “বলার কোড” অনেক হয়ে যায়। MVVM (Model-View-ViewModel) এই কাজটি একটি যন্ত্রের হাতে দেয় — data binding. Microsoft-এর John Gossman ২০০৫ সালে একটি blog লেখায় WPF (Windows-এর তখনকার নতুন UI কাঠামো)-এর জন্য নকশাটি বর্ণনা করেন, পরে Silverlight-এও এটি প্রচলিত হয়; এর আগে Fowler ২০০৪ সালে প্রায় একই চিন্তাকে Presentation Model নামে লিখেছিলেন। পরে JavaScript-এ Knockout.js-এর মতো library এটিকে browser-এ আনে।

View model হলো “screen-এর model” — screen-এ যা দেখাবে তার অবস্থা (state) আর ব্যবহারকারী যা করতে পারেন তার command. বাজার অ্যাপের ক্ষেত্রে: draft (text box-এ যা টাইপ হচ্ছে), items (তালিকা), canAdd (Add button চালু থাকবে কি না) আর add() command — পর্ব ৩৫-এর command pattern-এর একটি হালকা রূপ, সাথে “এখন চালানো যায় কি না” প্রশ্ন। View model কোনো button বা text box চেনে না; সে শুধু observable property রাখে। View declarative ভাবে বলে, “এই text box draft-এর সাথে বাঁধা, এই লেখা items-এর সংখ্যার সাথে”. Binder নামের একটি ছোট যন্ত্র দুই দিক মিলিয়ে রাখে।

• One-way binding: view model বদলালে view বদলায় — যেমন “items(1): potato” লেখাটি।
• Two-way binding: দুই দিকেই — ব্যবহারকারী টাইপ করলে view model বদলায়, আর view model-এ কোড draft খালি করলে text box-ও খালি হয়।

Two-way binding-এর একটি জন্মগত ফাঁদ আছে। View model বদলালে binder text box-এ লেখে; অনেক UI-তে text box-এ লেখা হলে সে আবার একটি “input” ঘটনা ছোড়ে; binder সেটি দেখে view model-এ লেখে; view model আবার খবর দেয়… দুই আয়না মুখোমুখি রাখলে যেমন অসীম প্রতিবিম্ব। প্রতিরোধের সবচেয়ে সাধারণ উপায় হলো equality guard: নতুন মান আগের মানের সমান হলে কিছুই না করা, খবরও না দেওয়া।

নিচের stepper-এ guard চালু আছে। ব্যবহারকারী text box-এ “potato” লিখে Add চাপেন। writes হলো text box-এ binder কতবার লিখেছে।

// MVVM: an observable view model + a tiny binder + a fake view (no DOM).
function observable(value, guard = true) {
  const subs = new Set();
  return { get: () => value,
    set(v) { if (guard && Object.is(v, value)) return;  // the loop guard
             value = v; subs.forEach(f => f(v)); },
    subscribe(f) { subs.add(f); f(value); } };
}
class FakeBox {                  // like an input box: it fires "input" on every write
  constructor(name) { this.name = name; this.value = ""; this.writes = 0; this.oninput = null; }
  write(v) {
    if (++this.writes > 5) throw new Error(`${this.name}: binding loop`);
    this.value = v; this.oninput?.(v);
  }
}
const bindTwoWay = (box, obs) => { obs.subscribe(v => box.write(v)); box.oninput = v => obs.set(v); };
const bindText = (label, obs, fmt) => obs.subscribe(v => label.text = fmt(v));  // one-way
class BazaarVM {                 // state + commands; never touches a box or label
  constructor(guard) { this.draft = observable("", guard); this.items = observable([], guard); }
  get canAdd() { return this.draft.get().trim() !== ""; }
  add() { if (!this.canAdd) return;            // a command with a canExecute check
    this.items.set([...this.items.get(), this.draft.get().trim()]); this.draft.set(""); }
}
for (const guard of [true, false]) {
  const vm = new BazaarVM(guard), box = new FakeBox("draftBox"), label = {};
  try {
    bindTwoWay(box, vm.draft);
    bindText(label, vm.items, xs => `items(${xs.length}): ${xs.join(", ")}`);
    box.value = "potato"; box.oninput("potato");      // the user types
    console.log(`guard=${guard}: vm.draft="${vm.draft.get()}" canAdd=${vm.canAdd}`);
    vm.add();
    console.log(`  label="${label.text}" box="${box.value}" writes=${box.writes}`);
  } catch (e) { console.log(`guard=${guard}: stopped - ${e.message} (writes=${box.writes})`); }
}

guard=true: vm.draft="potato" canAdd=true
  label="items(1): potato" box="" writes=3
guard=false: stopped - draftBox: binding loop (writes=6)

Two-way binding কখন কষ্ট দেয়

• রূপান্তর দুই দিকে না মিললে: view model-এ 1000, box-এ “1,000”. Box থেকে ফেরার পথে “1,000” যদি 1000-এ না ফিরে অন্য কিছুতে (ধরুন "1,000" string) যায়, equality guard আর মেলে না — চক্র বা ভুল মান। নিয়ম: format আর parse পরস্পরের উল্টো হতে হবে।
• এক property আরেকটিকে বদলালে: price বদলালে total, total বদলালে discount, discount আবার price… guard থাকলেও কয়েক ধাপ ঘুরে থামে কি না অনুমান করা কঠিন। এমন নির্ভরতা একটি জায়গায় হিসাব (computed property) হিসেবে রাখুন, শৃঙ্খলে নয়।
• “কে বদলাল?” প্রশ্নের উত্তর মেলে না: একটি মান চারটি জায়গা থেকে বদলাতে পারলে bug-এর উৎস খুঁজতে হয় সবখানে। এই অভিযোগই পরের অংশের নকশার জন্ম দেয়।

৬ · একমুখী data flow — action, reducer আর store

২০১৪ সালে Facebook তাদের web UI-র জন্য Flux নামের একটি নকশা প্রকাশ্যে উপস্থাপন করে। তাদের বক্তব্য অনুযায়ী, দুই দিকে খবর আদান-প্রদানকারী অনেক model আর view-এর জালে একটি পরিচিত bug বারবার ফিরে আসছিল — না-পড়া বার্তার সংখ্যা ভুল দেখানো — কারণ কোন বদল কোথা থেকে এসেছে তা খুঁজে পাওয়া কঠিন ছিল। সমাধান: বদলের একটিমাত্র পথ। ২০১৫ সালে Dan Abramov আর Andrew Clark-এর Redux এই চিন্তাকে আরও সরল করে, Elm ভাষার “Elm architecture” থেকে অনুপ্রেরণা নিয়ে। এই unidirectional data flow-এর চারটি অংশ:

1. Action — “কী ঘটেছে” তার একটি সাধারণ data object: { type: "toggled", id: 1 }. কোনো কোড নয়, শুধু বিবরণ।
2. Reducer — একটি pure function: (পুরোনো state, action) → নতুন state. কোনো network ডাক নেই, কোনো side effect নেই, পুরোনো state বদলায় না, নতুন একটি বানায় — এই গুণের নাম immutability.
3. Store — বর্তমান state-এর একমাত্র রক্ষক। dispatch(action) পেলে reducer চালায়, নতুন state রাখে, শ্রোতাদের জানায়।
4. View — state থেকে screen বানানোর একটি function. ব্যবহারকারী কিছু করলে view নিজে state বদলায় না, শুধু একটি action পাঠায়।

নিচের stepper-এ তালিকায় দুটি জিনিস — rice (id 1) আর egg (id 2), কোনোটিই কেনা হয়নি। ব্যবহারকারী rice-এর row-তে click করলেন।

পুরো প্রোগ্রামটি নিচে। শেষ অংশে log replay করে state আবার বানানো হয়, আর প্রথম তিনটি action পর্যন্ত replay করে “অতীতের” screen দেখা হয়।

// Unidirectional flow: action -> pure reducer -> store -> view. Replay the log.
const initial = { items: [], filter: "all", nextId: 1 };
function reducer(s, a) {                       // pure: no I/O, never mutates s
  switch (a.type) {
    case "added": return { ...s, nextId: s.nextId + 1,
                           items: [...s.items, { id: s.nextId, name: a.name, done: false }] };
    case "toggled": return { ...s, items: s.items.map(x => x.id === a.id ? { ...x, done: !x.done } : x) };
    case "removed": return { ...s, items: s.items.filter(x => x.id !== a.id) };
    case "filterSet": return { ...s, filter: a.filter };
    default: return s;                         // unknown action: same object back
  }
}
function createStore(reduce, state) {
  const log = [], subs = [];
  return { log, getState: () => state, subscribe: f => subs.push(f),
    dispatch(a) { log.push(a); state = reduce(state, a); subs.forEach(f => f(state)); } };
}
const view = s => s.items.filter(x => s.filter === "all" || (s.filter === "left") === !x.done)
                    .map(x => `${x.id}${x.done ? "[x]" : "[ ]"}${x.name}`).join(" ") || "(empty)";
const store = createStore(reducer, initial);
store.subscribe(s => console.log(`${store.log.at(-1).type.padEnd(11)} -> ${view(s)}  (filter=${s.filter})`));
const before = store.getState();
store.dispatch({ type: "added", name: "rice" });
store.dispatch({ type: "added", name: "egg" });
store.dispatch({ type: "toggled", id: 1 });
store.dispatch({ type: "filterSet", filter: "left" });
store.dispatch({ type: "added", name: "oil" });
store.dispatch({ type: "removed", id: 2 });
store.dispatch({ type: "typo-action" });
console.log("old state untouched:", before.items.length === 0 && before !== store.getState());
const rebuilt = store.log.reduce(reducer, initial);   // replay every action
console.log("replay equals live:", JSON.stringify(rebuilt) === JSON.stringify(store.getState()));
const at3 = store.log.slice(0, 3).reduce(reducer, initial);  // "time travel"
console.log("after 3 actions:", view(at3));

added       -> 1[ ]rice  (filter=all)
added       -> 1[ ]rice 2[ ]egg  (filter=all)
toggled     -> 1[x]rice 2[ ]egg  (filter=all)
filterSet   -> 2[ ]egg  (filter=left)
added       -> 2[ ]egg 3[ ]oil  (filter=left)
removed     -> 3[ ]oil  (filter=left)
typo-action -> 3[ ]oil  (filter=left)
old state untouched: true
replay equals live: true
after 3 actions: 1[x]rice 2[ ]egg

Command আর observer-এর সাথে সম্পর্ক

একমুখী data flow নতুন কোনো জাদু নয়; পুরোনো দুটি pattern-এর একটি শৃঙ্খলাবদ্ধ জোড়া। Action হলো পর্ব ৩৫-এর command-এর আত্মীয় — একটি অনুরোধকে data বানানো, যাতে তা লিখে রাখা, queue-তে রাখা আর replay করা যায়। পার্থক্য: command-এর ভেতরে নিজের execute() থাকে, action শুধু বর্ণনা — কাজটি করে reducer. আর store থেকে view-এ খবর যাওয়া হলো observer. নতুন যা, তা হলো নিয়ম: state বদলের একমাত্র দরজা dispatch, আর বদলের যুক্তি একটি pure function. Server-এর দিকে একই চিন্তা — ঘটনার log থেকে অবস্থা বানানো — পাবেন System Design কোর্সের event sourcing আর CQRS পর্বে; JavaScript-এ pure function আর reduce-এর ভিত্তি functional programming পর্বে।

৭ · চারটি নকশা পাশাপাশি, আর component-ভিত্তিক UI

নিচের ছবিতে চারটি নকশার তীর পাশাপাশি। প্রতিটি তীর মানে “এ ওকে ডাকে বা ওকে চেনে”; ড্যাশ তীর মানে “নিবন্ধিত শ্রোতাকে খবর দেয়” — যে খবর দেয়, সে শ্রোতার আসল class চেনে না।

Component-ভিত্তিক UI — প্রতিটি টুকরো নিজেই view আর view model

React (২০১৩ সালে open source), Vue আর Svelte-এর মতো আজকের জনপ্রিয় UI library-গুলো screen-কে ভাবে component-এর গাছ হিসেবে: একটি ResultCard, তার ভেতরে GpaBadge, পাশে SearchBox. প্রতিটি component একটি ছোট ইউনিট, যার ভেতরে থাকে নিজের state (“এই card খোলা কি না”), সেই state বদলানোর handler, আর state থেকে চেহারা বানানোর template বা JSX. MVVM-এর ভাষায় পড়লে, প্রতিটি component নিজেই একটি ছোট “view + view model” — শুধু একই ফাইলে। Component-গুলো একে অপরের ভেতরে বসে, যেমন পর্ব ৩৪-এর composite pattern-এ অংশ আর সমগ্র।

• React: data নিচে নামে props হিসেবে, ঘটনা ওপরে ওঠে callback হিসেবে — প্রতিটি component-এর ভেতরেই ছোট একমুখী flow. State বদলালে component আবার “আঁকা” হয়, আর library পার্থক্যটুকু DOM-এ বসায়। প্রথম দিকে React নিজেকে “MVC-র V” হিসেবে পরিচয় দিত।
• Vue আর Svelte: reactive state — একটি variable বদলালে যেসব জায়গা তাকে পড়ে, শুধু সেগুলো হালনাগাদ হয়; form-এর জন্য two-way binding-এর সুবিধাজনক রূপও আছে, যেমন v-model আর bind:value. MVVM-এর binding-এর আধুনিক বংশধর।
• Global state: অনেক component-এর ভাগের state (লগইন করা ব্যবহারকারী, বাজারের ঝুড়ি) প্রায়ই একটি store-এ যায় — Redux, বা প্রতিটি framework-এর নিজস্ব store ব্যবস্থা। দুই ভাইবোন component কথা বলতে না পারলে একটি সাধারণ অভিভাবক বা store মাঝখানে বসে — পর্ব ৩৬-এর mediator pattern-এর চিন্তা।

Framework-গুলোর বিস্তারিত তুলনা দেখুন JavaScript কোর্সের framework-এর পরিচয় পর্বে, আর browser-এর DOM, যার ওপর সবাই দাঁড়িয়ে, DOM-এর মৌলিক পর্বে। Framework ছাড়া browser-এর নিজস্ব component ব্যবস্থা — custom element আর shadow DOM — HTML & CSS কোর্সের web component পর্বে।

৮ · Business logic কোথায়, প্রতিটি স্তরের test আর তিনটি anti-pattern

Business logic (বা domain logic) মানে সেই নিয়ম, যা UI বদলালেও বদলায় না: GPA ২.০০-এর নিচে হলে fail, ৫০০ টাকার বেশি কেনাকাটায় delivery ফ্রি, একই roll-এ দুবার ভর্তি নয়। এই নিয়মের জায়গা view-এ নয়, controller বা presenter-এও নয়। কারণ সোজা: view আর controller সংখ্যায় অনেক (web, mobile, admin panel, API) আর ঘন ঘন বদলায়; নিয়ম একটি, আর তার ভুলের দাম বেশি।

Fat model, নাকি service layer?

• Fat model: নিয়ম যে data-র, সেই model class-এর method-এ — result.isFail(), cart.deliveryFee(). ছোট আর মাঝারি অ্যাপে সরল আর কার্যকর। বিপদ: একটি model একসময় শত শত method-এর একটি god class হয়ে যায়।
• Service layer: যে কাজ একাধিক model ছোঁয়, বা বাইরের ব্যবস্থাকে ডাকে (ভর্তি নিশ্চিত করা = আসন কমানো + ফি নেওয়া + SMS) — তা একটি service-এ, যেমন EnrollmentService.enroll(). Controller শুধু service ডাকে। Fowler-এর Patterns of Enterprise Application Architecture (২০০২) এই নামটি ছড়িয়ে দেয়।
• সাবধান — anemic domain model: সব নিয়ম service-এ ঠেলে model-কে শুধু getter-setter-এর থলে বানালে Fowler একে বলেন anemic (রক্তশূন্য) — object আছে, কিন্তু object-oriented নকশার সুবিধা নেই।

বাস্তবের ভারসাম্য: যে নিয়ম একটি object-এর নিজের data নিয়ে, তা model-এ; যে কাজ অনেক object আর বাইরের জগৎ মিলিয়ে, তা service-এ; আর UI-র দিকের কোডে শুধু অনুবাদ আর চেহারা। নিয়মকে database, framework আর UI থেকে পুরোপুরি স্বাধীন রাখার আরও কঠোর নকশা — port, adapter আর domain-কে কেন্দ্রে রাখা — দেখবেন পর্ব ৪০-এ: Clean আর hexagonal architecture.

প্রতিটি স্তর কীভাবে test করবেন

নিয়ম যত নিচের স্তরে, test তত সস্তা। এই ভাগই পর্ব ৫১-এর (Test pyramid আর integration test) test pyramid-এর মূল যুক্তি; unit test-এর গঠন (Arrange-Act-Assert) পর্ব ৪৬-এ। JavaScript-এ test লেখার হাতেকলমে পরিচয় পাবেন JavaScript testing পর্বে।

তিনটি পরিচিত anti-pattern

এই anti-pattern-গুলো চেনা আর ছোট নিরাপদ ধাপে সারানো পর্ব ৪২-এর (Code smell আর refactoring) বিষয়; পুরোনো massive controller-কে test ছাড়াই ভাঙতে যাওয়ার ঝুঁকি নিয়ে আলোচনা পর্ব ৪৩-এ: Technical debt আর legacy code. Code review-তে (পর্ব ৪৪, Code review) একটি সহজ প্রশ্ন অনেক কিছু ধরে: “এই if-টি কি screen-এর সিদ্ধান্ত, নাকি ব্যবসার নিয়ম?”

৯ · AI-এর যুগে — AI-এর লেখা UI architecture যাচাই

AI-কে “এই screen-টা MVVM-এ লিখে দাও” বললে প্রায় সবসময় পরিচ্ছন্ন দেখতে কয়েকটি ফাইল আসবে — ResultViewModel, ResultView, ResultService. নাম দেখে নকশা ঠিক ধরে নেওয়া সবচেয়ে বড় ভুল। নামগুলো সঠিক রেখেও ভেতরে view model button-এর রং বদলাতে পারে, বা GPA-র নিয়ম view-এর template-এ বসে থাকতে পারে।

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

• View model, presenter বা reducer-এর ফাইলে UI library-র কোনো import নেই
• প্রতিটি business rule একটিমাত্র জায়গায় আছে; template আর component-এ শুধু দেখানো
• Reducer-কে frozen state দিয়ে চালিয়েছি; একই log replay করে একই state পেয়েছি
• Two-way binding-এ guard খুঁজে পেয়েছি; একটি টাইপে লেখার সংখ্যা গুনেছি
• Test-গুলো ইচ্ছা করে ঢোকানো bug-এ ব্যর্থ হয়, browser ছাড়া চলে, আর একটি আলাদা branch-এ পুরো diff পড়েছি
• ইতিহাস ও framework-এর দাবি মূল সূত্রে মিলিয়েছি; কোডের license আর prompt-এর গোপনীয়তা দেখেছি