CODEWITHSUNDEEP
design-patterns
silent-box
silent-box

Reputation: 1666

Design patterns: helper class in front of Factory

Say, I've got a NotificationServiceFactory class with getService(Enum notificationType) method.

But in most cases there is just notificationId as the input, without notificationType.

So, i have to invoke some sort of Helper class to retrieve Notification from database by id, than run getService(Enum notificationType) and finally invoke desired method on obtained service.

Pseudocode:

class NotificationController() {

    private NotificationServiceHelper helper;

    void processNotification(Long notificationId) {
        helper.processNotification(notificationId);
    }   
}

class NotificationServiceHelper() {

    private NotificationServiceFactory factory;
    private NotificationRepository repository;

    void processNotification(Long notificationId) {
        Notification notification = repository.find(notificationId);
        factory.getService(notification.getType()).processNotification(notification);
    }
}

What is this NotificationServiceHelper class? Facade? Adapter?

Is that a bad practice, or just a standard approach?

Upvotes: 1

Views: 1251

Answers (1)

mawalker
mawalker

Reputation: 2070

No This is not Facade nor is it Adapter. You are not [A facade is an object that provides a simplified interface to a larger body of code] from https://en.wikipedia.org/wiki/Facade_pattern nor are you (too lazy to look up wiki definition of Adapter, but... converting one API of a class to match a new desired API.

If anything this is actually closer to the Command Processor Pattern http://wiki.hsr.ch/APF/files/CommandProcessor.pdf

Where the 'notification' is the 'command' that you are 'processing'

You have:

1) a controller that accepts service requests (here your 'helper' but I would rename it to match pattern)

2) the idea of an 'abstract command' being 'a notification that uses some service'

3) a lookup to retrieve the notification(concrete command instance) from ...somewhere... via using the ID (just because all 'notifications' currently are the same class doesn't mean they don't have member data which identifies which service they should use (obviously they do with notification.getType())

SO you could easily make this...

'notificationController' (formerly the helper) (controller) this class actually builds the concrete commands and then passes them to the 'command processor' for 'processing' So this is where you would build your NotificationA and NotificationB class instances by passing in the notificationID and then using a factory to build the 'appropriate' class instance returned as a 'notification'

'command processor' (also sorta formerly the helper) but this class would actually invoke the commands. and (if you so desire, store a queue of past commands to enable an 'undo' functionality' (this has to be built into the commands too))

'abstract notification' (base class/interface for all notifications) (abstract command)

'concrete notification classes' for each notification type (command(s))

'services' (the 'supplier' in the paper's usage, but basically the unique code that operates upon a command stored inside the command itself, but invoked from the command processor on the 'command' )

This pattern is a bit complicated, and I'm probably not doing it justice at all right now, but rushed and thought it might help before I have to leave.

Upvotes: 1

Related Questions