This is an interesting “principle” but essential question:
A- The pattern!!
MPV: Model View Presenter is the two way of
MVC Model View Controller; where Presenter is the middle-man, the mediator between Model and View know and get notificated by both Model and View.
worth to note:
even some part of JME3 assemble MPV, it’s not the whole!
also for a game, apply MPV is quite annoying and also tricky!
Talk about MVC first: Assume you know about web
from Wikipedia Web framework - Wikipedia
Push-based vs. pull-based
Most MVC frameworks follow a push-based architecture also called “action-based”. These frameworks use actions that do the required processing, and then “push” the data to the view layer to render the results.[5] Struts, Django, Ruby on Rails, Symfony, Yii, Spring MVC, Stripes, Play, CodeIgniter, and Struts2[6] are good examples of this architecture. An alternative to this is pull-based architecture, sometimes also called “component-based”. These frameworks start with the view layer, which can then “pull” results from multiple controllers as needed. In this architecture, multiple controllers can be involved with a single view. Lift, Tapestry, JBoss Seam, JavaServer Faces, and Wicket are examples of pull-based architectures.
MVC Push was born in the world of “none frequent” and not suite well for kind of application almost done update every-frame. So there is some kind of Event,Action embed on it.
MVC Pull in another hand, suite better for “frequent update” and assume that View is the one trigger the update call.
Back to real-time game, if you not making a chess game, almost you “are doing” a pull based MVC, or apply this pattern privately. Here is the twist: Actually in JME3, you are doing both, that’s why it look like MVP!
In JME3 we almost see the things work like this, the “almighty” Cycle:
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:update_loop
1 Input listeners respond to mouse clicks and keyboard presses – Input handling
2 Update game state:
Update overall game state – Execute Application States
User code update – Execute simpleUpdate() method
Logical update of entities – Execute Custom Controls
3 Render audio and video
Application States rendering.
Scene rendering.
User code rendering – Execute simpleRender() method.
4 Repeat loop.
So you see : “push” the data to the view layer to render the results, also “pull” results from multiple controllers as needed.
In fact the most things can be considered as Model here actually the “SceneGraph” and the View should be its rendered result and the user’s input only! The Controls or the Presenter can be “AppState”, “Control”, anything hooks between update step, in simpleUpdate().
As my exprience, apply MVC to real-time application not usually help greatly but sounds very confused and blury. It can help if you too familiar with it anyway, but be careful or you break the MVC contract easily and make it not useful. You can blindy apply it without concerning of consequence, but that don’t make any sense.
B-The central
Now talking about the long “getManager().getSubManager().getItsManagedObject().doSomeThing()”
Consider asking your self this when you code:
- Can singleton help?
- Can hierarchy actually help?
- How secure is your application, is it a game or anything else?
- How perfomance sensitive your game is?
For this particular example, related to “Law of Demeter” that @zanval88 mentioned is about “communicating range scope” and “hiding information”, appear as “encapsulation” and “reference” in Java.
- If all your Manager classes is public, and referenced every where chances that they can be Singleton (read more about singleton for its downside).
- If not, you should nest your Manager and its ManagedObject it arbitrary order and way. Consider this for a game, it’s almost always not necessary!
2a) When you have your Managers and Object form a “tree” and obey a “cycle” or “protocol” or “common pattern”, may be contract them with an Interface or force them to extend the same base. [I DID this in my Atom framework!]
2b) Actually while a lower (near the core) Manager are more powerful and can capture the whole process, the higher level Manager (extended Manager or sub manager) know better about detail and specific aspects. The split should be carefully thought first to avoid un necessary burden of too much Managers. Personally, I usually think about an interesting example about a society with many cops and few citizens to imagine about this balance.
- For part of the game, when security are most important but not the performance, or for external services. Long indirect call is the most appropriate method, because of the availability (something should be injected, lazy loaded…) and security (some protol given, real info is hidden from our view,…etc). Without a check of availability, chance that you have NPE all the time!
- For part of the game that need performance. I said “a big deal of performance” you should try “singleton” for final class (and bare with its other issuses) or bet in some other flatten type of reference (little bit worse performance - one level of indirect) should also be concerned:
- array or list with an index. map via Class(Type) apear as Template in java … ex: StateManager.getState(ClassName.class).doSomething(); or even more abstract Central.get(“StateManager”).do(“ItsFunctionName”)!!!
- evolve your hierarchy with EntitySystem paradigm
This is only the things in the top of my head, this question I have been asked many times in many situation, by myself and colleagues, teamates. So I try to make it clear to my situation and also have some common usecases in it.
Please ask more, this is really essential anyway!
