looking for pattern

[Wizumwalt]

I'm looking for a pattern that is good practice that allows called
classes to make calls back to a main application class.

Here's an example ...

My MainAppClass calls JPanelClassA which implements a custom Listener
class (basically, swing forms that allow me to control what my 3d
canvas displays). This listener class must make a call on the MainClass
where all handles to other features are being held, but it doesn't have
a handle to the main class.

I make many modifications in swing classes that must pass data back up
or invoke data in the MainAppClass so that these changes can then be
propagated back down and into my OpenGL game loop.

Is there a good pattern for this?

 

[jan V]

It does sound as though your game isn't properly decomposed into the right
kind of classes.

You talk of your "main class" holding key data... that sounds wrong. There's
a well-known anti-pattern called the God class (a class which is bloated
with data and functionality), and from your brief description your main
class sounds like such a God class.

When I talk about a "main" class, I mean a class which starts my
application. It doesn't manage any application state. it's just a glorified
launcher. Typically it just instantiates "the system" and tells it to run,
or go.

In your case, you apparently need a GameWorld class which is the root class
linking to all the various game object classes. Your main class should
instantiate the singleton GameWorld object, and then tell it to start
living, or simulating.. thus breathing life into all the objects of your
game world. Object-orientation and games are a match made in heaven... if
applied properly. Think simulation...

Swing is based on the famous MVC pattern, Model - View - Controller. I
suggest you view your game in the same way: you need a model of your game
world, a view capable of visualizing that model, and some controller logic
to let the user interact between the two.

 

[Wizumwalt]

My main class basically does start my application, along w/ building
the GUI interface which is very complex. It does launch, and manage the
UI (i.e. change default Look and Feel's, delegates form input, drops
threads to read in initial model data, and passes data to my gameLoop
upon each input event). But it really doesn't manage my application
state. What does worry me is that it does have a very extensive
actionPerformed() and itemStateChanged() methods. But it has caused me
no problems *so far*.

In the MVC of things ...
My model is the CAD's data file that I read in and then adjust with
user added input from my swing forms, the view of course is a singleton
"game world" class that contains the game loop.

But it's the controller I'm looking to enhance and see if I can do
better. In other words, any changes made to the model (through the use
of swing forms) I want to immediately update in my view (the game
loop). And I'd like to do this without passing handles down to the
swing forms and then let the main class pass them to the game loop. So
the main class uses the event methods to act as the controller which
I'm not crazy about.

 

[Wizumwalt]

I was thinking maybe an Observer is the thing to do. So I thought
something like this ...

Create observer class
Create data classA
Create data classB
Attach data classes to observer class

And inside my swing forms, change data which notifies observer.
Observer passes changes onto game loop

But this doesn't seem to help much because I still have the same
problem, my MainAppClass would hold the observer handles (just as it
declares, init's, and defines my current data arrays now) and my
MainAppClass would still be passing the observers data classes into my
game loop.

 

[jan V]

I was thinking maybe an Observer is the thing to do. So I thought
something like this ...

But this doesn't seem to help much because I still have the same
problem, my MainAppClass would hold the observer handles (just as it
declares, init's, and defines my current data arrays now) and my
MainAppClass would still be passing the observers data classes into my
game loop.

What follows is not what you wanted to hear, but from everything that you
say, it really sounds (to me) that your game hasn't been designed around a
properly derived set of classes. When I write "classes", I mean classes
representing *fine-grained* concepts in your game, and in your architecture.

Let me have a stab at proving this by asking you how many classes and
interfaces you've got so far? And what does your statistical class size
distribution look like? I'm guessing that you've got way too few
classes/interfaces (let's say less than 30 for the whole program so far?),
and I'm guessing you've got a few mega-fat classes, say of more than 1500
lines of code each. Assuming these figures were in the right ballpark, I
would expect that same amount of code to be distributed across more like
100+ classes/interfaces, with the largest class not more than 500 LOCs (in
my experience the difference between a 500 LOC class and a 1500 LOC one is
not just 3x more complexity, but more like 10x).

Many years ago I once came across a really nice Java game which came with
source code... the game looked gorgeous and played brilliantly. The source
code was... wait for it... one (1) single class. The author had stuck to
procedural-era programming techniques. Java lets you do this, and
unfortunately many real-world Java programs are a bit of a mess when viewed
from a strict O-O perspective. My rule of thumb is: many small classes are
better than a few big classes. This rule of thumb doesn't, unfortunately,
answer your question as to what architecture is needed to get all the parts
talking in an efficient and elegant manner.. I guess this is where design
pattern knowledge comes in. But before you get to that stage, you need to
have your top-level abstractions fully worked out...