• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

factory question

 
Debra Bellmaine
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
I've seen alot about factory patterns in this forum, and I'm not sure I totally get it. Here is some code of mine from a app similar to FBN:

The above code starts the app for the user. Depending on the number of arguments passed to BrokerToolFactory via BrokerTool, it determines whether or not the user intends local or networked mode. It is obvious what it does with regard to BrokerModel: gets an object reference from the registry if user wants networked mode, or creates the instance itself for local mode.
For the BrokerView instantiation, both BrokerViewAdapter and BrokerViewImpl implement my BrokerView interface, but BrokerViewAdapter extends UnicastRemoteObject, and BrokerViewImpl does not. (All the public methods in the Adapter just invoke the methods in the Impl when running with RMI).
It works great, but I want to know if this is a valid implementation of a factory pattern, and if not, why not.
Thanks,
Debra Bellmaine
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Before commenting on the Factory pattern, I see some problem with your code. I guess this BrokerToolFactory resides on the client side because I see you are doing a Naming.lookup() in the code. With that assumption, you should not create the instance of a class which extends UnicastRemoteObject unless you are creating a remote object on the client side which I think is unnecessary.
When you need to get an instance of any remote object, you have two options:
1) Use the RMI Registry to lookup for the instance which implements the java.rmi.Remote interface. What you get on the client side is the _Stub instance and never the remote object instance.
2) You can return the remote object when the client invokes a method on another remote object.
Here is my comment about the Factory pattern. Factory pattern is normally used for creating instances without hardcoding the class name in any part of the code other than the Factory class.
The factory class usually takes a name or have specific methods to distinguish the *kind* of objects need to be created.
Usually polymorphism is used when there is only one method in the Factory and you ask for an instance by specifying the name. For example, you can ask for an Apple instance by calling the method below in the FruitFactory:

The above method can return an Apple or Orange depending on the name which is usually defined as constants in the Factory class itself.
With that simple explanation of Factory, I wouldn't characterise BrokerToolFactory in your code as a Factory
[ May 03, 2002: Message edited by: Sai Prasad ]
 
Debra Bellmaine
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Sai,
With regard to the client being a remote object, in the app I've used as an example I've implemented the observer/observable pattern - the client gets live updates of changes to the model. I've been getting some feedback on another thread as to whether or not it would be bad to include this in the assignment. Feel free to comment on that.
On the factory issue, I want to be sure that I understand your comments correctly. It would go something like this?

If this is what you mean, I'm not totally sure I haven't actually done this. Here's what you wrote:

Usually polymorphism is used when there is only one method in the Factory and you ask for an instance by specifying the name. For example, you can ask for an Apple instance by calling the method below in the FruitFactory:
code:
--------------------------------------------------------------------------------
public Fruit createFruit(String name);
--------------------------------------------------------------------------------
The above method can return an Apple or Orange depending on the name which is usually defined as constants in the Factory class itself.

The BrokerTool code doesn't know or care what kind of BrokerModel and BrokerView objects it gets back. It asks for the correct instances by passing along the command line args, rather than by name - maybe this is nonstandard. For convenience I had "factory" pass back the Object array, rather than do a call to getBrokerModelObject and also getBrokerViewObject, although I could easily change it to have the two methods. If I'm still really missing this, please give me an example so that it is more real.
Thanks a bunch,
Debra
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you got it. For example, in my design, I have a ClientDataFactory which is responsible to either create the IData (interface with all the Data public methods) instance or get the IData instance from the RMI server. I have a specific method to return the appropriate IData instance.
In the future, when this application is extended to provide Passenger details, I will add another method in ClientDataFactory to get the IData instance representing Passenger table.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic