Activity $1$: Use a Factory Pattern $(15$ pts$)$ Do the following: Add a $2$nd implementation of IVehicleInspector named AltVehicleInspection. To make this go quickly, simply clone VehicleInspection and change all of the hardcoded literal values you see to provide a different behavior compared to VehicleInspection. Refactor out the "new" in VehicleService by applying the Factory design pattern. Your factory implementation must be a public class named VehicleFactory with a private constructor and a method with signature: public static IVehicleInspector getVehicleInspector$($String prop$).$ Clone Main.java and VehicleService.java to AltMain.java and AltVehicleService.java. AltMain should read a system property $($passed in on the java command line via $-$D$)$ with key $"$vi$"$ and value of either "alt" or and pass that to the constructor of AltVehicleService $($which will have to be modified$).$ AltVehicleService in that constructor should ask the newly created VehicleFactory to produce an IVehicleInspector of type AltVehicleInspection if the vi property $=$ alt, and of type VehicleInspection for $($including null$).$ If you do this correctly, then the AltVehicleService::calculateTotal method does not have to change compared to VehicleService::calculateTotal Remember, complete this and mark your commit in your Readme! Note as well in this Activity none of the original code changes, I am asking you to create copies of classes and name them with a prefix of "Alt". Activity $2$: Refactor your Refactoring! $(15$ pts$)$ The Factory pattern solution in Activity $1$ to determine which inspector to use. This gets rid of the explicit $($compile$-$time$)$ coupling to a specific implementation, and doesn't make our client responsible for another object's lifecycle. But we still have an indirect dependency through the Factory. Dependency Injection allows an outside object to inject the implementation it depends on to provide a service. Your Activity $1$ solution couples the $2$ main methods $($in Main.java and AltMain.java$)$ to the type of VehicleService $($VehicleService and AltVehicle Service$).$ But if you look at the $2$ service implementations, they are only different in the way they get a reference to their Visitor $($an IVehicleInspector$).$ These service implementations carry no other state, and have the same method implementation $($calculateTotal$).$ Let's fix this by doing a simple for of DI$.$ Do the following: Create a new Vehicle Service called Act$2$VehicleService. This class should be$,$ as it says, a Singleton. Do this by applying proper code structure for a singleton $($specifically the nature of the constructor, and how a client object gets reference to the singleton through a static accessor function$).$ Instead of lazily populating the Singleton instance, employ a static initialization block that takes care of reading the system property $"$vi$"$ and injects it into the singleton instance it creates. Create a new main program in Act$2$Main.java that uses this new Singleton to get an access to the service so it can calculate the total $($minimal change$).$ If you did this correctly, you would notice that $1)$ we only have one Vehicle Service we need now $($please name this Act$2$VehicleService$),$ and $2)$ the client $($the main program$)$ does not need to help create the right service object nor does it need to help that object configure itself through a property. Remember, complete this and mark your commit in your Readme! Activity $3$: Use the Strategy pattern to vary the behavior of calculateTotal $(15$ pts$)$ We got away with combining the two services in the last activity because calculateTotal did not change, only the Visitor it used did based on what is injected into it via the static initialization block. But wh