To implement a property or to implement a subclass

Question

I've got a class called List_Field that, as the name suggests, builds list input fields. These list input fields allow users to select a single item per list.

I want to be able to build list input fields that would allow users to select multiple items per list, so I have the following dilemma:

Should I do that through implementing a multiple_choice_allowed property into the existing List_Field property, or should I implement a Multiple_Choice_List_Field subclass of the List_Field class?

What's the engineering principle that I should follow when confronted with dilemmas like this one?

Pupa

.NET uses property approach itself. – Real

in html, you got your < select > single list and your < select multiple > list, seems to have worked out ok :) – Lutes

Answer 1

Take a look at the SOLID principles. They'll help you in your designs. In particular, the single responsibility principle will tell you not to mix the two concerns in one class, and the Liskov substitution principle will tell you not to create subclasses that break the contract of superclasses, like what you're also proposing.

So what would be the solution in your case? You could create an abstract base class that would be agnostic to the type of selection and then create 2 subclasses, one for single selection and another for multiple selection.

Aerator

That's an interesting suggestion. Is it that you generally avoid extending non-abstract classes or there's something specific in the class in question that makes it a good candidate for the abstract class approach? – Pupa

I generally try to avoid overriding concrete behaviors from a base class. It makes a class hierarchy harder to understand. – Fallal

+1 to Jordão for mentioning SRP/SOLID and linking to Uncle Bob – Coom

At sametime it is not follow the OCP (OCP The Open Closed Principle You should be able to extend a classes behavior, without modifying it.) Please correct if I am wrong. – Goethe

Answer 2

Depends on presence/lack of object evolution - if you want special case, sub-classing or injecting (DI) "select" behaviour (strategy) is good.

But if you also want to allow Field_List to change its behaviour dynamically, then property or mutating method is the only way to go.

Example: Sign-up screen with different "plans" - basic, where you can only select one thing and premium, where you can select as much as you want. Change of plan will switch between drop-down and multiple checkboxes, while still having the very same object including its contents.

I would vote for property/mutate method.

Hydrotropism

Answer 3

Personally I would go for the Multiple_Choice_List_Field way. I don't think there is a strict standard or an engineering principle that would make you to do it one way instead of another. The more important thing here is to choose one way to do it and follow it whenever you encounter such a dilemma. You should be consistent, but which way you go is your own choice.

I would choose the subclass because this way you won't have to bloat your List_Field class with additional checks and requirements. Of course there are other considerations such as if you need to switch the multiple choice and single choice at runtime it would be better to go for the boolean property (although subclass will work too, but doesn't feel natural to me).

The other thing is for List_Field you might need more than a single property to handle multiple choices, depending on your current implementation. For example a new property to return an array of the selected items.

Just do it the way it's most comfortable for you to build and maintain (and eventually extend).

Orethaorferd

-1 to Stormbreaker, this should really be down-marked, but U don't have the heart. No "engineering principle"s ? See the link above provided by Jordão – Coom

Yes, and there are a ton of those and half of them say exactly the opposite of what the other half say. – Orethaorferd

(My previous comment should have read "but I don't have the heart" not U). @stormbreaker, can you please refer me to a single principle that contradicts SRP, Liskov, etc? (I don't want to get into a flaming rubbish here but it'd be nice if you'd backup your sweeping statements with some proof) – Coom

Answer 4

Should I do that through implementing a multiple_choice_allowed property into the existing List_Field property

If you can do that, I think it's the best solution because this way you avoid class proliferation. If in doing that you are complicating too much your List_Field class, maybe create a derived class can have some benefits regarding the maintainability of your code.

Crosscut

Thats the thing - how do you know when a property complicates a class too much? – Pupa

it's quite subjective. For example if you need a lot of if statements in List_Field class to handle different selection methods, and while you are developing the code it increases for achieve that goal, maybe it's not the right approach . – Crosscut

Answer 5

Personally, I would say neither: instead use a constructor that takes multiple_choice_allowed, and then have a property exposing ListFields as a collection (with just one element when only one is allowed, all of them when more than one is allowed). Make it readonly (which means that you should copy it whenever you return the list).

Allelomorph