Inheritance with Singleton Design Pattern

inheritancesingleton

I have come up with the following design for my requirement and want know if there is a better way to do it or if you have any feedback on the design.

Requirement

Assume that an app provides different add-ons and each of these add-ons have a licence. The user is given a license key and he can activate/deactivate the license key to use that add-on.

There is also a bundle license which provides the user with a single license key that can be used to activate/deactivate all the add-ons. But there can be only one bundle license in the app.

This will be implemented in PHP.

Design

This is the design that I have come up with.

class BaseLicense {
    protected $license_key;
    protected $addon_name;

    public abstract activate();
    public abstract deactivate();
    public abstract is_active();
}

class License extends BaseLicense {
    // Inherit abstract methods
}

class BundleLicense extends BaseLicense {
    // Inherit abstract methods

    // Singleton since there can be only one bundle license.
}

Best Answer

I think that the design is well oriented but I would sugggest the folowing:

Licences and add-ons are mapped via the $addon_name property but a matches(add_on_name) method should be added to the base class in order to know if a licence belongs to a given add-on, or better yet not pass the add-on name but the add-on itself so the matches method can do a more complex validation as to whether or not the license belongs to that add-on
Care should be taken in the BundleLicense to reduce the visibility of the inherited constructors so they cannot be used to instantiate. Since that could be tricky, a better solution would be that every parent class has their constructors private (I don't know if that can be enforced in PHP) and instead provide a getInstance() method. All non-singleton classes would return a new instance, but the singleton would return the same instance all the time. That way you don't hace to reduce the visibility of the superclasses' constructors, which I don't know if is possible in PHP.
A possible flaw is that BundleLicense seems to cover all add-ons, potentially giving access to add-ons it shouldn't give acces to. So I suggest classes to have a private list of add-on names intead of a single $addon_name property. Non bundle licenses would have a list containing a single add-on name, but bundle licenses will contain a list with two or more add-on names.

Related Solutions

Design Patterns – Alternatives to the Singleton Pattern

Your second option is a fine way to go -- it's a kind of dependency injection, which is the pattern used to share state across your program when you want to avoid singletons and global variables.

You can't get around the fact that something has to create your factory. If that something happens to be the application, so be it. The important point is that your factory shouldn't care what object created it, and the objects that receive the factory shouldn't depend on where the factory came from. Don't have your objects get a pointer to the application singleton and ask it for the factory; have your application create the factory and give it to those objects that will need it.

Scala Singleton Design – Null Values vs Empty Singleton for Optional Fields

I also attended the same Scala course and I agree with e-i-s that you should use the Option[T] type for implementing an optional field. Here are some more ideas.

The pattern involving

a trait with method isEmpty
several classes or objects extending the trait
a unique object whose method isEmpty always returns true

is also used to implement sequence-like immutable structures such as lists, streams, and so on.

Compare:

An Option[T] type containing the values Some(t), for each value t in T, and the additional value None.
A List[T] type containing objects built from two subclasses (and their respective constructors) Cons[T](h: T, t: List[T]) and Nil: these represent immutable lists whose elements have type T. Note that here the method Nil.isEmpty returns true.

None indicates the absence of a value, while Nil indicates an empty list.

So an optional value None is not the same as an empty list Nil.

NOTE

If you need to test if an optional value is defined or not you can use the isEmpty method of the Option type, or pattern matching:

class MyClass(f: Option[String])
{
  val field = f
}

and then, to test if the field of an instance obj of MyClass is defined:

if (obj.field.isEmpty)
{
}
else
{
}

obj.field match
{
  case Some(s) => /* do something with s */
  case None    => /* ... */
}

Best Answer

Related Solutions

Design Patterns – Alternatives to the Singleton Pattern

Scala Singleton Design – Null Values vs Empty Singleton for Optional Fields

Related Topic