Design issue / suggestions
Hello fellow programmer!!!
Im working an interesting application framework, where I have of course an Application class. This is a dynamic component based framework, which is important here...
Key classes are
(1) Application class
(2) Controller class
(3) ComponentLoader class
(4) Component classe(s)
The application class will pretty much handle everything
the framework is capable of, with the help of many support classes///
Components should have only a simple higher level interface for interaction with global features of the framework. This interface is to be provided by a single instance of of the Controller class, which each Component loaded will have a reference to.
There are a large number of lower level methods in the Application class that Components should never have access to, however the current implementationof my code places a reference to the Application class in the
Controller class. Implemented this way there is no real way to prevent components from accessing key methods and data which by design, they shouldnt!!!
Thinking a little about this it seems some sort of messaging schema would be a solution, such that the Controller is actually firing specific events from its methods and the Application object is listening for them.
and acting accordingly upon recieving them...
Would this be a good solution?
Is there any other solution?
also if possible where might I find a good resource on implementing an event model smilar to that found in JFC/
Familiar with some, not all of course, of this event model, should I use some the existing classes as a basis for my own customized event model?
Please any recommendations, resources or insight that can be provided on this topic would be greatly apreciated. Through trial/error and time of course the design is getting better!!! currently in the process of gutting the whole thing and redesigning, Im hoping some of you more experienced programmers can help me get this thing right,
Thanks for the time,
J.Prisco
[2153 byte] By [
J.Prisco] at [2007-9-26 2:25:58]
So you have a class (let's call it A) which has methods
x and y and you want some classes only to see the method x and not the method y ... right?
One option would be to create a wrapper for A:
create an Interface I with method x
let A implement I
write a class like this:
Class Wrapper implements
private I instance;
public Wrapper(I aInstance){
instance = aInstance;
}
public void x(){
instance.x();
}
// note: no implementation of y
now you hand out instances of the wrapper to
the other classes which should only get limited access.
HTH
Spieler
The real interesting thing was .. I was just sitting in
front of my computer with exactly the same problem ...
I want to write a game where the players submit
not simply there moves but classes which perform their
moves, so I have to make the classes for the game
logic really water proof.
Have fun and thanx for the bucks
Spieler
Initially thrilled with this technique I didnt give it a whole lot of thought!!! Thinking about how3 and where Id apply the technique I had a realization that rules using the technique out... Sure you can limit the methods available using an interface this way, but there is not stopping one from casting the interface back to the original and then subsequently calling methods they shouldnt be calling!!!
This realization of course ruined my day, but or course will lead to a better design in the end!!!!
Just figured Id point that out to you as you will be using the technique as well.....
If there are any other suggestions I am of course all ears, until then Ill be investigating a messaging schema, which I knew was inevitably going to have to get into sooner or later anyhow........
There are good news and bad news:
- the bad one: you didn't read my posting properly
- the good one: I was aware of that problem and avoided it from the very beginning.
The simple trick is the interface I doesn't implement
the method you want to hide (y) so if you cast your
wrapper to I (and you can't cast it to anything else)
you still won't get a method y.
HTH
Spieler
