1

For hobby I'm making a game. The game has a monster chasing the human (Pacman-like). When the Pacman is stuck, can eat the human or does some move; an event should be raised. This is because my program became not-oop because all the objects had to know eachother what did the cohesion no good.

There is a control like object (called Game) which should respond to the event; human-moved, monster-moved, human-eaten, monster-stuck and eventually let the view know something happened so it repaints. Whats also the point, that the view responds to the keypresses of the actor and that those events should reach the human in some way (also with an event).

  1. Can someone help me with how I can best solve this issue? I've searched the internet for likewise problems but didn't came across one.

  2. In MVC: does the controller know the view? If so: does the whole program begins with the controller or with the view? (what makes who)

Andrew Marshall
  • 95,083
  • 20
  • 220
  • 214
guidsdo
  • 432
  • 2
  • 9

2 Answers2

1

Basically Event Handling mechanism is just a producer-consumer pattern, imagine you are producing some events(an action) and there are set of listeners who needs to be notified about your action.

whether you want to use to use the Java built-in event Handling depends on how much code you have already written, if refactoring your code to use the Java event Handling requires a lot of effort, and you have only limited set of events, then you can write your own message passing system. But obviously, using Java event handling mechanism should be preffered, since it takes cares of notifying all the listeners who are registered for that event, you dont need to worry about notifying each and every listener and later it will help you in debugging if anything goes wrong. I Hope it answers your first question

In short you can write your own events like HumanMovedEvent, MonsterMovedEvent etc.

Coming down to your 2nd question, yes in MVC, controller knows what all views it needs to trigger for any specific action. A controller can choose any specific view for any specific action, lets say if u do some action A, you can call view V.

and yes your program begins with sending a request from your UI to Controller. Controller then chooses what View it needs to render for that specific action.

I hope i made it clear :)

Rajesh Pantula
  • 10,061
  • 9
  • 43
  • 52
  • thanks about the MVC part :-) That helped me since some people I know believe that it's better the the Controller only keeps the model together and doesn't know the view. I was thinking of a custom event like; class GameEvent extends EventObject. With an ID which describes the event (using constants like; GameEvent.EntityMoved, HumanEaten, SnapperStuck etc). The only thing I still need to know is; how can the view (which catches the keyevents like arrowup) let the human know he must move up? – guidsdo Dec 21 '11 at 20:43
  • your idea of creating a class GameEvent and referring each event using Constants like ENtityMoved etc. is nice. coming down to your question, how your views will let the human know can be acheived in this manner. ArrowUpEvent--->Controller listen to the event and sends to view---->View generate another event---> human objects receives the event from view. – Rajesh Pantula Dec 21 '11 at 21:07
  • So you suggest that I should have another Custom event called MoveHuman (or also make it a constant in GameEvent) and let the human listen to it? But isn't everyone then leaning on the GameEvent class (as in; will this do the cohesion good)? thanks for your help and time in this question btw! – guidsdo Dec 21 '11 at 21:15
  • No, what i am suggesting is make another Custome event class MoveHuman(but dont make it a constant in GameEvent). rather your View will fire the event and Human will catch it. There will be 2 events in your application. 1st one will – Rajesh Pantula Dec 21 '11 at 21:24
  • No, what i am suggesting is make another Custome event class MoveHuman(but dont make it a constant in GameEvent). rather your View will fire the event and Human will catch it. There will be 2 events in your application. 1st events will be fired by you(like Up Arrow key pressed) which will be caught by your controller and it will update the specific view. the view will then decide and generate 2nd event which will b caught by Human,so in this way for ur differnt actions(ArrowUp,ArrowDown,etc) your controller will call different views and trigger the appropriate event and send it to HumanObj – Rajesh Pantula Dec 21 '11 at 21:30
  • @zondvloed to the event class it will just be another type of event, with no semantics attached. You could even construct the event class such that it does not know about which event types exist (by using strings as event types e.g.). The only ones who know about its meaning are the Human object, and the controller (because he needs to translate from key-presses to business domain events). So there are no cohesion problems. Succes met je programma! – fishinear Dec 22 '11 at 15:57
0

In MVC, the controller knows about both the model object and the view. The model object does not know who is controlling it, and likewise, the view does not know that either. Model and view typically communicated with the controller through callbacks: the model defines an interface for the various callback methods, and has a "delegate" instance variable holding a pointer to that interface. The controller sets itself as the delegate on the model. Likewise for the view. Instead of callbacks, you can also use events as you suggest, which would add an extra layer of decoupling:

  • the model can have multiple listeners to the events, not just the controller
  • if the controller also uses events to communicate with the model, then the controller does not need to know about the model at all, just about the events.

Typically you would have one model-view-controller combination for each object in your program (one monster model, monster view, and monster controller). But you can also have one controller managing multiple model objects and/or views. It depends a bit on the UI framework you are using which approach is most practical.

You second question also depends on the UI framework you are using. Typically, the controller instantiates the view, but some frameworks do it differently.

For the keyboad keys you mentions: typically the view would inform the controller of the key that is pressed "ctrl-K", and the controller would translate that into commands for the model object "move 1 space up".

fishinear
  • 6,101
  • 3
  • 36
  • 84
  • I'm using Swing for my GUI. A jpanel implements a keylistener. The only thing what I find hard in my program is how the view lets the Human know that he must move up. This is because the control (called game in my case) doesn't have a direct connection to the human (because the game has a playfield, what has cells, what can have an entity which can be a human) – guidsdo Dec 21 '11 at 21:56
  • In your case, I suggest that you (1) add the knowledge of which object is the humann to the controller. Either that, or one of these alternative might do: (2) give the Human its own controller and view and direct all keyboard input to that view, or (3) let the common controller convert the keyboard input into special events that only the Human object is registered to act on. – fishinear Dec 22 '11 at 15:45