Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Oberser pattern and MVC problem

Status
Not open for further replies.

Guest_imported

New member
Jan 1, 1970
0
0
0
Hello,

my question concerns Design Pattern, particulary observer pattern in Java.

I want to programme a board game called TWiXT. The subject of this game is not important, but the way how to implement is pretty decisive. GUI and application layer must be separated from each other. Data concerning the flow of the game must be hold in the application layer. Every view or presentation of data and also interaction takes place in the GUI.

In order to keep the GUI dumb the observer pattern could be applied. So far so good. For this I implement an interface that separates the GUI from the application layer. The GUI is allowed to communicate by this interface only.

What happens when a user does an interaction. The GUI uses the interface to send a message to the application layer. The application layer determines wheather this message changes the state of data. If it does, so the required change will be done. Hence it follows that the application layer must let the GUI know that data changed in order to make the GUI update the presentation of data.

Yeah, that's pretty lot so far, but the more precise the question is, the more precise is hopeful the answer. And here is the crucial question:

How can I let the GUI know what kind of change happened? If I define several states so that the GUI can query them in order to decide what to do, the GUI will have a portion of intelligence and thus know what's going on in the application layer. This is the crucial point: The GUI mustn't know so much about the application layer.

Do you have any bright idea? Are there "prefabricated" pattern solving this problem?

Any hint is higly appreciated.
THX in advance.

Yours

BinLadenKiller

P.S.: Hope I didn't make you confuse.
 
Well, the GUI is an observer - that is, it watches something, in particular it watches for changes in that something, and when it sees those changes, it does something. that is what an observer is.
so, you're asking how to implement this. it is done with the 'subscribe' idea, where the observer subscribes to certain aspects of the thing it is observing, and the thing makes a commitment to notify everything subscribed to watch an aspect of itself when that aspect changes. that is the only interface between the two.
i hope that answers your question, and i should note that there is ALOT of information on the observer pattern online - just do a google search on 'observer pattern' and you'll get a pile of useful stuff.

good luck "If you think you're too small to make a difference, try spending a night in a closed tent with a mosquito."
 
Hello stillflame,

first thx for your quick answer.

How to implement observer pattern is not the point. This works fine already. The problem is how to implement the update() method of the subscribed observers. Just performing all available methods in order to update presented data is not the way I want to do. I need a way to say precisely what kind of change happend without using states which can be queried by the observes.

Do I need a special change manager that is the observable? In this case the manager could specify the change. But this fails, 'cause the manager would just notify the subscribed observers. Gosh, I don't know where to start off.

Any hint, critic and correction is warmly welcome.

Yours
BinLadenKiller
 
well, lets say the GUI has its idea of what it is looking at - say a board and pieces on that board, implemented in pixels. now, it is subscribed to watch piece positions in the actual game engine, which it represents as which space on the board a piece is at. whenever those change, it does an update to itself to reflect its idea of where the pieces should be, in this case the particular location in pixels where a piece should be drawn. the GUI will have its own internal state of what it should look like, which it changes whenever it observes a change in the game engine. it already knows where it has drawn all the pieces, and when one of those pieces changes its location, the GUI redraws itself with that new location.

umm, i think the basic idea i was trying to say is that the GUI has its own internal state, which will change based on the things it observes in the game engine. is this what you're asking? "If you think you're too small to make a difference, try spending a night in a closed tent with a mosquito."
 
hello stillflame,

thank you that you spare no pains to catch what I try to say by my awkward presentation of my problem.

Generally you are right. This is a way to solve the problem. I do want to stress the point that's really important for me.

In your version the GUI would be a reflection of the state of data in the application layer. Surely, by defining the interface any GUI-Programmer could do his job as he wants to.

To concrete the problem: I want to programme the board game TWiXT. This game is for two players. The board has a matrix of 24x24 wholes where you can stick a peg. Each player tries to stick his peg in such a way that it can be connected to another peg by a brigde (called wall) when it is a knight's move away. In this way one player tries to build up a line from west to east and the other one from north to south. Thus out of a player's draw different amount of walls can be connected. This amount differs from none up to 8. This means that not only a single action results out of one draw. This variety must be sent to the GUI. Besides, the GUI must know which player's turn it is. If you play against the computer, the board (the GUI) must ignore any attempt of interaction. What I want to say is that there are many information to be sent to the GUI.

The GUI can't assume that an interaction just causes a draw of one player which must be queried and appropriately set on the board.

Dear Stillflame, I don't insist on to find a solution right to my presented problem. We are a team of 4 people. Two programme the GUI and the rest the game engine. The special task is to do it in a way where both teams can totally programme on their own. After having defined an proper interface each team can do their job.

As you can see I'm a little bit confused. Sticking on a certain method doesn't help. I want to find alternatives. But it seems that there are not so many. I've already read Gamma's book of design pattern. Every pattern is explained very well. But the transforming on a certain problem is not as easy as Mr. Gamma peresents it.

As I am a student of computer sciences, this task is mandatory for me.

Any hint is greatly appreciated.

Many thx in advance.

BinLadenKiller
 
I've only skimmed these questions and responses, but I would like to suggest a different approach. You are using the Observer interface and Observable class. These are great ways to implement an MVC architecture in a simple application. You have numerous things happened from one user action. This suggests a more robust architecture is in need. I would suggest looking into EventListeners and Events.

For instance, you have a cell on your board... it is manipulated in some way. It wants to send a message to other cells on the board (bare in mind I'm discussing the model only still). One way you could implement this is by firing custom events CellEvents and have other components register to listen via a EventListener mechanism. The cell would add and remove listeners for its events. When a certain action occurred it would fire an event and the listeners would take action to that event.

code:
Code:
public some_class {
  ...
  Vector listeners;
  ...
  public void some_method(arg) {
    ...
    fireStateChanged();
  }

  ...
  public synchronized void addListener(SomeListener l) {
    listeners.add(l);
  }
  ...
  //same for remove
  ...
  protected void fireStateChanged() {
    CustomEvent someEvent = new CustomEvent(args);

    for(int i = 0; i < listeners.size(); i++) {
      CustomerListener l = (CustomListener)listeners.elementAt(i);
      l.stateChanged(someEvent);
    }
  }
}

public interface CustomListener extends EventListener {
  //EventListener found in java.util package
  
  public abstract stateChanged(CustomEvent e);
  public abstract somethingHappened(CustomEvent e);
}

public class CustomEvent extends EventObject {
  //EventListener found in java.util package
}

This allows for a lot more customization and robustness.

Once you have a very robust model and it is fully functional the GUI follows easily. Just have your GUI classes implement the CustomListener interface and respond to the actions it cares about.

I'm currently using this architecture for my purely object-oriented MVC version of MineSweeper... working awesome so far... the model kicks ass... the gui is almost done and it was effortless to build... later. I hope this helped! ;-)
- Casey Winans
 
Hello Casey,

thanks a lot for your posting. All you talked about is fine and certainly a good and robust way to implement this task.

Unfortunately this kind of design pattern was presented by another group. Our prof had some arguments against this way of solving the problem. As separating GUI and application layer is the main goal of this project, the EventListener Model forces the GUI to know much about the app. layer.

Ok, what is much? Much is much as long as there is a way to reduce the GUI's knowlegde of the app. layer. Thus the GUI is always interchangeable by another as long as each GUI communicates with the app. layer by the defined interface. By doing so my headache increases, 'cause as I've already mentioned the state of change must be sent to the GUI somhow. But all you can do is just notifying the GUI by update().

Gradually I come to the point where I cope with the fact that every design pattern (observer, singleton etc.) is just an ideal. You can't manage to transform it to each problem without lowering your sights.

By now I think this problem is getting pretty abstract. I will do my best and implement it by observer pattern and informing the GUI what kind of change happened. In this manner the GUI must react somehow.

If someone is able to stop my resignation, I will be very grateful to him/her for telling it me.

THX all

BinLadenKiller
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top