Sealed classes - would you want them in D?

[Piotr Mitana]

On Friday, 11 May 2018 at 23:28:48 UTC, Jonathan M Davis wrote:
> Except that if I understand correctly, what the OP wants is to 
> have the class be publicly available while restricting who's 
> allowed to derive from it, with the idea that a particular 
> class hierarchy would have a well-defined set of classes that 
> the person who wrote them had full control over rather than 
> allowing anyone and everyone to derive from any class in the 
> hierarchy except for any final classes at the leaves of the 
> hierarchy.

Exactly that is the point.

I'll give you an example from an app I've started working on:

I developed a little CQRS library. The structure of classes is 
based on the Entity type - an entity is a piece of data that is 
sent between a client and a server. Client/server that has 
received the entity, detects the right Handler class for the 
given entity class and triggers it. Handler for some entity types 
will generate other entities, which will be sent to their 
handlers respectively or sent back over the network to be handled 
remotely.

There are four types of entitites: Commands, Queries, Responses 
and Events.

The most typical patterns are:
- Client sends a command to the server. Server uses a 
CommandHandler to generate resulting Events and EventHandlers to 
take actions corresponding to them. Eventually it may acknowledge 
the client that the command has been successfully processed, but 
without any data in response.
- Client sends a Query. The server processes it in QueryHandler, 
which generates a Response that is sent back. Client uses its 
ResponseHandler to take actions corresponding to the response, 
such as presenting the results in the UI.

Class-wise, we have:
- abstract class Entity,
- abstract classes Command, Event, Query and Response, each of 
them extends Entity,
- a number of concrete classes being the particular Commands, 
Events, Queries and Responses.

Now what I want to achieve is prevent library user to extend the 
Entity class. There are four classes inheriting the Entity class 
and the entire concept is built around these four. Library's 
internal code is also constructed to support only these four 
entity types, which make the concept complete and non-extendable 
by design. Currently user is able to create a fifth type of 
Entity, but the library will not - and is not meant to - support 
it in any other way then throwing an exception.

If I made the Entity class private as Walter suggested, I could 
not create a method to transfer any entity type via network or 
couldn't create for example a log method that accepts Entity as a 
parameter (Yes, there is a Variant and Algebraic, but I don't 
think that it is the right use for them). What I want to have is 
an entity class visible everywhere, but extendable only inside my 
library. At the same time I want users to be able to freely 
extend the Command, Event, Query and Response classes, as this is 
exactly what the concept is about.