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.
