📚 Library Management System

A CLI-based Library Management System built in C++ — designed to demonstrate Object-Oriented Programming concepts and a structured Git/GitHub branching workflow, documented as an academic project.

---

Overview

This project has two parallel goals:

1. OOP in C++ — implement all four pillars of object-oriented programming (encapsulation, inheritance, polymorphism, abstraction) in a real working system, not just isolated examples.
2. Git workflow — build the project through a disciplined feature-branching strategy with pull requests, tags, and a real merge conflict — producing a commit history that tells the story of the development process.

A raylib GUI port is planned as Phase 2, where the same C++ class architecture will be reused with a graphical front-end replacing the CLI menu — demonstrating that well-encapsulated OOP design is portable across presentation layers.

---

Features

As Admin (username: admin, password: 1234)

• Add and remove books
• View all books and members
• Save library state to file
• Load library state from file

As Member (ID: 1 or 2, password: 1234)

• Search books by ISBN
• Borrow a book
• Return a book

---

Project Structure

Library-Management-System/
├── include/                  → Header files (.h) — class declarations
│   ├── Book.h
│   ├── MemberRecord.h
│   ├── Library.h
│   ├── User.h
│   ├── Admin.h
│   └── MemberAccount.h
├── src/                      → Implementation files (.cpp)
│   ├── Book.cpp
│   ├── MemberRecord.cpp
│   ├── Library.cpp
│   ├── User.cpp
│   ├── Admin.cpp
│   └── MemberAccount.cpp
├── data/
│   └── books.txt             → Persistent storage (save/load)
├── main.cpp                  → CLI entry point
└── README.md

---

OOP Design

Each class demonstrates a specific OOP concept, built incrementally on its own feature branch.

Class	Concept	Description
Book	Encapsulation	Private fields (title, author, ISBN, availability) with public getters/setters only
MemberRecord	Encapsulation	Controls borrowed books list through borrowBook() / returnBook() methods
Library	Composition	Owns vector<Book> and vector<MemberRecord>; coordinates issue/return logic across both
User	Abstraction	Abstract base class with pure virtual displayMenu() and getRole() — cannot be instantiated directly
Admin : User	Inheritance	Inherits from User; provides Admin-specific menu and role
MemberAccount : User	Polymorphism	Both Admin and MemberAccount called through User* pointer; runtime dispatch selects correct method

Additional concepts demonstrated:

• operator== overloaded on Book for ISBN comparison
• operator<< overloaded on Book for clean cout output
• Lambda expressions with find_if for collection searches
• File I/O with fstream for persistence
• virtual destructor on base class for safe pointer deletion

---

How to Run

Prerequisites

• g++ compiler (MinGW or w64devkit recommended on Windows)
• C++17 or later

Compile

g++ -Iinclude src/Book.cpp src/MemberRecord.cpp src/Library.cpp src/User.cpp src/Admin.cpp src/MemberAccount.cpp main.cpp -o app

Run

./app        # Git Bash / Linux / Mac
app.exe      # Windows CMD

Default credentials

Role	Username / ID	Password
Admin	admin	1234
Member	1 (Hira) or 2 (Ahmed)	1234

---

Git Workflow

The project used a structured two-level branch strategy:

• main — kept completely clean until the final merge at project completion
• develop — integration branch; all feature branches merged here first via pull requests
• feature/* — one branch per feature, one PR per merge
• refactor/* — design improvements after initial integration

Branch map

Branch	PR	OOP Concept	Git Concept
feature/book-class	#1	Encapsulation	Feature branching
feature/member-class	#2	Encapsulation	PR workflow
feature/library-core	—	Composition	Cherry-pick recovery
feature/issue-return-logic	#3	Encapsulation enforcement	Tagging (v0.2)
feature/user-hierarchy	#4	Inheritance + Polymorphism	Branch isolation
feature/operator-overload	#5	Compile-time polymorphism	Pending PR strategy
feature/file-persistence	#6	Integration	Merge conflict case study
feature/cli-menu	#7	Full integration	v1.0 milestone
refactor/user-hierarchy	#8	Iterative design	Refactor branching

Commit convention

All commits follow Conventional Commits:

• feat: — new feature
• refactor: — code improvement without behavior change
• merge: — conflict resolution
• chore: — setup / configuration

Merge conflict case study

feature/operator-overload (PR #5) and feature/file-persistence (PR #6) were simultaneously left open, both modifying the same section of main.cpp. PR #5 was merged first. When PR #6 was compared against the updated develop, GitHub flagged an unresolvable conflict. It was resolved manually via git merge develop inside the feature branch, editing the conflict markers to preserve both sections, then committed as merge: resolve conflict — visible in the commit graph below as a documented, timestamped event.

---

Commit Graph

Full branch history captured at project completion via git log --graph --oneline --all:

*   c765ce1 (HEAD -> main, origin/main, develop) Merge pull request #8 refactor/user-hierarchy
|\
| * 4070742  refactor: clean up User hierarchy after integration
|/
*   2094279 (tag: v1.0) Merge pull request #7 feature/cli-menu
|\
| * 98ded60  feat: add CLI menu integrating all features
|/
*   0e3e086 (tag: v0.3) Merge pull request #6 feature/file-persistence
|\
| *   002b356  merge: resolve conflict  ← merge conflict case study
| |\
| |/
|/|
* |   16b223e  Merge pull request #5 feature/operator-overload
|\ \
| * | 594a85f  feat: add operator overloads for Book
|/ /
| * a90bdf7   feat: add file persistence for books and members
|/
* d4efd9b    feat: add abstract User hierarchy with Admin and MemberAccount
*   401d023 (tag: v0.2) Merge pull request #3 feature/issue-return-logic
|\
| * 2aed0b8  feat: add issue/return logic
|/
* ca72ac0 (tag: v0.1)  feat: add Library class with core CRUD
* 90a4c4b    feat: add MemberRecord class
*   b158f77  Merge pull request #1 feature/book-class
|\
| * 890f46b  feat: add Book class
|/
* 2f8c994    initial project structure  ← main started here

Every |\ and |/ in the graph represents a branch diverging (new feature branch created) and merging back (PR merged into develop). The conflict resolution at 002b356 shows its own branching shape — two branches meeting at a conflict point, resolved manually, then merged.

---

Releases & Milestones

Tag	Milestone
v0.1	Core classes complete — Book, MemberRecord, Library
v0.2	Issue/return logic added
v0.3	File persistence + merge conflict resolved
v1.0	Full CLI feature-complete
v1.0-release	Final release — develop merged into main

---

Built by Syeda Hira Batool · C++ · raylib (Phase 2) · Git/GitHub