How do I show classes of two different variants with two possible values in a class diagram?

Question

I have an entity Question (abstract) in my project. It can be asked in English or Russian. In addition, it can be asked by a student or a non-student. So,I'm looking for the perfect way to show it in my class diagram.

The only way I see, is to create four different classes (English-Student, English-NonStudent, NonEnglish-Student, NonEnglish-NonStudent). I guess, it will be the most efficient way to store them in different tables (different classes in class diagram).

What are the drawbacks of this approach? Would there be a better design?

Answer 1

Limitation of the current design

Your current design ignores the fact that questions share some common features and behaviors, regardless of who asks in which language:

• this introduces redundancy in the design and the implementation that will make maintenance less efficient and more error prone. Suppose for example that you want to add to the question some voting score like on StackOverflow: you would have to introduce your change in every variant of Question. If you would forget one of it in your revision, the code would break in some specific cases (usually the one that was not tested well).

• the design is not compliant with the open/closed principle: if you would add other languages, e.g. Ukrainian and French, your design would get broken and you'll have to add lots more classes and modify all the classes/code that use/work with questions.

How to improve?

First, does the language or the status of the author (student vs. non-student lead to any change in the behavior of the question?

If no, the simplest is to add a property language to the class Question. In the same spirit, you'd add an «enumeration» to identify the kind of author (unless the question is not already associated with an Author that provides similar information).

If there would indeed be different behaviors, or if depending on the combination, you'd need some additional properties, then you could use inheritance. But you'd quickly end-up in a very deep class hierarchy or multiple inheritance.

A better alternative could be to prefer composition over inheritance: typically using a strategy pattern for the language and the author category; although I could imagine that you should consider decorator pattern if a student question would for example bear more information than a non-student one.