ক্যাপস্টোন — একটি আসল C++ সিস্টেম: লাইব্রেরির বই ধারের ব্যবস্থা

১ · প্রোগ্রাম থেকে সিস্টেম — অনেক ছোট অংশ, প্রতিটির একটি কাজ

পঞ্চাশটি পর্বে আপনি C++-এর প্রায় পুরো যন্ত্রপাতি হাতে নিয়েছেন — std::vector থেকে শুরু করে class, template, ranges, move semantics, std::expected, ফাইল, thread, CMake আর টেস্ট। পর্ব ১৯-এর মাঝপথের প্রজেক্টে আপনি একটি দোকানের হিসাবের CLI টুল বানিয়েছিলেন; সেখানে সব ডেটা খোলা struct-এ ছিল, আর নিয়ম রক্ষা করছিল শুধু comment. এবার শেষ বড় ধাপ: এমন একটি সিস্টেম বানানো, যার প্রতিটি অংশ আলাদা করে বোঝা, বদলানো আর টেস্ট করা যায়।

প্রোগ্রাম আর সিস্টেমের পার্থক্য আকারে নয়, গঠনে। একটি ৩০০ লাইনের ফাইলও “সিস্টেম” হতে পারে, যদি তার ভেতরের অংশগুলোর সীমানা পরিষ্কার হয়; আবার ৩০,০০০ লাইনের প্রোগ্রামও একটি বড় জট হতে পারে। ঢাকার মেট্রো রেলের কথা ভাবুন। টিকিট মেশিন জানে না ট্রেন কীভাবে চলে, চালক জানেন না কার্ডে কত টাকা আছে, আর সিগন্যাল-ব্যবস্থা জানে না কোন যাত্রী কোথায় নামবেন। প্রত্যেকে নিজের একটি কাজ করে, আর নির্দিষ্ট “দরজা” দিয়ে একে অপরের সাথে কথা বলে। এই দরজাগুলোর নাম সফটওয়্যারে interface.

প্রজেক্ট: “আলোঘর” লাইব্রেরির বই ধারের ব্যবস্থা

রাজশাহীর একটি পাড়ায় স্বেচ্ছাসেবীরা “আলোঘর” নামে একটি ছোট লাইব্রেরি চালান। কয়েকশো বই, দুইশোর মতো সদস্য — স্কুলের ছাত্রছাত্রী থেকে অবসরপ্রাপ্ত শিক্ষক। এখন হিসাব রাখা হয় একটি খাতায়, আর তিনটি সমস্যা বারবার হয়: যে বইয়ের সব কপি বাইরে, সেটাও “দেওয়া হয়েছে” লেখা হয়; দেরিতে ফেরতের জরিমানা কেউ এক রকম, কেউ আরেক রকম হিসাব করেন; আর খাতা ভিজে গেলে সব হারায়। দায়িত্বে থাকা নাসরিন আপা চান একটি সহজ প্রোগ্রাম।

কেন দোকান নয়, লাইব্রেরি? পর্ব ১৯-এর দোকানে মাল একবার বিক্রি হলে চলে যায়; লাইব্রেরিতে বই ফেরত আসে। ফলে নতুন একটি জিনিস মডেল করতে হয় — সম্পর্ক (কোন সদস্যের কাছে কোন বই, কবে থেকে) আর সময় (কতদিন দেরি)। C কোর্সের ক্যাপস্টোনে বানানো হয়েছিল একটি মিনি ডেটাবেস; এখানে আমরা ডেটাবেস বানাচ্ছি না, বরং ব্যবসার নিয়মসহ একটি পূর্ণ অ্যাপ্লিকেশন — যেখানে নকশার স্তর, ভুল সামলানো আর টেস্টই মূল বিষয়। শেষ পর্যন্ত প্রোগ্রামের সাথে কথোপকথন হবে এমন:

> add B1 2
ok
> lend rina B1 1
ok
> lend tamim B1 2
ok
> lend sakib B1 3
error: no copy of B1 left
> return rina B1 18
ok, fine 6.00 Tk
> report
B1   1/2 on shelf
loans: 1  fines: 6.00 Tk

এই ছোট কথোপকথনের পেছনে কোর্সের প্রায় প্রতিটি মডিউল কাজ করছে। নিচের কার্ডগুলো দেখুন — এগুলোই এই পর্বের মানচিত্র:

২ · চাহিদা — কমান্ডের ছোট টেক্সট-ভাষা আর লাইব্রেরির নিয়ম

পর্ব ১৯-এ দেখেছেন, কোড লেখার আগে লিখিত specification দরকার — “কী” করবে, “কীভাবে” নয়। নাসরিন আপার সাথে আধা ঘণ্টা কথা বলে আমরা প্রথমে লিখলাম প্রোগ্রামের সাথে কথা বলার ভাষা। প্রতিটি লাইন একটি কমান্ড, শব্দগুলো space দিয়ে আলাদা। এমন নিয়মবদ্ধ ছোট ভাষাকে বলে text protocol — ঠিক যেমন SMS-এ “BAL” লিখে ব্যালেন্স জানা যায়। সুবিধা: মানুষ হাতে টাইপ করতে পারে, আবার একটি ফাইলে পুরো সেশন লিখে স্বয়ংক্রিয় টেস্টও করা যায়।

লক্ষ করুন, তারিখের জায়গায় একটি পূর্ণসংখ্যা “দিন নম্বর” — লাইব্রেরির খাতা খোলার দিন ১, পরের দিন ২। এটি একটি সচেতন সরলীকরণ: টেস্ট সহজ হয় আর ফল প্রতিবার একই আসে। পূর্ণ সংস্করণে পর্ব ৪১-এর std::chrono দিয়ে আসল তারিখ বসানো যায়, আর বাকি নকশা একটুও বদলায় না, কারণ “দিন” টাইপটি এক জায়গাতেই সংজ্ঞায়িত।

নিয়মগুলো — যা কখনো ভাঙবে না

spec-এর সবচেয়ে মূল্যবান অংশ কমান্ডের তালিকা নয়, বরং সেই নিয়মগুলো যা সবসময় সত্য থাকতে হবে। পর্ব ২০-এ এদের নাম শিখেছেন: invariant. আলোঘরের তিনটি invariant:

1. I1: প্রতিটি বইয়ের জন্য ০ ≤ বাইরে থাকা কপি ≤ মোট কপি।
2. I2: একজন সদস্যের কাছে একই বইয়ের একাধিক কপি থাকে না; আর প্রতিটি ধার একটি জানা বই আর জানা সদস্যের।
3. I3: মোট জরিমানা কখনো কমে না, আর সবসময় পূর্ণ পয়সায় — ভগ্নাংশ পয়সা বলে কিছু নেই।

এই তিনটি লাইন পুরো প্রজেক্টের মেরুদণ্ড। প্রতিটি ফাংশন লেখার সময় প্রশ্ন একটাই: “এই ফাংশন শেষ হওয়ার পর কি তিনটি নিয়মই সত্য থাকবে — সফল হলেও, ব্যর্থ হলেও?”

৩ · স্থাপত্য — চার স্তর: CLI → service → domain → storage

পর্ব ১৯-এ আমরা তিন ভাগ করেছিলাম: কথা বলা, হিসাব, ডেটা। এবার সংরক্ষণ যোগ হওয়ায় চারটি স্তর। এমন নকশার নাম layered architecture: প্রতিটি স্তর শুধু নিচের স্তরকে চেনে, ওপরেরটাকে কখনো নয়। হাসপাতালের কথা ভাবুন — রিসেপশন রোগীর কথা শুনে টিকিট বানায়, ওয়ার্ডের নার্স ঠিক করেন কোন ডাক্তারের কাছে যাবেন, ডাক্তার চিকিৎসার নিয়ম মানেন, আর রেকর্ড-রুম ফাইল রাখে। ডাক্তার কখনো রিসেপশনে বসে টিকিট কাটেন না।

প্রতিটি স্তরের দায়িত্ব এক বাক্যে বলা যায় — এটাই পর্ব ২৭-এর single responsibility নীতির পরীক্ষা:

• CLI: মানুষের লেখা লাইনকে একটি টাইপ-করা Command-এ রূপান্তর, আর ফলাফলকে মানুষের ভাষায় ফেরানো। কোনো নিয়ম জানে না।
• Service: একটি কমান্ড পূর্ণ করতে কাকে কোন ক্রমে ডাকতে হবে, তা জানে — domain-এর কাজ, তারপর দরকার হলে storage. নিজে কোনো ব্যবসার নিয়ম রাখে না।
• Domain: লাইব্রেরির নিয়ম — invariant, জরিমানার হিসাব। কিছু পড়ে না, কিছু ছাপে না, ফাইল চেনে না। একে বলে domain model.
• Storage: একটি লেখা কোথাও রাখা আর ফিরিয়ে দেওয়া। লাইব্রেরি কী, জানে না।

ফাইল-কাঠামোতেও এই ভাগ চোখে পড়ে। প্রতিটি ফোল্ডার একটি স্তর; কেউ নতুন যোগ দিলে ফোল্ডারের নাম দেখেই বোঝেন কোথায় কী আছে:

alo-library/
├── CMakeLists.txt
├── README.md
├── src/
│   ├── domain/    money.h  error.h  library.h  library.cpp
│   ├── storage/   storage.h  file_storage.h  file_storage.cpp  memory_storage.h
│   ├── service/   library_service.h  library_service.cpp
│   └── cli/       command.h  command.cpp  main.cpp
└── tests/         test_main.cpp  test_library.cpp  sessions/*.txt

একটি কমান্ডের যাত্রা — চার স্তরের ভেতর দিয়ে

এবার দেখুন lend rina B1 1 লাইনটি ঢোকার পর কোন স্তর কী করে। প্রতিটি ধাপে কে কাজ করছে আর কী হাতবদল হচ্ছে, খেয়াল করুন:

"lend rina B1 1"
  → getline → istringstream → "lend"
  → LendCmd{ .member = "rina", .book = "B1", .day = 1 }
Command = std::variant<AddCmd, LendCmd, ReturnCmd, ...>
"lend rina B1 abc" হলে এখানেই থামে: unexpected("bad day")

std::visit(overloaded{
    [&](const LendCmd& c) { return lib_.lend(c.member, c.book, c.day); },
    ...
}, cmd);
service নিজে কোনো নিয়ম জানে না — শুধু সঠিক জায়গায় পাঠায়

B1 আছে?            হ্যাঁ
কপি বাকি?          out 0 < total 2   হ্যাঁ
rina-র কাছে B1?   না
বদল: loans_ += {rina, B1, day 1};  B1.out = 1
I1, I2, I3 — তিনটিই এখনো সত্য

std::expected<Money, Error>  →  has_value() == true, value 0
Storage-কে এই কমান্ডে ডাকা হয়নি — শুধু save/load-এ।
domain জানে না ফলটি কে দেখবে: CLI, GUI, না টেস্ট

if (r) std::println("ok");
else   std::println("error: {}", message(r.error()));
> ok

নকশার সিদ্ধান্ত — কী, কেন, আর কী দাম দিলাম

৪ · Domain — invariant রক্ষাকারী class, Money আর std::expected

সবচেয়ে ভেতরের স্তর দিয়ে শুরু, কারণ বাকি সবাই এর ওপর দাঁড়ায় — আর এটাই সবচেয়ে সহজে টেস্ট করা যায়, কারণ এর কোনো I/O নেই। প্রথম টুকরো টাকা। পর্ব ২৩-এ Money টাইপের ধারণা দেখেছেন; এখানে তার একটি সংক্ষিপ্ত রূপ। এটি একটি value object — পরিচয় নয়, মানই এর সব: দুটি ৬ টাকা সবসময় সমান।

class Money {
    long long paisa_ = 0;                          // invariant: পূর্ণ পয়সা, double নয়
    constexpr explicit Money(long long p) : paisa_(p) {}
public:
    constexpr Money() = default;
    static constexpr Money paisa(long long p) { return Money{p}; }
    static constexpr Money taka(long long t)  { return Money{t * 100}; }
    constexpr long long in_paisa() const { return paisa_; }

    friend constexpr Money operator+(Money a, Money b) { return Money{a.paisa_ + b.paisa_}; }
    friend constexpr Money operator*(Money a, int n)   { return Money{a.paisa_ * n}; }
    friend constexpr auto operator<=>(const Money&, const Money&) = default;
};
std::string to_text(Money m);                      // Money::paisa(650) -> "6.50 Tk"

constructor private, তাই Money{5} লিখে কেউ বোঝাতে পারবেন না এটা ৫ টাকা না ৫ পয়সা — নাম দেওয়া factory function (Money::taka(2)) বাধ্য করে স্পষ্ট হতে। Money-এর সাথে int যোগ করার কোনো operator নেই, ফলে “জরিমানা + দিন নম্বর” ধরনের ভুল compiler-ই আটকায়। operator<=> পর্ব ৪২-এর মতো সব তুলনা একবারে দেয়।

এরপর ভুলের কারণ। পর্ব ১৯-এর Result enum-এর বড় ভাই — এখন এটি std::expected-এর error অংশ:

enum class Error { BadInput, NoSuchBook, NoSuchMember, NoCopyLeft,
                   AlreadyHas, NoSuchLoan, StorageFailed, BadFile };
std::string_view message(Error e);                 // মানুষের ভাষা — CLI ব্যবহার করে

using Day = int;                                   // পরে std::chrono-তে বদলানো যায়
inline constexpr int   kLoanDays   = 14;
inline constexpr Money kFinePerDay = Money::taka(2);

class Library {
public:
    [[nodiscard]] std::expected<void, Error>  add_copies(const std::string& book, int n);
    [[nodiscard]] std::expected<void, Error>  add_member(const std::string& member);
    [[nodiscard]] std::expected<void, Error>  lend(const std::string& m, const std::string& b, Day d);
    [[nodiscard]] std::expected<Money, Error> give_back(const std::string& m, const std::string& b, Day d);
    // শুধু পড়ার জন্য: রিপোর্ট আর storage এগুলো দিয়ে দেখে
    const std::map<std::string, Book>& books() const { return books_; }
    const std::vector<Loan>& loans() const { return loans_; }
    Money fines() const { return fines_; }
private:
    std::map<std::string, Book> books_;            // I1 রক্ষা করে Book নিজেই
    std::set<std::string>       members_;
    std::vector<Loan>           loans_;            // I2: {member, book} একবারই
    Money                       fines_;            // I3: শুধু বাড়ে
};

কয়েকটি বিষয় খেয়াল করুন। প্রতিটি বদলানোর ফাংশনের ফেরত টাইপেই লেখা “এটি ব্যর্থ হতে পারে”, আর [[nodiscard]] থাকায় ফল ফেলে দিলে compiler সতর্ক করে। পড়ার ফাংশনগুলো const& ফেরত দেয় — রিপোর্ট দেখতে পারে, কিন্তু বদলাতে পারে না (পর্ব ১০-এর const-correctness). আর সব ডেটা private — পর্ব ১৯-এ lg.items[0].qty = -5; লেখা যেত, এখানে lib.books_ লিখলে compile-ই হবে না। invariant এখন compiler-এর পাহারায়, পর্ব ২০-এ যেমন কথা দেওয়া হয়েছিল।

যাচাই আর বদল — ব্যর্থ কমান্ডে কিছুই বদলায় না

domain-এর সবচেয়ে গুরুত্বপূর্ণ প্রতিশ্রুতি পর্ব ৩৭-এর strong guarantee-এর মতো: কাজ হয় পুরোপুরি সফল, নয়তো অবস্থা ঠিক আগের মতো। কৌশলটি সরল — সব পরীক্ষা আগে, সব বদল শেষে, আর পরীক্ষা আর বদলের মাঝে এমন কিছু নেই যা ব্যর্থ হতে পারে। এবার একটি ভুল অনুরোধ দেখুন: B1-এর দুটি কপিই বাইরে, আর সাকিব তৃতীয়টি চাইছেন।

1auto cmd = parse(line);   // LendCmd{"sakib","B1",3}2auto it = books_.find(cmd.book);3if (it == books_.end()) return unexpected(NoSuchBook);4if (!it->second.can_lend()) return unexpected(NoCopyLeft);5loans_.push_back(...); it->second.take();  // not reached6if (!r) std::println("error: {}", message(r.error()));7report();

৫ · এক ফাইলে পুরো সিস্টেম — চালিয়ে দেখুন

আসল প্রজেক্টে ফাইল অনেক, কিন্তু অনলাইনে চালাতে একটি ফাইল লাগে। তাই নিচে একটি সংক্ষিপ্ত রূপ — domain (Library class) আর CLI (main) পুরোপুরি আছে, service আর storage বাদ (storage-এর একটি সরল রূপ অংশ ৭-এর টেস্টে চলবে)। Money class-এর জায়গায় সরল using Paisa = long long, আর error হিসেবে সরাসরি বার্তার std::string. ইনপুট আগে থেকেই দেওয়া — একটি সেশন, যাতে ইচ্ছা করে ছয় রকম ভুল রাখা আছে। “Run” চাপুন:

#include <algorithm>
#include <expected>
#include <iostream>
#include <map>
#include <print>
#include <sstream>
#include <string>

using Paisa  = long long;                          // money in paisa, never double
using Result = std::expected<Paisa, std::string>;  // value or a reason
constexpr int   kLoanDays   = 14;
constexpr Paisa kFinePerDay = 200;                 // 2 Tk for each late day

class Library {                                    // invariant: 0 <= out <= total
    struct Copies { int total = 0, out = 0; };
    std::map<std::string, Copies> books_;
    std::map<std::pair<std::string, std::string>, int> loans_;  // {member, book} -> day
    Paisa fines_ = 0;
public:
    Result add(const std::string& b, int n) {
        if (n <= 0) return std::unexpected("copies must be positive");
        books_[b].total += n; return 0;
    }
    Result lend(const std::string& m, const std::string& b, int day) {
        auto it = books_.find(b);
        if (it == books_.end()) return std::unexpected("no book " + b);
        if (it->second.out == it->second.total) return std::unexpected("no copy of " + b + " left");
        if (!loans_.try_emplace({m, b}, day).second) return std::unexpected(m + " already has " + b);
        ++it->second.out; return 0;                // change state only after every check
    }
    Result give_back(const std::string& m, const std::string& b, int day) {
        auto it = loans_.find({m, b});
        if (it == loans_.end() || day < it->second) return std::unexpected("no such loan");
        Paisa fine = std::max(0, day - it->second - kLoanDays) * kFinePerDay;
        loans_.erase(it); --books_[b].out; fines_ += fine; return fine;
    }
    void report() const {
        for (const auto& [id, c] : books_) std::println("{:<4} {}/{} on shelf", id, c.total - c.out, c.total);
        std::println("loans: {}  fines: {}.{:02} Tk", loans_.size(), fines_ / 100, fines_ % 100);
    }
};

int main() {
    Library lib;
    for (std::string line; std::getline(std::cin, line); ) {
        std::istringstream in{line};
        std::string cmd, a, b; int n = 0;
        in >> cmd;
        if (cmd == "report") { lib.report(); continue; }
        Result r = std::unexpected("unknown command '" + cmd + "'");
        if      (cmd == "add"    && in >> a >> n)      r = lib.add(a, n);
        else if (cmd == "lend"   && in >> a >> b >> n) r = lib.lend(a, b, n);
        else if (cmd == "return" && in >> a >> b >> n) r = lib.give_back(a, b, n);
        else if (cmd == "add" || cmd == "lend" || cmd == "return") r = std::unexpected("bad numbers in '" + line + "'");
        if (!r)                   std::println("error: {}", r.error());
        else if (cmd == "return") std::println("ok, fine {}.{:02} Tk", *r / 100, *r % 100);
        else                      std::println("ok");
    }
}

৬ · Storage — একটি interface, দুটি রূপ, আর নিরাপদ round trip

খাতা ভিজে গেলে সব হারায় — নাসরিন আপার তৃতীয় সমস্যা। প্রোগ্রাম বন্ধ হলে মেমরির সব ডেটা মুছে যায়, তাই দরকার persistence: ডেটাকে প্রোগ্রামের জীবনের বাইরে টিকিয়ে রাখা। কিন্তু domain যদি সরাসরি ফাইল খোলে, তাহলে প্রতিটি টেস্ট ডিস্কে লিখবে, ধীর হবে, আর একটির ফাইল আরেকটিকে নষ্ট করবে। সমাধান পর্ব ২৬-এর abstract class: একটি চুক্তি, যার পেছনে যেকোনো রূপ বসানো যায়।

#pragma once
#include <expected>
#include <string>
#include "domain/error.h"

class Storage {                                    // চুক্তি: একটি লেখা রাখা ও ফেরত দেওয়া
public:
    virtual ~Storage() = default;                  // base pointer দিয়ে মুছলেও ঠিক destructor
    [[nodiscard]] virtual std::expected<void, Error> write(const std::string& text) = 0;
    [[nodiscard]] virtual std::expected<std::string, Error> read() const = 0;
};

#include "storage/file_storage.h"
#include <fstream>
#include <sstream>

namespace fs = std::filesystem;

std::expected<void, Error> FileStorage::write(const std::string& text) {
    fs::path tmp = path_;
    tmp += ".tmp";                                 // আগে পাশের একটি ফাইলে লিখি
    {
        std::ofstream out(tmp, std::ios::binary);
        out << text;
        out.close();                               // এখনই flush, যাতে ভুল ধরা যায়
        if (!out) return std::unexpected(Error::StorageFailed);
    }                                              // RAII: যা-ই ঘটুক, ফাইল বন্ধ
    std::error_code ec;
    fs::rename(tmp, path_, ec);                    // তারপর এক ধাপে পুরোনোটার জায়গায়
    if (ec) return std::unexpected(Error::StorageFailed);
    return {};
}

std::expected<std::string, Error> FileStorage::read() const {
    std::ifstream in(path_, std::ios::binary);
    if (!in) return std::unexpected(Error::StorageFailed);
    std::ostringstream all;
    all << in.rdbuf();                             // পুরো ফাইল একবারে
    return all.str();
}

#pragma once
#include "storage/storage.h"

class MemoryStorage final : public Storage {       // টেস্টের জন্য: ডিস্ক নেই
public:
    std::expected<void, Error> write(const std::string& text) override {
        if (fail_next_) { fail_next_ = false; return std::unexpected(Error::StorageFailed); }
        data_ = text; return {};
    }
    std::expected<std::string, Error> read() const override { return data_; }
    void fail_next_write() { fail_next_ = true; }  // ডিস্ক-ভরা অবস্থার অভিনয়
private:
    std::string data_;
    bool fail_next_ = false;
};

তিনটি জিনিস লক্ষ করুন। এক, FileStorage::write সরাসরি আসল ফাইলে লেখে না। আগে library.txt.tmp-এ লেখে, সফল হলে std::filesystem::rename দিয়ে পুরোনো ফাইলের জায়গায় বসায়। লেখার মাঝপথে বিদ্যুৎ গেলে নষ্ট হয় শুধু tmp ফাইল; আসলটি আগের অবস্থায় থাকে। এই কৌশলের নাম atomic write. POSIX সিস্টেমে একই ফাইল-সিস্টেমের ভেতরে rename একটি ধাপে ঘটে বলে নিশ্চয়তা দেওয়া আছে; তবে লেখাটি সত্যিই ডিস্কে পৌঁছেছে কি না (fsync) — সেই নিশ্চয়তা স্ট্যান্ডার্ড C++ দেয় না, তার জন্য অপারেটিং সিস্টেমের ফাংশন লাগে। দুই, block-এর }-এ std::ofstream নিজেই ফাইল বন্ধ করে — পর্ব ১৭-এর RAII; কোনো পথে close ভুলে যাওয়ার সুযোগ নেই। তিন, MemoryStorage একটি test double, আর ইচ্ছা করলে ব্যর্থও হতে পারে — ফলে “ডিস্ক ভরা থাকলে কী হয়” টেস্ট করতে আসল ডিস্ক ভরাতে হয় না।

service কোন রূপ পেল, জানে না — constructor-এ একটি Storage& নেয়। এর নাম dependency injection: নির্ভরতা বাইরে থেকে ঢোকানো।

// আসল প্রোগ্রাম                          // টেস্ট
FileStorage disk{"library.txt"};           MemoryStorage mem;
Library lib;                               Library lib;
LibraryService svc{lib, disk};             LibraryService svc{lib, mem};

save → ফাইল → load: একটি round trip

মেমরির object-কে লেখায় রূপান্তরকে বলে serialization, আর উল্টোটাকে parsing. একটি সংরক্ষণ-ব্যবস্থা তখনই বিশ্বাসযোগ্য, যখন “লিখে আবার পড়লে হুবহু একই জিনিস” — এর পরীক্ষাকে বলে round-trip test. সবচেয়ে সূক্ষ্ম অংশ load: ফাইলটি ভাঙা হলে কী হবে? ধাপে ধাপে দেখুন:

books_   B1 {total 2, out 1}   B2 {total 1, out 0}
members_ rina, tamim
loans_   {rina, B1, day 1}
fines_   600 paisa

alo-library v1
book B1 2
book B2 1
member rina
member tamim
loan rina B1 1
fines 600
out লেখা হয়নি — loan লাইন থেকে আবার গোনা যায়

library.txt.tmp  ← নতুন লেখা পুরোটা
close(), !out?   না, সফল
rename(tmp, library.txt)
এর মাঝে বিদ্যুৎ গেলে: library.txt পুরোনো, কিন্তু সম্পূর্ণ

প্রথম লাইন "alo-library v1"?       হ্যাঁ
book B1 2      → add_copies("B1", 2)     ok
loan rina B1 1 → lend("rina","B1",1)     ok
loan sakib B7 3 → NoSuchBook  → unexpected(BadFile)
একই domain ফাংশন দিয়ে তৈরি, তাই invariant আবার যাচাই হয়

auto fresh = parse_library(text);      // নতুন, আলাদা object
if (!fresh) return std::unexpected(fresh.error());
lib_ = std::move(*fresh);              // move: কপি নয় (পর্ব ৩৬)
report → হুবহু ধাপ ১-এর মতো · ভাঙা ফাইলে পুরোনো lib_ অক্ষত

রিপোর্ট — container, algorithm আর ranges

domain যা জানে, রিপোর্ট তা থেকে প্রশ্নের উত্তর বানায়: কার কাছে দেরি হচ্ছে? কোন বই সবচেয়ে জনপ্রিয়? এখানে মডিউল ৫-এর যন্ত্রপাতি — views::filter, ranges::sort-এর projection আর views::take. রিপোর্ট শুধু const& দিয়ে পড়ে, তাই সে নিজে কখনো invariant ভাঙতে পারে না:

// দিন `today`-তে যাদের দেরি হচ্ছে
auto late = lib.loans() | std::views::filter([today](const Loan& l) {
    return today - l.day > kLoanDays;
});
for (const Loan& l : late)
    std::println("{:<8} {:<4} late {} days", l.member, l.book, today - l.day - kLoanDays);

// সবচেয়ে বেশি ধার হওয়া ৩টি বই
auto top = lib.books() | std::views::values | std::ranges::to<std::vector>();
std::ranges::sort(top, std::ranges::greater{}, &Book::times_lent);   // projection
for (const Book& b : top | std::views::take(3))
    std::println("{:<4} {}", b.id(), b.times_lent());

views::filter কোনো নতুন vector বানায় না — হাঁটার সময় শর্ত দেখে (পর্ব ৩৫-এর lazy evaluation). std::ranges::to C++23 থেকে আছে; এর আগে হাতে vector বানিয়ে কপি করতে হতো। sort-এর তৃতীয় argument একটি member function pointer — ranges algorithm-এর projection সেটি ডেকে তুলনার মান বের করে, ফলে আলাদা comparator lambda লিখতে হয় না। আর রিপোর্টের আউটপুট নির্ধারিত (map-এর ক্রম), তাই golden-file টেস্টে মেলানো যায়।

৭ · ধাপে ধাপে বানানো — ছয় মাইলস্টোন, টেস্ট harness আর CMake

পর্ব ১৯-এর শিক্ষা এখানে আরও জরুরি: পুরো সিস্টেম একবারে লিখে প্রথমবার compile করবেন না। ছয়টি মাইলস্টোন, প্রতিটির শেষে প্রোগ্রাম চলে আর টেস্ট সবুজ। লক্ষ করুন, ক্রমটি ভেতর থেকে বাইরে — আগে domain, শেষে সাজসজ্জা:

Money, Error, Book, Library::add_copies / lend / give_back
টেস্ট: সফল ধার · শেষ কপি · কপি নেই → অবস্থা অক্ষত
      ঠিক ১৪ দিনে ফেরত → 0 · ১৭ দিনে → 6.00 Tk

getline → parse_command → std::visit → println
টেস্ট: sessions/basic.txt → golden output মেলে
      EOF-এ শান্তভাবে শেষ · অজানা কমান্ডে বার্তা

BadInput · NoSuchBook · NoSuchMember · NoCopyLeft
AlreadyHas · NoSuchLoan
টেস্ট: sessions/errors.txt — প্রতিটি ভুলের পর report অপরিবর্তিত
এখানেই MVP: নাসরিন আপা ব্যবহার শুরু করতে পারেন

serialize · parse_library · save · load
টেস্ট: round trip হুবহু · ভাঙা ফাইলে BadFile, অবস্থা অক্ষত
      fail_next_write() → StorageFailed

cmake -S . -B build && cmake --build build && ctest --test-dir build
টেস্ট: আসল ফাইলে save → প্রোগ্রাম বন্ধ → খুলে load
      -fsanitize=address,undefined-এ সব টেস্ট পরিষ্কার

overdue <day> · top · report-এর সুন্দর টেবিল
টেস্ট: M1–M5-এর সব টেস্ট হুবহু আবার পাস (refactoring-এর প্রমাণ)
ঐচ্ছিক: std::jthread দিয়ে background autosave

একটি ছোট টেস্ট harness — নিজের হাতে

আসল প্রজেক্টে GoogleTest বা Catch2-এর মতো framework চলে (পর্ব ৪৮)। কিন্তু মূল ধারণাটি এতই সরল যে দশ লাইনে লেখা যায়: একটি শর্ত, একটি নাম, PASS বা FAIL ছাপা, আর শেষে ব্যর্থতার সংখ্যা exit code হিসেবে — যাতে CI বা ctest বুঝতে পারে। এমন ছোট কাঠামোকে বলে test harness. নিচের টেস্টে Storage interface, MemoryStorage, round trip আর ভাঙা ফাইল — অংশ ৬-এর সব কিছু, একটি সরল Catalog-এর ওপর:

#include <algorithm>
#include <expected>
#include <format>
#include <map>
#include <print>
#include <sstream>
#include <string>

struct Storage {                                   // the storage interface
    virtual ~Storage() = default;
    virtual void write(const std::string& text) = 0;
    virtual std::string read() const = 0;
};
struct MemoryStorage : Storage {                   // test double: no disk at all
    std::string data;
    void write(const std::string& text) override { data = text; }
    std::string read() const override { return data; }
};
using Catalog = std::map<std::string, int>;        // book id -> copies

void save(const Catalog& c, Storage& s) {
    std::string out;
    for (const auto& [id, n] : c) out += std::format("{} {}\n", id, n);
    s.write(out);
}
std::expected<Catalog, std::string> load(const Storage& s) {
    Catalog c; std::istringstream in{s.read()};
    std::string id; int n = 0;
    while (in >> id >> n) {
        if (n <= 0) return std::unexpected("bad copies for " + id);
        c[id] = n;
    }
    if (!in.eof()) return std::unexpected("broken line");
    return c;
}
long long fine_for(int lent, int back) { return std::max(0, back - lent - 14) * 200LL; }

int failures = 0;
void check(bool ok, const char* name) {
    std::println("{} {}", ok ? "PASS" : "FAIL", name);
    if (!ok) ++failures;
}

int main() {
    check(fine_for(1, 15) == 0, "returned on day 14: no fine");
    check(fine_for(1, 18) == 600, "3 days late: 6.00 Tk");
    MemoryStorage mem;
    const Catalog books{{"B1", 2}, {"B2", 1}};
    save(books, mem);
    auto back = load(mem);
    check(back && *back == books, "save then load gives the same catalog");
    mem.write("B1 2\nB2 -4\n");
    check(!load(mem), "negative copies are rejected");
    mem.write("B1 two\n");
    check(!load(mem), "broken number is rejected");
    return failures;                               // 0 means every test passed
}

CMake — পুরো প্রজেক্টের বিল্ড এক জায়গায়

পর্ব ৪৭-এর মতো, domain + storage + service মিলে একটি library target, যার সাথে দুটি executable link হয় — আসল প্রোগ্রাম আর টেস্ট। ফলে টেস্ট ঠিক সেই কোডই পরীক্ষা করে, যা প্রোগ্রামে চলে (এটি চালানোর কোড নয়, বিল্ডের বিবরণ):

cmake_minimum_required(VERSION 3.25)
project(alo_library LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_library(library_core
    src/domain/library.cpp
    src/domain/money.cpp
    src/storage/file_storage.cpp
    src/service/library_service.cpp)
target_include_directories(library_core PUBLIC src)
target_compile_options(library_core PUBLIC -Wall -Wextra -Wpedantic)

add_executable(alo src/cli/main.cpp src/cli/command.cpp)
target_link_libraries(alo PRIVATE library_core)

enable_testing()
add_executable(library_tests tests/test_main.cpp tests/test_library.cpp)
target_link_libraries(library_tests PRIVATE library_core)
add_test(NAME unit COMMAND library_tests)

ctest চালালে library_tests-এর exit code দেখে — ০ মানে সফল। harness-এর return failures; ঠিক এই কারণেই। -Wextra আর -Wpedantic GCC আর Clang-এর flag; MSVC-র flag আলাদা (যেমন /W4), তাই আসল প্রজেক্টে compiler দেখে শর্তসাপেক্ষে দেওয়া হয়।

৮ · AI-এর যুগে — ক্যাপস্টোনে AI আপনার pair programmer, মালিক আপনি

আজ একটি প্রম্পটেই এমন পুরো একটি প্রজেক্ট AI দিয়ে লেখানো যায় — হাজার লাইন, সুন্দর README সহ। কিন্তু ক্যাপস্টোনের উদ্দেশ্য কোড জমা দেওয়া নয়; উদ্দেশ্য হলো আপনি একটি সিস্টেম নকশা করতে, ব্যাখ্যা করতে আর প্রমাণ করতে পারেন। ইন্টারভিউতে কেউ জিজ্ঞেস করবেন “load ব্যর্থ হলে পুরোনো অবস্থা কেন থাকে?” — তখন AI পাশে থাকবে না। তাই পর্ব ১৯-এর pair programming নিয়মগুলো এখানে আরও কঠোর:

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

• প্রতিটি ফাইলের প্রতিটি লাইন আমি মুখে ব্যাখ্যা করতে পারি; যা পারি না, তা বাদ বা নিজে নতুন করে লেখা
• domain-এ কোনো std::cin, println বা ফাইল খোলা নেই; storage-এ কোনো ব্যবসার নিয়ম নেই
• টাকা কোথাও double-এ নেই; জরিমানার গুণ Money বা পূর্ণসংখ্যায় (পর্ব ২৩)
• প্রতিটি ব্যর্থ পথ std::expected ফেরত দেয়, আর আগে সব যাচাই, পরে বদল (পর্ব ৩৭)
• খোঁজার জায়গায় map::operator[] নেই — অজানা চাবি নীরবে তৈরি হয় না (পর্ব ৩১)
• কোনো new/delete নেই; ফাইল, mutex আর thread RAII-তে (পর্ব ১৭, ৪৫)
• প্রতিটি Error-এর অন্তত একটি টেস্ট আছে, আর sanitizer-সহ সব টেস্ট সবুজ (পর্ব ৪৮)
• AI যে library বা ফাংশনের নাম দিয়েছে, তা সত্যিই আছে — cppreference-এ মিলিয়ে দেখা

৯ · এরপর কোথায় — বাড়ানোর দিক, portfolio আর কোর্সের মানচিত্র

MVP শেষ হলে প্রজেক্ট শেষ নয় — বরং এখন এটি একটি নিরাপদ ভিত্তি, যার ওপর আরও কিছু বসানো যায়। প্রতিটি দিক একটি নতুন দক্ষতা; প্রতিটিতে আগের স্তরগুলো কতটা অক্ষত থাকে, সেটাই নকশার মান মাপে:

লক্ষ করুন, কোনো সারিতেই “domain বদলায়” নেই। নকশা ঠিক থাকলে নিয়মের হৃদয় সবচেয়ে স্থির অংশ — চারপাশের প্রযুক্তি বদলায়, লাইব্রেরির নিয়ম বদলায় না।

Portfolio — কাজটি দেখান

চাকরির বাজারে, বিশেষ করে প্রথম চাকরিতে, একটি ভালো প্রজেক্ট অনেক সময় সনদের চেয়ে বেশি কথা বলে। কিন্তু GitHub-এ কোড রাখাই যথেষ্ট নয় — যিনি দেখবেন, তাঁর হাতে হয়তো পাঁচ মিনিট। সেই পাঁচ মিনিটে কী দেখাবেন:

• README প্রথম পর্দায়: এক লাইনে কী সমস্যা সমাধান করে, একটি ছোট নমুনা সেশন, বিল্ডের তিনটি কমান্ড, আর চার স্তরের ছবি। তারপর “নকশার সিদ্ধান্ত” অংশ — অংশ ৩-এর টেবিলটিই।
• পরিষ্কার commit-ইতিহাস: মাইলস্টোন ধরে ধরে (M3: all error paths tested). ইতিহাস দেখে বোঝা যায় আপনি ধাপে ধাপে ভাবেন, এক রাতে কোথাও থেকে কপি করেননি।
• CI-তে সবুজ টেস্ট: GitHub Actions-এ প্রতিটি push-এ বিল্ড আর ctest (continuous integration). README-র ওপরে একটি সবুজ badge অনেক কিছু বলে।
• সৎ সীমারেখা: “যা এখনো নেই” অংশ — concurrency নেই, একটি কাউন্টার ধরে নেওয়া হয়েছে। সীমা জানা ইঞ্জিনিয়ার সীমা না জানা ইঞ্জিনিয়ারের চেয়ে অনেক বেশি বিশ্বাসযোগ্য।

Interviewer-রা সাধারণত কোডের আকার দেখেন না; দেখেন আপনি কেন একটি জিনিস এভাবে করলেন, অন্যভাবে করলে কী হতো, আর কীভাবে জানেন যে এটা কাজ করে। “কেন std::map?” প্রশ্নে “কারণ রিপোর্ট সাজানো চাই, আর কয়েক হাজার বইয়ে log n যথেষ্ট — মাপলে বদলাব” একটি চমৎকার উত্তর; “AI দিয়েছিল” নয়।

কোর্সের মানচিত্র — আপনি যা শিখেছেন, আর ক্যাপস্টোনে কোথায়

এই পর্বের সাথে কোর্সের শেখানোর অংশ শেষ হলো। পরের মডিউল ৮ পরীক্ষা ও ইন্টারভিউর প্রস্তুতির — কোড পড়ে আউটপুট বলা, MCQ, লিখিত-মৌখিক প্রশ্ন আর কোডিং ইন্টারভিউ। সেখানে প্রতিটি প্রশ্নে আপনি দেখবেন, এই ক্যাপস্টোনের কোনো না কোনো সিদ্ধান্তের পেছনের কারণটাই আসলে জিজ্ঞেস করা হচ্ছে।