Le classi astratte devono essere utilizzate per impedire l'istanziazione

Solitamente le classi Abstract vengono utilizzate quando una ha una classe che ha alcuni metodi che devono essere implementati da una delle sue classi figlie, quindi, quando si vede una classe astratta si prevede anche di vedere una serie di metodi astratti che deve essere implementato.

Quindi, anche se puoi usare classi astratte per denotare classi non istantanee, non penso che se vuoi impedire alle persone di creare un'istanza della tua classe, questa sarebbe la strada da percorrere.

Un'altra cosa che potresti fare, se vuoi impedire l'istanziazione, sarebbe dichiarare il costruttore della classe genitrice come protected . In questo modo, non sarà visibile a classi esterne diverse da quelle che lo estendono:

public class Gauge
{
    ...

    protected Gauge(...)
    {
        ...
    }

    ...
}

public class HeadingIndicator extends Gauge 
{
    ...

    public HeadingIndicator(...)
    {
        super(...);
    }

    ...
}

public class AirSpeedIndicator extends Gauge 
{
    ...

    public AirSpeedIndicator(...)
    {
        super(...);
    }

    ...
}

In questo modo, i mezzi per creare istanze della classe Gauge sono limitati solo alle classi estendenti.

Dipende dal motivo per cui vuoi impedire l'istanziazione.

Se vuoi avere il controllo sulle istanze, ad es. il modello singleton quindi nascondere / incapsulare il costruttore.

Se la classe è una generalizzazione che in sé non potrebbe mai essere un'istanza, allora ha più senso che sia una classe astratta.

Ti stai già ponendo la domanda giusta: un indicatore di nessun tipo specifico è utile a nessuno? Che cosa misura? Quali unità utilizza? Come hai già notato, non lo è.

Quindi chiaramente un misuratore non è qualcosa che deve essere istanziato stesso. Ciò significa che un indicatore dovrebbe probabilmente essere una classe astratta o un'interfaccia. Solitamente preferisco creare le interfacce di classe e, se necessario, fornire un'implementazione astratta di classe di tale interfaccia se devo fornire un'implementazione predefinita di alcuni comportamenti comuni.

Una cosa che dovresti considerare, comunque, è se un calibro dovrebbe essere o meno un tipo e che tutto si riduce a ciò che stai facendo specificamente. Un sacco di 'calibri' non fanno nulla di comune a tutti i calibri. Se questo è il caso, considera di allentare un po 'il tuo modello e magari nemmeno di avere un'interfaccia di gauge. Lascia che HeadingIndicator e AirspeedIndicator siano le loro classi separate, non correlate. O forse ti piacerebbe un modo uniforme per visualizzare questi indicatori e vuoi un'interfaccia con metodi come Unit units() , String labe() e double measurement() .

Credo che il tldr; ecco che se sembra difficile / imbarazzante astrarre queste due entità in un genitore astratto, forse quell'astrazione non è necessaria e può essere saltata. Stai per scrivere un codice che si applica a tutti gli indicatori? In caso contrario, salta l'interfaccia genitore / classe astratta. È abbastanza facile estrarre un'interfaccia in seguito per il codice che necessiterà dell'interfaccia.

Dal mio punto di vista, sì lo è.

L'unica domanda è, vuoi una classe o un'interfaccia è sufficiente?

Quindi la domanda sarà: hai un comportamento comune (implementazione del metodo) tra classi figlie, quindi hai bisogno di una classe astratta comune, o solo di una dichiarazione di metodo (in questo caso, usa meglio un'interfaccia)?

D.

Una classe astratta significa che alcune parti della sua implementazione potrebbero mancare. IMHO, il fatto che un Gauge possa essere inutile da solo è la tua opinione, non l'opinione di tutti gli utenti della tua API.

Vorrei dichiarare tale abstract di classe solo se mancava di metodi importanti, ma mai come mezzo per impedire all'utente di creare un'istanza di tale oggetto.

In primo luogo, vorrei scrivere della documentazione su quella specifica classe e perché non dovrebbe essere usata così com'è. Poi mi chiederei se voglio davvero impedire a chiunque di usare quell'oggetto, e perché (perché non è chiaramente definito nel tuo caso).

E l'ultimo passo sarebbe utilizzare un costruttore speciale o rendere astratta la classe (ma questo è qualcosa che non farei ancora perché sembra che l'API e gli oggetti siano mal progettati).