Is it ok to have a class that only has boolean properties?

Question

Scenario
We have a class Vehicle, this class contains some properties to define the object such as a CarBrand, TransmissionType, Color, etc..

A car (vehicle) also has options, these days a lot of options.
My idea is to create a separate class called Options and list the needed options that I require as a Boolean value, then use true or false to determine if the vehicle has that option or not.

Would this be considered a good idea or a lazy idea? Should I even bother making a separate class for this or should I simply put all this info in the vehicle class. Not just from a design point of view but also looking at the database to store this information.
There is no intention of making the vehicle class a base class for multiple other classes.

My alternative would simply be an array of string value's. This would be less restrictive when it come to adding in new options and maybe even better in terms of data usage in a database (I think).

• Booleans: every option will need a true or a false value.
• Strings: there will be something or there will be nothing at all to store.

Ideas besides the 2 that I posted are also welcome.

Answer 1

Yes absolutely it is a good idea because we want the compiler to check as much as possible. If the options were a list of strings any mistypings would not be discovered until runtime.

The test you can do to see which fits your solutions is this: If you were to introduce a new option tomorrow is it acceptable to deploy a new version with new code or do you expect to make the change via configuration.

If the former there is no downside to using a bunch of boolean properties.

Answer 2

To directly answer your question: yes, it is possible to have a class with only booleans.

// 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
}

There are other ways to accomplish your goal.

If you only need Options as a boolean for if this instance of a vehicle has a particular option, it might be easier to have a List<String> Options as a field on your class. If the option is in the list, then the instance has that option. Searching the list shouldn't be difficult.

// 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);
  }
}

I suspect you will be loading the options from a database, so using the list will probably match your data more closely. Also, when you need to swap out the List<String> for a more complex list object (e.g., List<OptionDetail>), it will make the conversion easier. All you will have to do is change the signature of the associated variables (if you don't use the var keyword to declare them).

Why might you choose one method over another is going to depend on your functional (business) requirements, if you like building and deploying a new version of your application/web site every time a new option is released by a manufacturer, your coding style and that of your team, whether your code mimics the database structures as objects, instructions from your team lead/manager, or lots of other reasons.

Answer 3

Unless an option is only a name, you could also go full OO and create an IOption interface (I don't know C# but this should more or less compile):

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

Then each option implements that interface (and you can add them as required - including on the fly from a UI):

class AmazingSound implements IOption {
  //blabla
}

Then you would have a List` in your car.

On the DB side you would probably have a car table, an option table and a table with car_id, option_id to list the option for that specific car.