Passing User enterd Data across Modules
Hi please suggest me some design pattern for the req.....
Its a graphics application where user action like moseClick , mouseDragged events are captured and One Bean Class MouseData is populated.
Now differnt totally differnt components wants to use this real time data.So how should i design so that other modules can use this data on demand but i dont want to couple different modules.
What i am thinking on is that thier is MouseData class and if any other module wants than just req for it
The logic for when to ask for User data will be in their repsective modules according to the requirement......i want to design in such a way that all other modules can envoke a method or some triggger to get the currently updated MouseData.
Its like common pool of data from where any module can take the current data but thier should not be tight coupling .
One way is to pass a refrence of my MouseData class to all Modules but it tightly couple my modules.
Basicallly i am in process of designing my application so some things are yet not clear......so i want to design in such a way that if any new module comes up ,it can easily use the data pool like pugin sort
Basically you want to get mouse data without coupling to your MouseData class? The classes are already coupled to the mouse data in this design. I think you may be missing the big picture here. Uncoupling it from one mouse data class only allows you to provide another mouse data class. The client classes still need the mouse data. Unless you can decouple the other components from the mouse in general, I don't see much point to this.
yaa you are right ...this is first time i am doing design and so thier is no past experience to fall on...........this is just wat came ino my mind..........what kind of architecture u suggest where thier is common data pool and all other independent modules want to access this real time data............
Thanks a lot fr guiding me
First, if you haven't read the GoF Design Patterns book I suggest picking up a copy at a library or bookstore. This is the defacto foundation for OO design.
There are quite a few approaches you could take. Here are two:
The first is the one you have mentioned where you pass the mouse data class to each of the mouse data clients. You can always make your MouseData class an interface. This isn't terrible way to approach this but it's not my favorite. It depends on the situation. The problem with this is that some third party class generally needs to provide the appropiate MouseData instance to each client. This is often inelegant but sometimes it's perfect. Depends on how these clients are interrelated. When want to add a new client, you'll have to again provide the MouseData instance.
The other way I would recommend is to create a Factory class for the MouseData. The Factory class will have a method on it that provides MouseData instances. When you create a client, you call the Factory and get the MouseData instance. This way new clients have less ripple effect on the rest of the code. There are many ways to create Factory methods. One approach is the Abstract Factory approach. You could even make the MouseData class have a static factory method on it. It can't be an interface in that case, but you can make it abstract.
