A globally accessible object

The first requirement makes the messaging system an excellent candidate for a singleton object, since we would only ever need one instance of the system. Although, it is wise to think long and hard as to whether this is truly the case before committing to implementing a singleton.

If we later decide that we want multiple instances of this object to exist, wish to allow the systems to be created/destroyed during runtime, or even wish to create test cases that allow us to fake or create/destroy them in the middle of a test, then it can be a difficult task to refactor a singleton out of our code base. This is due to all of the dependencies we will gradually introduce to our code as we use the system more and more.

If we wish to avoid singletons due to the above drawbacks, then it may be easier to create a single instance of the messaging system during initialization and then pass it around from subsystem to subsystem as needed, or we might wish to go further and explore the concept of dependency injection, which attempts to solve problems like these. However, for the sake of simplicity, we will assume that a singleton fits our needs and design our MessagingSystem class accordingly.