Sealed classes and interfaces

1

I have generally programmed to an interface. So naturally in a Kotlin library
of immutable data types the option type has an interface OptionIF defining
the protocols for this type, an abstract class OptionAB that implements most
of this behavior, and the two concrete classes None and Some that complete
the class hierarchy.

When Kotlin introduced sealed classes the opportunity was taken to recast the
option type to exploit how the when clause plays well with this feature. The
interface remained unchanged, the (abstract) sealed class Option replaces the
abstract class OptionAB, and the two concrete classes are nested within Option
(None is actually an object). The member functions can now exploit the when
clause with a default else clause.

So far, so good. However, if the interface includes a member function that has
a option type parameter then I would normally present this as a parameter of
type OptionIF. The eventual implementation of this function may use a when
clause against the parameter but it must include the default else clause.

Consequently I have now removed the interface, programming to the sealed class
Option. All functions with an option type parameter now use Option for its
type.

Does anyone see issues not using an interface? Have I missed anything?

2

An abstract base class counts as an “interface” in the Gang of Four reasoning, since it is not a proper, full implementation.
Also, since it’s a sealed hierarchy, you don’t have to worry about someone else trying to make an additional implementation that requires multiple inheritance.