Duplicate code and redundant design is a common occurrence. Although sometimes it is the result of bad design, many times duplication and redundancy creeps into code that has been developed over a period of time. Abstraction is an effective way to tackle duplication in design and code.

Many online questionnaire tools like SurveyMonkey, Doodle Poll, etc. $($even Canvas$)$ allow creating a questionnaire made of several types of questions: Yes$/$No$,$ Short$-$answer, Likert scale, etc. The provided starter code contains a design and implementation of some question types.

Each question, irrespective of type, supports some operations. These operations are listed in the Question interface.

The YesNoQuestion class represents a yes$/$no type question. It imposes the following specific constraints:

The text of the question cannot be empty, and must end with a question mark.

This question can be answered in one of two ways: yes or no$.$ The case does not matter.

The LikertQuestion class represents a $5-$scale Likert question. It imposes the following specific constraints:

The text of the question cannot be empty, although it need not end with a question mark.

This question can be answered in one of five ways: "Strongly agree", "Agree", "Neither agree nor disagree", "Disagree" and "Strongly disagree". The case does not matter.

As the story goes, the YesNoQuestion class was implemented first. Then a second developer wrote the LikertQuestion class by "drawing inspiration" from the first $($note the similarity in the methods and tests$).$ As a result the provided code $($including tests$)$ have the following undesirable properties:

They seem to have redundant and$/$or duplicate code.

The fields are not appropriately guarded against side$-$effects or inappropriate access.

Although the interface is well$-$documented, the documentation of the implementations is rather scant.

Much like the second developer, if more types of questions were to be implemented they would likely inherit the same undesirable properties as the above.

Your aim in this lab is to refactor $($change the implementations without changing what they do$,$ or how other classes view their public offerings$)$ the provided code. Use abstraction mechanisms such as inheritance, abstract classes and methods, etc. as necessary to minimize duplication of code. Tighten the access and usage of fields as appropriate. Lastly write appropriate Javadoc$-$style documentation for all the implementations.

Note that the provided tests suffer from similar duplication as the code they test. The same ideas of abstraction apply to tests as well! For example, one may write an abstract test class and concrete classes that extend it$.$ Only the concrete test classes can be run.

Implement a new type of question: multiple$-$choice. It must take in the possible answers, and the valid answers should be numbers starting from $1.$ Try to fit the resulting MultipleChoiceQuestion class into your improved design. Don't forget to write tests for it$!$