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.

  • 1
    If lazy means simple, then lazy is good! Having a set of boolean properties on the Vehicle class sounds like exactly what you need. Given what you say, I don't see any reason to overcomplicate things by having a separate class for boolean properties or create arrays or some other special data structure for them.
    – JacquesB
    Apr 3, 2016 at 9:36
  • 1
    I agree with JacquesB; that a bunch of the properties are boolean isn't really a great reason to put them in their own class. However, if for some reason you do want these options grouped together, it's common to use a Flags enumeration for this purpose.
    – Brian
    Apr 3, 2016 at 9:37
  • I would put the options in their own class, because I suspect they won't be booleans forever, and I wouldn't want to change the Vehicle interface when it happens.
    – bigstones
    Apr 3, 2016 at 10:29

3 Answers 3


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.


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.

  • Does C# have a Set? If so, then that would most likely be faster than a List, at least for the uses here.
    – anon
    Apr 2, 2016 at 22:35
  • @QPaysTaxes, there is a near equivalent: HashSet Apr 3, 2016 at 3:13
  • Would it be faster to use that? I'm pretty sure it makes searching to see if it contains an element O(1) instead of O(n), as well as for adding. I'm not certain about that, though. The docs didn't say it anywhere that I saw.
    – anon
    Apr 3, 2016 at 3:17
  • I haven't used it much. You could look at the implementation code. Apr 3, 2016 at 3:33
  • 3
    Even ignoring efficiencies, HashSet better reflects the OP's intentions, as it (for example) disallows the same option to be set twice. However, it smacks of magic strings, so my preference is to avoid it unless it becomes necessary (which is admittedly likely, in the case of a vehicle catalog).
    – Brian
    Apr 3, 2016 at 9:42

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

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

class AmazingSound implements IOption {

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.

  • An Option is a name because the context is about secondhand cars, still +1 for an answer that one of my old teachers would have loved.
    – Vahx
    Apr 15, 2016 at 13:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.