Use of mediator design pattern with mailing list implementation

I have implemented the following scenario for the Mediator pattern sample:

MailingListMediator: Manages the subscription and send the mail back and forth.

• JavaMailingList

• SQLMailingList

(Colleagues)MailUsers: They can login, subscribe to the mailing list, send mails to mailing list.

• GmailUsers

• YahooUsers

My implementation looks like this:

MailingListMediator

public abstract class MailingListMediator {

    protected List mailingList;

    public MailingListMediator() {
        this.mailingList = new ArrayList();
    }

    public void sendMail(String message){
        for(MailUser mUser:mailingList){
            System.out.println("Mail message: '"+message+"' sent to "+ mUser.getMailId());
        }
    }
    public abstract String subscribe(MailUser mailUser);
}

MailUser

public abstract class MailUser {
    public abstract void login(String mailID);
    public abstract void sendMailToMailingList(MailingListMediator mailingList, String message);
    public abstract String getMailId();
}

GmailUser

public class GmailUser extends MailUser {
    String mailID;

    @Override
    public void login(String mailID) {
        this.mailID = mailID;
    }

    @Override
    public void sendMailToMailingList(MailingListMediator mailingList, String message)     {
        mailingList.sendMail(message);
    }

    @Override
    public String getMailId() {
        if(mailID != null){
            return mailID;
        }else{
            return "Login First";
        }    
    }
}

YahooUser

```
public class YahooUser extends MailUser {
String mailID;

@Override
public void login(String mailID) {
this.mailID = mailID;
}

@Override
public void sendMailToMailingList(MailingListMediator mailingList, String message) {
mailingList.sendMail(message);
}

@Override
public String getMailId() {
if(mailID != null){
return mailID;
}else{

I am not familiar with the Mediator pattern, but I think your code is not complex enough to make good use of the pattern. Take your JavaMailingList and SQLMailingList, what is the difference between those classes ? The value of mailingListId. The implementation of subscribe is exactly the same, you add the same variable to the class. If your MailingListMediator would look like :

public class MailingListMediator {
    private final String mailingListId;
    protected List mailingList;

    public MailingListMediator(String mailingListId) {
        this.mailingList = new ArrayList();
        this.mailingListId = mailingListId;
    }

    public void sendMail(String message){
        for(MailUser mUser:mailingList){
            System.out.println("Mail message: '"+message+"' sent to "+ mUser.getMailId());
        }
    }
    public String subscribe(MailUser mailUser) {
        mailingList.add(mailUser);
        return mailingListId;
    }
}

There is suddenly no need for JavaMailingList and SQLMailingList.

The same principle apply to YahooUser and GmailUser. Those classes are almost a copy-paste of each other. Same implementation for all the methods and adding the same variable to the class. Why is mailID an attribute in the children classes but not in MailUser? I could repeat the same process that I used for MailingListMediator and I could remove YahooUser and GmailUser.

My conclusion is your code looks like trying to be complicated when in fact it is not. You want to try the Mediator pattern ? Well wait when you will need it, do not force your code into a pattern. Pattern will be useful when you need it, otherwise it will only make your code less readable and harder to maintain.

Since you wanted to implement the Mediator pattern, I will expand more on that part. You do have a mediator pattern implemented. Your "colleagues" do interact between each other through the mediator that is the MailingList. There isn't a MailUser that interact directly with each other, that is the main point of the mediator pattern. Do know that your example is a little weak. I would suggest you, if you really want to test the mediator pattern, try a to code a chat application. This could be a good exercise since you will have a lot of users that will need to communicate, but you don't want the class to be tightly coupled.

StackExchange Code Review Q#54129, answer score: 2