Which pattern use, Object with subtypes only differing properties

Question

I have a simple class Notification, which has a few properties (title, body, op) and only getters/setters. Among all my project I'll use different kind of notifications, this is Notification objects but with different title, body, op depending of the logic of that part.

I'm wondering what would be the best aproach to implement it. I've though of using some kind of polymorphism that would work but not sure if that would be overcoding. Here is the class Notification:

<?php

namespace App\Library\Notifications;

/**
 * Class Notification
 */
class Notification
{
    /** @var string $title*/
    private $title;
    /** @var string $body */
    private $body;
    /** @var string $op */
    private $op;

    /**
     * Constructor
     */
    public function __construct()
    {
        $this->title = '';
        $this->body = '';
        $this->op = '';
    }

    public function getTitle(): string
    {
        return $this->title;
    }

    public function getBody(): string
    {
        return $this->body;
    }

    /**
     * String that tells the apps which kind of notification
     * we are sending so they can act depending of the type
     *
     * @return string
     */
    public function getOp(): string
    {
        return $this->op;
    }

}

And here is a subclass:

<?php

namespace App\Library\Notifications;

use Illuminate\Support\Facades\Lang;

/**
 * Class Notification
 */
class OtherAcceptedTripNotification extends Notification
{
    /**
     * Constructor
     */
    public function __construct()
    {
        parent::__construct();

        $this->title = Lang::get('notifications.other_accepted_trip_title');
        $this->body = Lang::get('notifications.other_accepted_trip_body');
        $this->op = 'OA';
    }
}

Answer 1

This is abusing inheritance.

An inherited class is used when it changes something about the base class (but it retains some of the existing base class' logic).

In your example, nothing is changed except the value of the properties. You're not adding/changing any logical behavior.

This is effectively the same as doing (forgive the C# syntax):

public class Person()
{
    public string Name { get; set; }

    public Person(string name)
    {
        this.Name = name;
    }
}

public class John : Person
{
    public John() : base("John") {}
}

public class Bob : Person
{
    public Bob() : base("Bob") {}
}

public class Tom : Person
{
    public Tom() : base("Tom") {}
}

Or, even more blatantly:

public class MyNumberClass()
{
    public int Value { get; set; }

    public MyNumberClass(int value)
    {
        this.Value = value;
    }
}

public class Five : MyNumberClass
{
    public Five() : base(5) {}
}

public class Twenty : Person
{
    public Twenty() : base(20) {}
}

This is not what inheritance is used for! You should be using simple variables here:

var myAge = new MyNumberClass(20);

var myBoss = new Person("Bob");

var otherAcceptedTripNotification = new Notification ("title", "body", "op");

---

The factory pattern.

However, I do understand your intention here. You're trying to create a default preset, so you don't have to use hardcoded values. If you use the same OtherAcceptedTripNotification type across your codebase, you don't want to have to repeat yourself.

That is an actual problem that is worth solving. The factory pattern is a good solution here.

The linked reference (and other online resources) go into a lot of detail, and in my opinion a lot of complexity. To boil it down to the most barebones example to illustrate the point (again, forgive the C#):

public static class NotificationFactory
{
    public static Notification CreateOtherAcceptedTripNotification(string bodyText)
    {
        return new Notification(
                      "THIS HEADER CANNOT BE CHANGED",
                      "FIXED PREFIX : " + bodyText,
                      "FIXED OA"
                    );
    }
}

This gives you the benefit you want (only needing to define the fixed values of a notification "preset" once) without the drawback (inheritance abuse).

Answer 2

In this case you can either use a factory, or have a set of these created and accessed by name. My pseudo-code is not the same language you are using, but you can adapt the pattern.

public class Notification {
    internal Notification(string title, string body, string op) {
        Title = title;
        Body = body;
        Op = op;
    }

    public string Title { get; private set; }
    public string Body { get; private set; }
    public string Op { get; private set; }
}

public static class Notifications {
    public static Notification OtherAcceptedTrip = new Notification(
        Lang.Get("notifications.other_accepted_trip_title"),
        Lang::get("notifications.other_accepted_trip_body"),
        "OA");
}

At this point, you can use that notification any time you want just like this:

SendNotification( Notifications.OtherAcceptedTrip );

Essentially, you are controlling the instances of the notification. If you can't reuse the same instance everywhere because the Notification object is doing other things besides what you have listed here, you would use a factory. The factory will create an instance of the Notification object with the right values that you can use, and it won't be shared with anything else.