Question about use of Controllers

Question

I was given a Use Case for a Quizz Application. The Use Case is only for creating new Quizzes. I am having trouble deciding which design is better:

a)

b)

Although this might look like a Domain Model, it is in fact a Class Diagram (I was lazy to put the methods/attribtues in the diagrams :( ).

The idea behind all this is that I have a QuizCatalog that has Quizzes. Each Quiz has a set of Questions, that must be created through a QuestionFactory(a Question is an abstract class, and QuestionA, QuestionB, etc are the concrete classes). Each Question has a set of PossibleAnswers.

The difference in terms of associations between Design A and Design B is that in the first I am considereing that CreateQuizController will simply delegate every task it has to QuizCatalog. If QuizCatalog needs to do something, it will delegate everything it might need down the hierarchy. This is actually nice, as it seems to reduce coupling.

Design B, on the other hand, follows a different philosophy. The associations seen in Design A still exist (as a QuizCatalog still has Quizzes, a Question PossibleAnswers, etc) but now I've made CreateQuizController have access basically to every kind of object in the domain it might need to create in the process(I've signaled those kind of associations with d). The idea is that instead of asking the QuizCatalog to create a Quiz, CreateQuizController will create a Quiz by itself (and if it needs to create Questions for the Quiz, it will by itself, the same happening for Question's PossibleAnwsers, etc).

There are 2 things that bother me about Design A:

1.

If I need to create temporary objects that need to be filled up before being put "in the system" (for example, a Quiz is only actually added to QuizCatalog after it was filled with all the wanted Questions), following this design I'll have to keep them in some place other than the Controller.

For example, when I first create a Quiz, I'll have to probably save it under QuizCatalog without actually adding it to the current collection of Quizzes that is accessible to the rest of the system. I find this kind of behaviour a bit awkward. I find it better to keep those kind of temporary objects in a Controller, as if anything wrong happens then the "System" is kept just as it was before, with no problems associated.

The problem is that it makes the Controller have to know about almost everything, which might be undesirable. On the other hand, there is no difference in how coupled the rest of the classes in the System are.

2.

If I am going to use Design A, I actually don't see a big point in having a CreateQuizController, as basically everything can be done by just having a reference to QuizCatalog. In my eyes, it is just delegating all its work to QuizCatalog, so why have it in the first place?

Also, using Design A, I'd probably consider QuestionFactory to be a Singleton, while if using Design B I'd probably just have CreateQuizController's constructor accept an instance of a QuestionFactory instead.

---

What are your thoughts about this?

Thanks

PS: Only after drawing the diagrams I noticed that Quizz has 2 z's :( My bad.

Answer 1

Just from the naming I think, the CreateQuizController has too many responsibilities. I assume (again from its name), that it can create quizzes and control quizzes. What about separating this in two classes, a QuizFactory and a QuizController?

So if we need a new quiz, we ask the QuizFactory to create a new one, the QuizFactory would then create a new quiz, use the QuestionFactory to create questions and possible answers and we would add the new quiz to the (static) QuizCatalog.

If we want to run a quiz, we then would select a quiz from the catalog, create a QuizController (with this quiz), and the QuizController would start the quiz, present the questions and keep the score.

The QuizController wouldn't need to know the questions, it would be enough if the quiz offered methods like getNextQuestion() and getPreviousQuestion() and a method to validate the candidate's answer (so the controller would know the actual question only).

So a has-a relation from QuizController to Quiz would be enough. And in my design, the QuizCatalog would be (like) a singleton and thus static or owned by another top-level class, like some QuizManager.