Multitype Booking System

Multitype booking system (like expedia.com and booking.com) core.

• About Project
  • Backend
  • Frontend
  • Class diagram
• Future updates
• License

Latest release:

Confirmed in Windows 10 64 bit, compiled by g++

Booking.v1.0.exe

About Project

Hi, I'm Abdullrahmen, and I'm happy to introduce you to my project -Multitype booking system-.

From calling APIs through making interfaces to creating factory methods, this project is a simulation of the process in the real world.

But before we get started, what is a booking system?

A booking system is an interface that allows people to easily choose, reserve, and pay for items(e.g. flights, hotel rooms) from different companies, and stores different items in a container called an itinerary that can be paid for, reserved, modified, etc...

The main difference between my project and a real one is that the real one has real online APIs (I will convert mine to real ones in a future update -I hope).

Backend

We can say that there are five primary steps here:

1. interface to all items
   1. Create interfaces for every company

      If any company's API changes, the type's interface doesn't need to be changed

   2. Create interfaces + factory classes for every type
      • interfaces

        To generalize companies' interfaces to one interface

      • factory classes

        The programmer (in this project's frontend or any other project) doesn't need to recompile his code every time a company's API changed/added

   3. Create an interface for all items

      To generalize types' interfaces to one global item interface to use it in itinerary or any other class that needs a general item

2. interface for payment companies

   same as step one but for payment companies

3. Create an itinerary to store items
   • Containing factory methods to add items, and delete them in the destructor, so the programmer doesn't need to worry about items' memory management.
   • Use the payment interface to pay for items.
4. Create a user class that stores itineraries

   Actually, it has to be in frontend, but because I put it in the Backend folder, I'll write it here.

Frontend

I made the basic process of any other project, even though I didn't focus on amazing frontend part.

• User login/#
• List available items according to filters
• Create/modify/remove itineraries
• I made two classes for cmd menus and will move them to another cmd tools repository soon

Class diagram

Before I started the project, I made my first class diagram to put my main ideas in, and it had many return types and parameters mistakes, but at least it'll give you an idea of how the interfaces and classes link to each other:

For every type and payment companies

The relation between itinerary class and other classes (Here, the factory methods are in the wrong class, I moved them to the Itinerary class, so the user doesn't need to know anything about ItineraryItem class and doesn't need to worry about deleting heap stored items)

Future updates

These are some future updates I hope to make (any contributions would be appreciated)

• Convert online_api folder to real APIs
• # payment info check (in payments APIs, payment interface, Itinerary::pay, and frontend #)
• Add more functionalities in payments
• Separate login info and create a user profile
• Convert itineraries and payment info to string to store them in one table
• Store data in a separate file (database)
• Remove_item in Itinerary class and customer view
• If a reservation fail after the payment is successful, refund the money and cancel the payment
• Refund the money after cancel a reservation
• Add answer pattern option in InputsMenu
• Convert itineraries vector(in User) to pointers (to prevent lots of deep copies) -Important
• Operator = in Itinerary class
• In OptionsMenu add the ability to disable an option (but still visible) (Used in cases like upcoming features)
• Convert cli to gui
• Make the admin part
• Convert raw pointers to smart.
• etc...

License

MPL-2.0 license