This question relates to a question I asked earlier, which can be used for reference here: Is this the best way to approach this design? Is this an example of MVC?While coding, I came across a realization that I am not creating 'loose coupling'. The way I am trying to solve the problem right now is creating an instance of the Log Collector Class in MAIN and passing it around to each form classes constructor. Now, in theory, the Log Collector Class needs to be instantiated only once for the whole program run-time. I was thinking about using a Singleton Pattern for this class, but than thought that if two forms need to update this class at the same time, there would be an issue. What would be the best way to have the Log Collector Class be shared via multiple forms without instantiating a new version of the Log Collector Class each time?I've done some research before posting this question and have read some people say using a static class for this type of design. However, this doesn't seem like loose coupling to me.Another QuestionWould an Interface for the Log Collector Class be best used here for all forms wanting to communicate with it? For example:public interface LogCollectorInterface{    void SendLogMessage(string logMessage);}Now when all forms want to communicate with the Log Collector Class, this is the only function they really need to use, SendLogMessage. Would instantiating the interface rather than the Log Collector Class be the best way to go about it?FWIW, I am not sure if 'loose coupling' is the best direction is the way to go. It's one of those things I have caught on to while reading questions answered related to OOP. Being a new OOP programmer, it makes the most sense to me for both as an organizational standpoint and testing standpont.Edit:This will not be a multi-threading application so no two forms can update the log collector class at the same time.
Design: Sharing a class between multiple forms
design
While coding, I came across a realization that I am not creating 'loose coupling'. The way I am trying to solve the problem right now is creating an instance of the Log Collector Class in MAIN and passing it around to each form classes constructor.This is the best way to go.A singleton will work, but carries with it all sorts of risks as your application grows, especially if you intend to implement unit tests.The biggest problem with a singleton is it will be available to every single class in your application, not just the ones you've allowed access to it. And, as you'll see below, you can no longer segregate access to certain functionality by interface.but than thought that if two forms need to update this class at the same time, there would be an issue.This applies whether it's a Singleton or a single instance held by each form. But, if it's the form sending the message then, even in a multi-threaded application, this will all take place in the UI thread, so it isn't an issue.If there's any danger whatsoever then a simple lock() will solve the problem for you.Would an Interface for the Log Collector Class be best used here for all forms wanting to communicate with it?Yes. Definitely. Even if you extend your mediator later to receive multiple messages from each form, have multiple interfaces and hold the same object in each field.eg. (notice how a singleton isn't so attractive now?)public class FooForm : Form{    private ILogCollector _logCollector;    private IDataRequestor _dataRequestor;    public FooForm (FormMediator mediator)    {        _logCollector = mediator;        _dataRequestor = mediator;    }    // Stuff here}This way, if another form can only log exceptions and not request data, you needn't expose that functionality to the form.This is the I in SOLID: Interface Segregation Principle.