Created a common interface for two security interfaces that may be used by a hypothetical agency. These key encryptions are called Ouroboros and Cerebus and they are used based on the security level of the message.

In our code, I used both the Strategy and the Observer patterns to meet the requirements as per the Module Interface Specifications. The purpose of the Strategy pattern is to allow the end-user to use different variants of an algorithm within an object and be able to switch from one algorithm to another during runtime. Thus, Strategy was implemented to satisfy the requirement of being able to simultaneously have a single “protocol” but use the appropriate level of encryption for each site (ex. Cerberus, Ouroboros). Strategy allows us to centralize all the encrypt/decrypt methods which is maintainable moving forward. This also implements the Open-Close principle of good design because the Protocol class is open for extension to many different types of encryptions, however the main encrypt/decrypt methods are closed for modification which ensures our software entities’ behaviour can be changed without the need to edit and recompile the code itself. The use of the Observer is generally when there is a 1 to many relationships between objects such as if one object is modified, its dependent objects are to be notified automatically. In our case, this is perfect to satisfy the need for all remote sites to be notified if the hypothetical agency desires to change their encryption. This is implemented using the Spectator class which has an update method to notify the respective sites that security needs to be updated. Lastly, my design uses encapsulation and the principle of high coupling and low cohesion in the form of grouping together three main classes (Protocol, Server, and Spectator) that are well developed and do not share unnecessary dependencies on each other.