Question

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)

Was it helpful?

Solution

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 :)

OTHER TIPS

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".

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top