Re: static or not?



hawat.thufir@xxxxxxxxx wrote:
> iamfractal@xxxxxxxxxxx wrote:
> Hi, Ed!
>
> ...
> > Thus, for example, controller.Driver will register its Controller
> > interface in the Registry by calling:
> > Registry.getInstance().register(this).
>
> package controller;
> package-private class Driver extends controller.Controller{
> void register() {
> Registry.getInstance().register(this);
> }
> }
> is the register method correct as far as it goes?
>
>
> "If I use a singleton, then I can strip away an interface from this
> singleton, and have it register that interface in the Registry.
>
> If I use static methods, I cannot do this: static methods are not
> allowed to hide the instance methods of the interface.
>
> This is the major reason I use a singleton, instead of a class of
> static methods. " -Ed
>
> this is where you're stripping away an interface?

Exactly, though I should have pointed out the signature of this method,
as it is crucial. This method will have signature:

void register(Controller controller);

And not,
void register(Driver controller);

This any Driver implementation could register, as long as it implements
the Controller interface. This would not be possible if we tried to
register a class of static methods.




>
> > Next, a user will make some input; we needn't specify how, here, but
> > suffice it to say that when that input is made, an object will need to
> > get that input into the system. It will do this by doing something
> > like:
> > Controller controller = Registry.getRegistry().getController();
> > controller.process(input);
>
> if this is done from class foo, what's foo's package? of MVC
> I think view, but view presents data to the user, so I'm not sure.


Well, class Foo, in this case, will be a class that captures user
input, which is traditionally put in the controller package. As the
user input could be from a button click (if the tool is started
graphically) or from a class just reading command line input, these
classes - specific to user input - are usually put in a subpackage of
controller.

For example, controller.gui would hold the GUI widgets waiting for
button clicks, and controller.cli would have classes reading from the
command line.

In our small example, however, it would be perfectly acceptable to have
all these user-input classes lumped into the controller package itself.




>
> > The Driver object will have its process() method called, and will kick
> > the database into life, by something like:
> > Registry registry = Registry.getInstance();
> > Model model = registry.getModel();
> > model.doThis();
> > model.doThat();
> > Result result = model.getResult();
> >
> > (OK, here's an interface I'd forgotten; any guesses where we'd declare
> > it?)
>
> heh, ir1 of course.

Absolutely!



>
> > The Driver object would then output the result to the use by:
> > int viewID = registry.getCurrentViewID();
> > View view = registry.getView(viewID);
> > view.show(result);
>
> where did result come from, please?
> view.show() might trigger a SQL query and would show the outcome of
> that query?

This is a continuation of the code written above; result is just a
convenient way to pass view-independent data from controller to the
view. The Driver code altogether will be:

Registry registry = Registry.getInstance();
Model model = registry.getModel();
model.doThis();
model.doThat();
Result result = model.getResult();
int viewID = registry.getCurrentViewID();
View view = registry.getView(viewID);
view.show(result);

Here we see, again, that Driver has only one dependency one a concrete
class, and all the rest are interfaces.



> you said "...portray Driver as a Controller," so it's:
>
> package controller;
> package-private class Driver implements SomeInterface {...

Correct, and that SomeInterface will actuall be the Controller
interface.




>
>
> > Thus we have a system in which there are only two types of
> > inter-package, concrete class dependencies:
> >
> > 1) From Start to XStart - and these XStart classes only contain enough
> > logic to kick start the business logic, in other words, these
> > dependencies do not change as business logic changes.
>
> if everything in the start package is business logic, might that
> logic consist of static methods, like Math.sin(x), or is that a bit
> extreme?

I didn't phrase this well. I meant to say that everything in the start
package is NOT dependent on business logic: all the start package knows
is how to call a single method (usually start()) on one concrete class
in some other subsystems. Admittedly, this method could of course be
static, but I still use singletons for these (yes, the getInstance() is
static in fact).

So our start package will contain on class which will look something
like this:

class Start {
public static void main(String[] args} (
ModelStart.getInstance().start();
ControllerStart.getInstance().start();
ViewStart.getInstance().start();
)
}

And thus all the subsystems get a change to register relevant objects
in the registry before the user starts clicking things.

Note, in the real world, the start phase is usually more complicated,
using either broadcasts of sequentially increasing phases (so that, for
example, the Registry object starts in phase 1, the ConcreteModel
registers in phase 2, Driver registers in phase 3, etc.) or Observers
all register to be notified of registrations together, and a first
registration triggers a wave of registering throughout the system.


>
> > 2) Dependencies on the Registry concrete class - but this class simply
> > stores and erturns interfaces, and has no dependencies on the
> > methods of those interfaces, and thus is immune to changes of the
> > interface methods (although of course will change as whole
> > interfaces change, and new ones are added).
>
>
>
> > And *all* other inter-package dependencies are on interfaces
> > only. Thus, you can switch in any database you like, as long as it
> > conforms to the Model interface (this will, in reality, probably be
> > JDBC, or a wrapper thereof). The same goes for the Views and even the
> > Controller itself.
> >
> > Hence, "Program to an interface repository, not an implementation
> > repository."
> >
> > Note that model package, view package, and controller packages do not
> > depend on one another (you can Google for the heated discussions on
> > which of these packages should depend on one another, and which must
> > not), and that the system is guaranteed to be free from inter-package
> > circular dependencies.
>
> err, next time ;)
>
> > Of course a full system will have hundreds of packages, and there will
> > be hierarchical start/implementation repository/irX packages, but the
> > design is - and particularly the benefits listed above are -
> > wonderfully extensible.
> >
> > .ed
> >
> > www.EdmundKirwan.com - Home of The Fractal Class Composition.
>
>
>
> this helps to justify MVC for me, thanks.
>
>
>
> -Thufir

.