Va bene avere una classe che abbia solo proprietà booleane?

Sì, assolutamente è una buona idea perché vogliamo che il compilatore controlli il più possibile. Se le opzioni fossero un elenco di stringhe, qualsiasi errore di digitazione non verrà rilevato fino al runtime.

Il test che puoi fare per vedere quale si adatta alle tue soluzioni è questo: se dovessi introdurre una nuova opzione domani è accettabile implementare una nuova versione con un nuovo codice o prevedi di effettuare la modifica tramite la configurazione.

Se il primo non ha svantaggi nell'uso di un gruppo di proprietà booleane.

Per rispondere direttamente alla tua domanda: sì, è possibile avere una classe con solo boolean s.

// C# example
public class VehicleOptions
{
  public boolean DriversSideAirbags { get; set; }
  public boolean PassengersSideAirbags { get; set; }
  public boolean FrontCurtainAirbags { get; set; }
  public boolean MiddleCurtainAirbags { get; set; }
  public boolean RearCurtainAirbags { get; set; }
  // Repeat until you run out of options
}

Ci sono altri modi per raggiungere il tuo obiettivo.

Se hai solo bisogno di Options come boolean se questa istanza di un veicolo ha un'opzione particolare, potrebbe essere più semplice avere un List<String> Options come un campo della tua classe. Se l'opzione è presente nell'elenco, l'istanza ha quell'opzione. Cercare l'elenco non dovrebbe essere difficile.

// C# example
public class Vehicle
{
  // If you require unique values for the Options field, 
  // change the declaration to:
  // public HashSet<String> Options
  public List<String> Options { get; }

  // Other stuff in the class...

  public boolean hasOption(string searchItem)
  {
    // Search the list for any element that contains the searchItem
    return this.Options.Contains(searchItem);
  }
}

Sospetto che caricherete le opzioni da un database, quindi l'utilizzo dell'elenco probabilmente corrisponderà più strettamente ai vostri dati. Inoltre, quando devi sostituire List<String> per un oggetto elenco più complesso (ad esempio List<OptionDetail> ), renderà più semplice la conversione. Tutto ciò che dovrai fare è cambiare la firma delle variabili associate (se non usi la parola chiave var per dichiararle).

Perché potresti scegliere un metodo rispetto a un altro dipenderà dai tuoi requisiti funzionali (aziendali), se ti piace costruire e distribuire una nuova versione della tua applicazione / sito web ogni volta che una nuova opzione viene rilasciata da un produttore , il tuo stile di codifica e quello del tuo team, se il tuo codice imita le strutture del database come oggetti, le istruzioni del tuo responsabile / responsabile del team o molti altri motivi.

A meno che un'opzione non sia solo un nome, puoi anche completare l'OO completo e creare un'interfaccia IOption (non conosco C # ma questo dovrebbe più o meno compilare):

interface IOption {
  String optionName();
  double optionPrice();
  List<IOption> exclusive(); //list of options that can't be selected with with this one
  //etc
}

Quindi ogni opzione implementa quell'interfaccia (e puoi aggiungerli come richiesto - anche al volo da un'interfaccia utente):

class AmazingSound implements IOption {
  //blabla
}

Allora avresti un elenco "nella tua auto.

Sul lato DB probabilmente avresti un tavolo auto, una tabella opzioni e una tabella con car_id, opzione_id per elencare l'opzione per quella specifica auto.