Design patterns

Question

I am trying to understand design patterns (the Observer pattern in particular). I am trying to create a design pattern for the below scenario (specifically the seconnd paragraph). I have included an image of the UML diagram I have managed to produce so far. Could people please advise on whether it is correct/wrong/adequate/inadequate or give me any tips that would help? I have tried to use the Observer pattern to model the system - are there any additional patterns that could be used to model this scenario?

Consider the design of a system to support flight reservations and flight status alerts for an airline. The system centrally stores information about registered customers and controls customers' access to the information. A customer maintains a profile describing some basic information including name, country of residence, gender, birth date, email address and mobile number. A customer can search for round-trip flights on the airline by entering the city name or airport code for the origin and destination. Upon finding an itinerary of acceptable flights, a customer can purchase the flights in economy class, business class or first class. Upon completing the purchase, a customer can select seats on the chosen flights in the class of service paid for. The system will deliver alerts about the flights to the customer's alert address, which can be the email address and/or mobile number, depending on the customer's choice. An alert may indicate a delay to a flight, a cancellation to a flight, or some other change to flight status that may be introduced in future versions of the system.

At some point a flight becomes available for purchase with a specified flight date. A customer can purchase a seat on the flight np to one week before the flight date; after this date the flight is closed to further seat purchases. In addition, once a flight becomes available for purchase, its status is on-time until one day before the flight, after which it can become delayed upon occurrence of a weather delay, cancelled upon a decision to cancel the flight, and landed upon successful completion of the flight. A flight ceases to exist after it becomes cancelled or landed.

https://i.sstatic.net/YB9lJ.jpg

Answer 1

Unlike Splendor I would not use a third class which manages all observers.

1. It adds complexity.
2. Reusing events for other types of objects will most likely result in violations of Liskovs Substitution Principle.

However, if you have a Car class, you can derive it Volvo : Car and you'll still be able to work with the subscribers.

Your design is in other words fine.

Note that I didn't read that bloat of text that you quoted. If you need more help, break the text into parts where you think that a design pattern is applicable.

Answer 2

Observer pattern should be fine. Only comment is the image that you have provided is not complete.

1. Try avoiding direct coupling between observer and subject.
2. Instead use a class which can manage all the observers.
3. This provides flexibility to your design to have multiple subject classes publishing same event. In future if you have a new subject then you need not make any change to IClient.

Ofcourse this depends on your need.

Subject1 -----                                                             ---- Client1
Subject2 ----- ISubject------  Observer implements IObserver  --- IClient  ---- Client2
                                                                           ---- Client3

1. Observer maintains list of IClient and subscribes to Subject1, subject2... and so on.
2. Any of the subject can send the notification along with the state (subject) reference Observer goes through the list of IClient and notifies each of the client.
3. This is useful when same notification can occur from more than one subject. Example: Folder rename done using slow double click or press of F2 in windows context