Landing : Athabascau University

Taking a Peek at Observer Patterns

  • Public
By Tyler Lucas in the group COMP268 July 15, 2017 - 5:40pm
Taking a Peek at Observer Patterns

Java loves the Observer pattern. This is a software design pattern where an object is notified of a change in another object instead of having to periodically check for it, sometimes using another mediator object to act like a telephone switchbank, making sure the right messages go the the right places in the correct formats. There's a lot to it, and I don't know the half of it, so I'll just talk about the wee bit I've used in a recent textbook examples.

The text introduces "Events and Listeners" in 6.1.3, using the interface ActionListener as its first example. In doing just a few examples one learns many things, one of which bugged me enough to lead to this subject exposé: telling different objects who to inform when an event happens to them and telling other objects who to look at for an event is a pain in the ass. You invariably end up hacking in a way to pass and store references to various objects in other objects, or moving up and down the hierarchy of objects in order to setup the event handling framework.

For example, for a JPanel sub-display inside of the content JPanel to pass a message to a JLabel in the menu bar, something has to pass the JPanel sub-display object reference to that JLabel. What is going to do that? The JFrame handler, which has access to both the menu bar and content panel? It has to dive deeper, going into the content JPanel to get the sub-display JPanel reference, and going into the JMenuBar, from there into the JMenu, and maybe there it can find the JLabel in question. Maybe the JPanel sub-display itself? It has to climb the hiearchy through its parent JPanel to the JFrame, then down to the JMenuBar and JMenu to finally get to the JLabel. Same deal for the reverse. All of this reeks of implementation dependency -- anti-OOP.

One solution is to have one all-seeing, all-knowing object mediate the flow of messages. (I called mine "Seer".) Any object that needs to tell others that it has changed just tells this mediator and it makes sure the message gets passed correctly. Likewise, any object that needs to receive an update can ask the mediator, and it will collect the information for it. Depending on the details of how you implement it and what type of software it's for, this can be called a "mediator pattern", "publish–subscribe" pattern, "message-oriented middleware", "implicit invocation", other terms that can be catagorized under one of the former, and probably a bunch of others I didn't come across.

Another solution was already explored (I called it "anti-OOP"). It works. Java AWT and Swing both (and probably JavaFX, Pivot, and SwingX as well) include methods to climb up and down their object hiearchies, and a developer can do it in ways that will work for various implementations. It's kinda hard. I resorted to using java.lang.Class (object.class.getThisOrThat("withThisName")) a few times.

Anyway, researching observer patterns led to an information overload, so I decided that the best way to figure out what was what was to try a few patterns out, see how they worked and how I felt about them. Enter the textbook example for Conway's Game of Life, section 7.5.2 and pp. 366-370. I didn't actually look at Eck's implementation, but dove right into it myself. I called it "Conway's Game of Life... Now With More Life!"

 

Conway's Game of Life ("CGoL") consists of a grid of cells that either stay alive, stay dead, die, or come back to life based on some simple rules about the state of their neighbours. The overall pattern looks like a time-lapse view of a petri-dish, with colonies of microbes coming to life and dieing inside of a fixed area, hence the term "...Life" in the title. It's more of a mathmatical model than a game, as the computer plays all the parts, and has been the subject of [light-hearted] study for decades.

I used an all-seeing, all-knowing mediator object (a class I called "Seer"), labeled "enki" (a Sumerian 'Lord of the Earth'), and available to all; as well as a the other option, each observer or observable object climbing up and down their object heiarchies to find their complimentary observables or observers. "enki" was in charge of passing messages to and from the JMenuBar and its parts, and between different levels of the content, as that was much easier than following the hiearchy trails we've gone over. The other approach was used with the individual cells: the ones that lived and died according to their neighbours. "enki" may be a Sumerian god, but even he could not be bothered with the large number of events and messages being passed between each cell and its neighbours. Better to have them communicate directly between themselves! The individual cells are already being instantiated and setup by a "Grid" object, so it may as well tell every one of them which other cells (class "Cell") are its neighbours. After that, they are on their own. They don't need the Grid, content JPanel, window JFrame, or even all-seeing "enki" to do their thing -- they communicate directly with their neighbours and respond appropriately, just like you'd imagine a living organism would do. This screams OOP, which, to me, means that we're on the right track.

The bit of my title "... now with more life!" comes from an implementation tweak that sets it apart from the many others: each individual Cell responds to their neighbour states at different rates, essentially making them all unique in what you might consider "environmental hardiness".

Take a look at the code here: https://goo.gl/yB6xHR (GitHub link)

I packaged a JAR file which, if you have a standard JSE 1.8+ installation (PATH set correctly), should run with a double-click: http://tyblu.ca/misc/COMP268/GameOfLife.jar (you will undoubtedly get a warning when downloading as JAR files can be viruses... this one isn't)

Conway's Game of Life ... now with more Life! screenshot

Comments

These comments are moderated. Your comment will not be visible unless accepted by the content owner.

Only simple HTML formatting is allowed and any hyperlinks will be stripped away. If you need to include a URL then please simply type it so that users can copy and paste it if needed.

(Required)

(Required)


COMP268

COMP268

COMP268 - Introduction to Computer Programming (Java)