IRCTC Railway Reservation System (OOAD + C++17)

This project is a simplified IRCTC Railway Reservation System implemented in modern C++17, following Object-Oriented Analysis & Design principles, SOLID principles, and classic design patterns.

Directory Structure

• include/ – Header files for all domain entities and services:
  • User.h, Admin.h, Train.h, Ticket.h
  • Payment.h, UpiPayment.h, CardPayment.h, NetBankingPayment.h
  • PaymentFactory.h, TrainDatabase.h, TrainService.h
  • PaymentService.h, BookingService.h
  • FareStrategy.h, SimpleFareStrategy.h
• src/ – Implementation files for all headers.
• main.cpp – Interactive demo program:
  • Prompts for user details
  • Seeds sample trains
  • Lets the user search trains
  • Books a ticket based on user choice
  • Processes payment
  • Optionally cancels the ticket and shows updated status
• Makefile – Build script (make to build, ./irctc to run). // uml/ – UML design diagrams (no longer included in this repository).

UML & Code Alignment

• Actors: User, Admin, Payment Gateway (Use Case / Sequence diagrams).
• Entities:
  • User, Admin, Train, Ticket.
• Payments:
  • Interface: Payment
  • Implementations: UpiPayment, CardPayment, NetBankingPayment
  • Factory: PaymentFactory
• Core Services:
  • TrainDatabase (Singleton in-memory store for Train)
  • TrainService (search, check availability, seat management)
  • PaymentService (delegates to PaymentFactory and Payment)
  • BookingService (coordinates booking, payment, ticket creation)
• Strategy:
  • FareStrategy (interface), SimpleFareStrategy (concrete)
• Relationships:
  • BookingService uses TrainService + PaymentService + FareStrategy.
  • PaymentService uses PaymentFactory → Payment (interface).
  • TrainDatabase stores Train objects (Singleton).
  • Ticket depends on Train + User.

All these relationships are reflected in the original UML design diagrams.

SOLID Principles

• S – Single Responsibility
  • Train only manages its own seat and schedule data.
  • TrainDatabase only manages storage/retrieval of trains.
  • TrainService handles train-related use cases.
  • BookingService orchestrates booking and cancellation workflows.
  • PaymentService orchestrates payment using Payment abstractions.
• O – Open/Closed
  • New payment types can be added by creating a new class implementing Payment and registering a creator in PaymentFactory, without changing callers of PaymentService.
  • New fare calculation strategies can be added by implementing FareStrategy and injecting into BookingService.
• L – Liskov Substitution
  • UpiPayment, CardPayment, NetBankingPayment can all be used wherever Payment*/Payment& is expected.
• I – Interface Segregation
  • Payment is focused only on payment operations.
  • FareStrategy is focused only on fare calculation.
• D – Dependency Inversion
  • High-level BookingService depends on abstractions (FareStrategy, Payment through PaymentService and PaymentFactory), not on concrete payment types.
  • PaymentService depends on PaymentFactory and Payment abstraction, not on specific payment implementations.

Design Patterns Used

• Singleton Pattern – TrainDatabase
  • Provides a single shared in-memory store for all train objects.
• Factory Pattern – PaymentFactory
  • Centralizes creation of payment method objects (Payment implementations).
• Strategy Pattern – FareStrategy / SimpleFareStrategy
  • Encapsulates fare calculation logic, allowing future strategies (e.g., dynamic pricing, discounts).

Build & Run

cd IRCTC
make
./irctc   # on Linux / macOS
# or .\irctc.exe on Windows

When you run the program you will see an interactive menu that lets you:

1. Enter user details.
2. Search trains by source and destination.
3. Select a train, number of seats, date, and payment method.
4. View the booked ticket and optionally cancel it.