Mediator pattern or facade or ...?

Question

I'm writing an app which tracks device location and based on some factors (user gets an assignment), it needs to change the location tracking settings (for example, frequency).

I have an issue with how to design this.

// I left out methods to start\stop tracking
interface ILocationTracker
{
    event EventHandler LocationChanged(Position pos);

    void UpdateTrackingSettings(TrackingSettings settings);
}

interface IUser
{
    event EventHandler AssignmentAdded(Assignment a);
}

I don't want to couple the IUser to the ILocationTracker, so I added this (I'm leaving fields out so it looks simpler to read):

class UpdateLocationTrackingSettings
{ 
     public UpdateLocationTrackingSettings(ILocationTracker tracker, IUser user)
     {
     }

     // I need to somehow start/stop it listening to AssignmendAdded event
     public void Start() {
          // Subscribe to IUser:AssignmentAdded
     }

     public void Stop() {
          // Unsubscribe from IUser:AssignmentAdded
     }

      void OnAssignmentAdded(Assignment a)
      {
          TrackingSettings settings = GetSettingsByAssignment(a); 
          _tracker.UpdateTrackingSettings(settings);
      }
}

The questions I have:

• How to 'start' the UpdateLocationTrackingSettings? Should I have a façade for the location tracking which contains ILocationTracking and UpdateLocationTrackingSettings and calls Start() on each?

• I feel like for GetSettingsByAssignment I should use use strategy pattern. I am thinking to implement something like ITrackingSettingProvider which computes and returns the tracking settings based on the assignment.

• Is this overthinking\over engineering?

• Any suggestions of a different or better design?

Answer 1

Is this overthinking\over engineering?

YES. It's too early for you to make this choice. If you have a clear idea, then go with it. If you don't, then just write some tests and make them pass with the simplest possible code. If a circular class dependency arises, then break it by introducing an interface. When the code gets repetitive or ugly, then refactor. At that point some design pattern may fit your need.