Final Project with Design Patterns, ie Creational and Structural etc.
- Abstract Factory. The use of this is for the construction of the portfolios. The portfolios are suited to the Abstract factory since essentially this is creating families of related objects. Thus the two Advanced Portfolios (Summit, & Ascent) are part of the Portfolio family as is the Expedition Portfolio that sits under the Starter Portfolio interface. One of the other reasons for using the Abstract factory is it can readily be used with Facade to provide an interface for creating subsytem objects in a subsystem-independent way.
- Singleton. The use of this creational pattern is directly related to the role of the LeadPortfolioManager. As this staff member has the ultimate responsibility for the notification process (to be described later in the Observer pattern) I have utilised this creation pattern in order to have that notification class rest only with the LeadPortfolioManager.
- Observer pattern. This pattern essentially was an easy one in the fact that this is centred around the notification that happens when an investor withdraws from an investment, as a first step, and then the waitlisted individuals who have not had access to those portfolios. With this pattern we are interested in the state of an object, and in this project both LeadPortfolioManager is to be notified, and also investor needs notification.
- Strategy pattern. This pattern is suggested since it allows us to split all the portfolios into their own classes and have each of them implement the same method. Then when it comes to picking a portfolio all you do is run 2 methods, get investments and get method. This pattern adds some logic to the particular program we are building.
- Facade pattern. I have chosen this pattern due to its flexibility and interchangeability with both Singleton and Abstract Factory. This projects has a complex subsystem of the various investment holdings that make up various portfolios, and the network of the types of clients and their risk profiles that have interconnectivity, the facade pattern assists in simplifying this.This pattern will be applied as it relates to the selection of the portfolios relative to each client related to their risk profile, and how much they have to invest. I created a class that simplifies the interface for interacting with the complex
SatelliteInvestmentsandBuildPortfolioclasses. This class will provide higher-level methods that clients can use without needing to understand the complexities of the underlying classes. Clients can instantiate anInvestmentFacadeobject and use its methods without needing to understand the underlying implementations. - Decorator pattern. This is open to extension, and closed to modification, when you wrap a class within another class. In the case of this project again this focuses on the notification system, and will allow some variability. In my practice and generally in financial advice it is often that you are dealing with clients in their 20's as well as some in their 80's. Clearly they may have different notification methods, and traditionally an older client may prefer the proactive phone call, whereas a younger client may want a text. This pattern will allow me to expand on the system in order to have different offerings for each type of notification. What I have built has allowed for different decorators to be stacked on top of each other. For instance if you would like an urgent Notification and a VideoLink Notification then you can return that with a combination of the various decorators offered, and can even extend them.