$2.$ Consider a change in requirements in the Registration lab work from previous weeks: each unit has a unit coordinator and the unit coordinator$$s details include: coordinator$$s name, room number, telephone number and email.

Reflect on the re$-$design you would need to do to cater for new requirements for the Registration codebase. How would you $$future$-$proof$$ your design so that any new code that you write will introduce additional functionality to cater for new requirements and not keep on modifying existing code? $($Open$-$Closed principle $)$ Note that in the past, you were given an example of what output the program should do$.$ What if the output format was changed? Would you have to go back and change existing classes? Note that formatting concerns are part of the $$View$$ in the Model$-$View$-$Controller pattern $($MVC$)$ discussed in the past. The data classes are part of the Model. Do not make the Model dependent on the View.

Ideally, to change the output format should only require a changed $$main program$($client code$)$ and not a change to the data classes. What about a change in the input format? For example, how would you cater for the input format shown at the end of the document? You will be using the first version of the input format for the rest of ict$283.$

You have a free hand in re$-$designing all the classes in the Registration codebase to attempt to future$-$proof them. Later, you will be learning from your successes and mistakes when you discover the amount of re$-$designing and coding that you must do to cater for expanded$/$changing requirements, if you do not design well and implement that chosen design carefully.