Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: question(s) regarding Java port code  (Read 6100 times)
senn
Newbie
*
Posts: 1


View Profile Email
« on: March 22, 2011, 08:21:38 »

Hello

Ive been using PureMVC in some Flex3/4 applications for a while now and Im definitely a fan.

I was looking into the Java port as most of my development work is actually Java-based.
When browsing through the source code I noticed there were some architectural choices that I didnt fully understand.


1. Why arent classes like Mediator and Proxy made abstract?  I simply cannot think of a use case where anyone would use the base classes anyway...
Also, it would better (and cleaner) to replace

:
public void onRegister(){}with
:
public abstract void onRegister();
If however, it is intended that these classes are not abstract and indeed instantiable, please enlighten me with a use case.


2. What is the logic behind not using Generics in, for example, the following cases:

:
public class Mediator extends Notifier implements IMediator, INotifier
{
//...

private Object viewComponent = null;

//...
}
instead of
:
public class Mediator<T> extends Notifier implements IMediator<T>, INotifier
{
//...

private T viewComponent = null;

//...
}

or

:
public class Proxy extends Notifier implements IProxy
{
//...

private Object data = null;

//...
}
instead of
:
public class Proxy<T> extends Notifier implements IProxy<T>
{
//...

private T data = null;

//...
}

There's more examples like this.  Wouldn't this avoid lots of casting? 


Any input appreciated!

Greetings,
Bart


Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: March 23, 2011, 07:54:20 »

Both Proxy and Mediator can be instantiated and used, though 99.99999999% of the time they are subclassed.

For instantiating Proxy, you may simply want a named data object that can be retrieved from the Model. Dynamically created objects for a game, perhaps. Or interim values in a large calculation that takes async breaks to keep from going compute-bound.

These objects don't have to have a custom Proxy subclass with methods for manipulating them. In this case the Model is merely an object registry, and the Proxy a thin wrapper for placing arbitrary objects into the registry and retrieving them.

The case for instantiating Mediator is much the same. Perhaps you're generating gobs of sprites for your game. You can use the View as an object pool, wrapping your objects in thin wrapper that Commands retrieve by name (perhaps from a simple array of names stored in a Proxy instance) and act upon.

Sure, if you need object pooling, you could write something to do that, but if you're already using PureMVC, why would you bother? Model and View are functional registries out of the box.

-=Cliff>
Logged
Pages: [1]
Print