Modeling combination of two independent abstractions

Question

I am building an app (.NET, but whatever) which is supposed to be able to send notifications to users.

Each Notification can either be a Reminder or a Newsletter, and I'll possibly add more types in the future. Each type is handled differently. Reminders are periodical, so I need to keep track of who is reminded of what, while newsletter is just broadcasted with each publish to all users.

Additionally, I can send notifications using any of several notification mediums or however you want to call those (Email, Push etc.). Those are modeled in the domain something like this:

public class Email
{
    public string Sender { get; set; }
    public string Recipient { get; set; } // email address on the user object
    public string Subject { get; set; }
    public string Body { get; set; }
}

public class Push
{
    public string Title { get; set; }
    public string Content { get; set; }
    public string DeviceId { get; set; } // some token on the user object
}

I'll most likely add more NotificationMedium types in the future as well.

So, each concrete notification can be of just one concrete NotificationType and can be sent via one or many NotificationMediums, with both evolving in variety independently.

I already have an IEmailSender and an IPushSender, both being implemented by concrete senders relying on specific third party services, and receiving one of those domain objects from above.

My first thought was to implement a Bridge Pattern, but I'm not really sure how that would work. I'm mostly insecure about how I'd unify Email, Push and other "mediums", since they do vary in detail (Push doesn't have a sender, and I don't want to make something rely on things it doesn't need).

I'm also pretty sure that each Notification must have its type stored in the database, maybe have some NotificationType table or even an enum. But this would mean that I'd have to have some way of converting a Notification to EmailNotification or PushNotification in the end, which would completely defeat the purpose of the Bridge Pattern.

What I'd like is to have a mechanism which recieves a Notification, handles it internally based on its NotificationType, and then send it off via one or more predefined NotificationMediums, which I could add or remove without needing to affect anything but the class that brings all of these concepts together.

P.S. The class that brings all of these concepts together will most probably be a CQRS Command Handler, since I'm already using MediatR in my project. I look at it as a kind of "composition root" for this use case, so I don't believe that changes anything in the big picture, but I though I'd state it just in case.

Any suggestions with this?

Answer 1

You don't need the bridge pattern. You only need a method for initializing the content / body and the title / subject of a NotificationMedium from a Notification. For this, you may provide Content and Title as abstract string properties in the base class Notification and override them accordingly in derived classes Reminder and Newsletter.

In NotificationMedium (as a base class of Push and Email), provide an abstract initialization method InitFromNotification(Notification n), and implement it like this:

In Email:

 void InitFromNotification(Notification n)
 {
      this.Subject = n.Title;
      this.Body = n.Content;
 }     
  

In Push:

 void InitFromNotification(Notification n)
 {
      this.Title = n.Title;
      this.Content = n.Content;
 }     

Now, your handler class can take arbitrary notifications media and fill and send them with arbitrary notfications generically

       medium.InitFromNotification(myNotification);
       // another abstract method, implemented differently in different media
       medium.InitReceiverInformation(...);
       medium.Send();

To your question about different the different requirements for different types of notifications: sending reminders regularly to individual users is one use case. Sending newsletters to all users once is a different one. So if that can be separated that strict, it is probably not necessary to generalize this into one command handler - you may choose to have an individual one for each use case.

However, if you have more notification types, or, for example, also newsletters which are send repeatedly, you could try to generalize this, give a Notification an attribute like RepetitionType with values OnlyOneTime or InIntervals, so allowing to decide if a newsletter will be send repeatedly as well. And if RepetitionType becomes a type of its own, and InIntervals becomes a derived class with certain parameters (like the interval size), then you have indeed introduced the bridge pattern here.

Answer 2

I might be wrong here, but it seem to me that you are trying to abstract something that is completely separate just because it has the same name. It is similar to the "product" problem - you have multiple departments and for each one, subscription means a different thing - sales cares about naming and price, warehouse care about how much they have in stock, etc.

You are talking about Newsletters and Reminders. Seems like these two are from different domains. One seems to lean on sales, the other one on customer support. We can define what Newsletter looks like and what Reminder looks like.

Newsletter has probably a date, title and content.

Reminder has probably a date, type, date due(?), recipient, title and content

These are two completely different things. One is intended to be sent out and forgotten, the other one is intended to reach a specific person.

Now that we defined each entity, we can move on to different mediums. You can have a generic EmailSender, which will send an email. You can also have a generic PushNotifier, which will send push notifications. What you then need is to have an adapter from Newsleter to Email and Push and an adapter from Reminder to Email and Push.

You could however invert this and have visitor pattern for each type of channel -> EmailSender.send(Newsletter)|send(Reminder) and PushNotifier.send(Newsletter)|send(Reminder). This however seems a bit odd, because both channels have to know about multiple domains...

I would go with first approach for this reason - keep the domains seperate and make an adapter from each type of notification to each type of channel.