Swing and OOD
hi ..
i am working on a project that i am trying my best to design it as OO as possible ..
i have the core of the system as a class called Gipsy, it instansiates a factory which instanciate an interface which is being implemented by a text interface(TInter) and GUI interface(GInter).
now my problem is how to take user requests and pass them to the core (Gipsy).
i though about 2 choices:
1. create a class that will pass the request and form some kind of mapping. but i think this is littel bit complicated and not effiecint since there are some JList(s) and there is no easy way to take a row String (which is the text in a list choosed by the user ) and use it to pass the request(can't really explain it well , that's abvous i guess !).
2. use MVC but i don't know how to do that exactly.
please can someone suggests a good way to do it ? i guess both of my ideas aren't that good and i need help so badly.
thanks alot for ur help
Musab.
[1008 byte] By [
malrawia] at [2007-9-28 0:24:02]
I don't understand certain points here, can you give more details
1) Why do you want to pass the request to the core system, what does it do. The user request processing supposed to be done at the enhancement points of the subsystem.
2) What is the problem? If passing the request to the core is the only problem, then you have to tell me what your core system accepts.
3) Is your question about how to design the whole UI using MVC?
4) Please be elaborate on your point 1
- Karthicraja
the core system is responsible for orgnizing images in e-albums , so the core should accept things like add image to album request, delete image, delete album etc.
--||--> GipsyGInter(GUI)
||
core|> Instanciates factory -|
||
--||--> GipsyTInter(TEXT)
both GipsyGInter and GipsyTInter implement an interface to make it possible for the factory to call methods of whatever interface (GUI or TEXT) we are dealing with.
now my problem is i don't know how the GUI/Text interface will be able to tell the core something like .. ok add image 1 to album 1000.
the core is not visible to the GUI/Text interface, since the interface is not inner class to the core.
i hope that i made myself clearer littel bit .. please if there is any Q's i will be glad to answer them ..
and thanks for helping in advance
Musab
the diagram is not visible so here is what it's all about ..
core system instanciates factory
factory insatnciates interface Inter
GipsyGInter implements the interface Inter
GipsyTInter implements the interface Inter too ..
the factory can call methods of whatever class implementing the interface inter (GipsyGInter/GipsyTInter).
hope this clears it a bit
May i know what sort of operations your GipsyTInter, GipsyGInter provides.- Karthicraja
the core (Gipsy) is responsible for arranging images in albums categories .. operations include things like ..
create album .. addImageToAlbum .. deleteImage .. createImage
the interface (i don't mean java interface, i just mean GUI interface please consider this unless something else is mentioned) doesn't really know anything about the core .. i.e there is no class Album or Image in the GUI classes .. on the other hand the core has those classes (Album, Image) so basically the GUI interface class can't call methods in the core (such as addImageToAlbum) because the GUI is being instanciated by the core and it is not an inner class for the core ..
all what's in the GUI interface classes are JList(s) that should show the names of the images and albums to the user (GUI classes get the names of images and albums from the core class) ..
so how can i get the GUI interface class to tell the core that the user wants to add an image to an album or to add album etc when it can't call the core's methods ?
Hi,
either I'm misunderstanding something, or the answer is really simple:
your core should offer all the functionality it has as methods. If the core consists of more then one class, considere a facade, that is a single class, which exhibits all possible functionality of the gipsy classes and delegates the calls to the 'real' gipsy classes. Your different user interface wil instantiate a instance of gipsy and call it's methods and present the results in apropriate form to the user.
Just make sure gipsy doesn't ever call the user interface classes, this way you can exchange them without a problem.
regards
Spieler
hi ..
i thought about this solution but i thought what if we have more than one interface ,i.e GUI and text .. i have a factory that creates one of one of the interfaces depending on the user's wish...
should the factory instanciate the Gipsy or should the GUI/TEXT user interface class instanciate the Gipsy..
by the way .. should they instanciate the Gipsy or the facade ?
thanks alot for ur help
have a nice day
regards
Musab
The factory would instantiate the facade and pass it as an argument to the constructor of the userinterface.
to the question about instantiating the facade versus gipsy itself:
two options:
1. you instantiate the facade which in turn instantiates the gipsy core classes. I'd go this way if gipsy is fairly easy
2. if gipsy is really complex to instantiate, you should have a seperate builder class to do it for the facade, but I'd still start with the facade.
The reason to start with the facade is: you want to hide complexity (in this case gipsy) behind it. And what is the point if you (the using class) puts the complexity (gipsy that is) behind the facade itself.
regards
Spieler
there is another reason for creating the facade which creates directly or indirectly gipsy:If you do it the other way round gipsy would need to know about the facade which isn't necessary for all other purposesregardsSpieler
"And what is the point if you (the using class) puts the complexity (gipsy that is) behind the facade itself."
could u please explain it more .. i know that facade hides complexity so the other world will deal with this neat class without worring about the "how to" and the details .. but i didn't exactly understand ur sentence..
thanks
Musab
the point of a the facade is that the class using it doesn't have to deal with the complexity of gipsy.But if the class gets a reference to gipsy or even has to create it, it has to deal with gipsy: figuring out what class to create, how to get an apropriate facade for it.
gocha..
alright .. things are so much clearer now thank God .. of courses thanks to u ..
now i have this Q with some alternatives but before going into the Q please consider these things:
1. Library, Rolls are classes of the core of the system.
2. Gipsy is going to be a facade that takes commands from the GUI/Text interface and passes them to the core neatly (the core includes Library and Rolls).
now the Qestion is .. there are some parts of the interface that deal with the Library and some other parts deal with Rolls, for example i have a JList that shows the contents of Library and should take requests that are asscociated with the Library, same thing with the Rolls and another JList that's associated with it.
and we have Gipsy (which is facade) instanciated in the factory and passed to the GipsyGInter (GUI interface) or GipsyTInter (Text interface).
now when the user requests something to be done on the Library from the JList (which is being instaciated by the GipsyGInter) the ways that that JList can communicat with Gipsy are :
1. having Gipsy Global .. which is going to violate one of the OO princeples.
2. passing Library to the class that will take requests form the user regarding Library ,, same with Rolls i.e send it as parameter in the constructor of the class that shows and deals with the Rolls.. but this way we don't have a facade anymore !
3. (which i like among the three) having a LibraryFacade and RollsFacade both of those classes will be instanciated by the father facade which is Gipsy. then i will pass the LibraryFacade to the class that deals with Library and pass the RollsFacade to the class that deals with the Rolls. BUT i have one thing that makes me suspect that it could be a not bad idea is that the Library's facade will be just the public methods of Library , same thing for the RollsFacade.
so which one u think is better and if there is a better way could u please direct me to it .. i know that i am pushie with asking but becuz i don't have that much of a help in here and i am new to java.
thanks alot for helping and have a nice day
Regards
Musab
I'm not sure if I really understood your new problem, but
I'll try to help anyway:
1. If it doesn't make sense for the library to be instantiate more then once you could use a singleton pattern or static methods to make it public available. Nothing wrong with that. java.util.Math is a typicall example for this method of 'global methods'
If you need multiple instances of the library this is not an option.
2. I think you are quite right with your evaluation of this option. and it holds also for option 1.
3. I don't like the sound of 3 facades. Probably it would make more sense to have one facade which knows (has references to) the library, the Roles (I'm assuming you are refering to roles and not baked pieces of dough ;-) and the core.
One more advice:
start coding. Might sound like a stupid advice but sitting there thinking up a cool design without realy understanding the pros and cons can get really frustrating.
In my experience the best way to learn design is to just try it.
Write the app in the design you came up with so far. When you finished it come up with changes for the app. Then start to think about what kind of patterns would help you to make these changes more easily. After some time you will get a feeling for what pattern has what kind of effect.
regards
Spieler
hi again .. (i guess u wish u could kill me :))
ANYWAY..
yesterday while i was having dinner i got an idea which might be okay .. the idea is having those classes of the interface that deal with the Library and Rolls(and no it is not the baked pieces of dough :) ) as inner classes to the GipsyGInter (which is the class that is responsible for creating all other classes of the GUI interface) and by having the core's facade as a private class member of the GipsyGInter (as u suggested earlier, by passing the facade to the GipsyGInter) that way those inner classes can call methods of the facade without problems except for one which is having a lengthy file .. which i really don't know if it is ok with java programmers or not .. i mean if i am trying to be as standard as i can would it be ok ?
i guess it depends ...
BY the way when u said
"3. I don't like the sound of 3 facades. Probably it would make more sense to have one facade which knows (has references to) the library, the Roles "did u mean that these references will be passed to the appropriate classes of the interface depends on which deals with who ?
for example the facade has reference to the Library, and the facade will pass the reference to the constructor of that class of the interface (the class that is responsible for taking user's requests to regarding the Library) so later that interface class can call methods of Library ... did i get it right ?
but this way u are losing ur facade aren't u ?
thanks
cheers
Musab
