Consider the system sequence diagram for the use case "Interact with Character":

From this we learn that the use case has the following system events:

initiateConversation()
sendQuery()
acceptGameObject()
endConversation()

Below, we reason about some GRASP patterns in relation to these system events.

initiateConversation(theCharacter)

This event instructs the :Game that the player wishes to start a conversation with a specific character. The game checks whether the character is accessible (e.g. player has the phone number to the character, an address for text messages, or is at the same scene as the character, and then connects the player with the character using the appropriate CharacterInterface.

- Who is the information expert on which characters are available at a specific point in the game?

The current Scene keeps track of who is available in the scene, and the PhoneBook keeps track of whom the player knows how to contact. In addition a Character may themselves decide to be available or not based on conditions not known to the current Scene or the PhoneBook.

- Who is the controller for this use case?

I would use two controllers. First, Game is a controller to decide which use case that is currently active. Then, Game initiates a InteractWithCharacterController to deal with the rest of the use case.

(To explain further, which you need not do in your assignment, the flow is something like this:

User to their user interface: I'd like to talk to $CHARACTER
User Interface: Hey game:Game, initiateConversation($CHARACTER)
game:Game: Sure thing. Here is an InteractWithCharacterController for you.
User Interface: Thanks. Now let me create a new InteractWithCharacterWindow and connect it with the InteractWithCharacterController I just got.

)

- Who is the information expert on how one may interact with this particular character?

The InteractWithCharacterController was created by Game once it had found the character, either in the current Scene or in the PhoneBook. Thus Game knew how the interaction should be done, and gave this knowledge to the InteractWithCharacterController upon creation. So InteractWithCharacterController is now the information expert on this.

sendQuery(theQuery)

In this event the player sends a text query to the character that is currently active (as per the most recent initiateConversation event). The character parses the query, checks where in the game plot the player is, formats a response along with conversational avenues that the player can pursuit in their next sendQuery() call.

- Who is the information expert on how to process the query?

Rather than bloating the Character class with one more responsibility, I'm going to use Pure Fabrication and create a new class "InteractionParser" that tries to make sense of what the player has written. Let's assume that I get a nice data structure back that contains the gist of what the user wrote so that it can be used to create an answer. Somehow. With a little hand-waving.

- Who is the controller to format an answer?

The Character class could be responsible for this, but I could also create new classes for this. This may become arbitrarily complex in the future, but we may keep it in the Character class for now.

- Who is the information expert on who is the currently active character?

That would still be the InteractWithCharacterController. Game might have a pointer but there is no real need for that. If the user exits the interaction it is equivalent to hanging up the phone on them and if they wish to continue the conversation they can always redial.

acceptGameObject()

The response may include a GameObject that the character prepares (e.g. a pathology report, a note with the character's phone number, etc.) and offers to the player. In this event, the player accepts to take the object and it gets put into their inventory.

- Who is the information expert on what GameObjects a particular conversation may involve?

This may be one place where the interaction increases in complexity. If the Character is simple, it may be the information expert. With a more complex Character, it may be able to hold several conversations with the player throughout the game, with different behaviours and GameObjects. In this case, I would use a Strategy Pattern (Which is not a GRASP pattern) to model each Conversation as a separate class, and make them information experts on the GameObjects that are relevant to each piece of Conversation.

- Who is the creator of the GameObject?

This could be the Character or Conversation (there's no point in creating e.g. a pathology report GameObject until the player requests it), or it can be the GameInitFactory (Factory is another not-a-GRASP-design-pattern) that creates the GameObject when the game is first started.

- Who is the controller to make sure that the GameObject is delivered to the user (and put in their inventory)?

The following discussion is a generic reasoning about solutions. You do not need to be as elaborate as this in your assignments. I am doing this to show how you might try different solutions before deciding on one particular path forward, and to illustrate how different solution proposals will influence your design.

For this question, we run into a bit of a problem. Game of course knows about the Inventory. But it is the InteractWithCharacterController that ends up receiving the GameObject from the Character. And InteractWithCharacterController does not necessarily know about the game:Game object (to avoid creating circular dependencies). We have a couple of solutions to this.

- First, Game can send along the Inventory when creating the InteractWithCharacterController object. But this creates dangerous precedent for the next time Game should create a controller. What should be send along for the creation then? And, more importantly, in essence Game needs to know the innards of every controller it creates in order to pass along the right objects. Game thus becomes the information expert of everything, and this is of course bad.

- Second, we may pass along a pointer to the game:Game object. This is not so bad, is it? Except that we now need to do this for every new controller we want to create. It is at least a consistent programming pattern, but the danger is that we get tempted to throw all sorts of odds and ends into the Game class just because we know that it will be known throughout the entire system.

- Third, we can use a Singleton design pattern (also not a GRASP pattern) on the Game class. There should only ever be one instance of that class anyway. Right? Right? Except when we put the game engine on a server and want to allow for multiple concurrent players. then the Game class might have to be instantiated once for each player.

But should the Game class keep the Inventory in the first place? Isn't that the job of the Player class? This would give higher cohesion to both these classes. And with this, we may reach a more acceptable solution. The game:Game knows (or can be made to know) which player:Player is responsible for making that initial request to initiateConversation(), and it is highly relevant for the InteractWithCharacterController to know which Player wishes to interact with the character so that the right conversation context is loaded. Indeed, it is probably relevant for nearly every (use case) controller created by Game to know who the current user is. And this does not introduce any circular dependencies. We do run the risk of the Player class becoming the same "kitchen sink" as Game ran the risk of becoming before. But Player is a more specific class than Game, and through this class we can reach other classes that are relevant for this one player. For example, it might be a good idea for the Player to keep track of which Scene it is currently visiting, together with the Inventory and the PhoneBook.

So the answer is that InteractWithCharacterController is responsible to get the Inventory from its Player and to add the GameObject there.

endConversation()

This terminates the current conversation. When relevant, the character records into persistent storage that they have had the conversation (e.g. about a particular clue) with the player.

- Who is the controller to record the conversation into persistent storage?

The Character is responsible for making sure that relevant parts are recorded into persistent storage. Some characters may be "stateless" so there is no need to record anything, some characters may wish to record that they have answered a particular question, and some characters may wish to store everything the player has said to them so that they can (and will) use it against them at a later stage. Therefore, the information expert on what needs to be recorded is the Character, and so they also assume the role of controller to make sure it is stored.

- Who is the controller of the persistent storage?

The trick here is to recognise that the controller for what should be stored is not necessarily also the controller for deciding how to store it. I will again use my licence to invent stuff with the help of the GRASP pattern pure fabrication and create a class "StorageManager" (or StorageController, if you prefer), that will take care of all the nuts and bolts of storing stuff persistently.