• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Factory Design Pattern??

 
steve nicholls
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
After reading through several chapters on RMI, it seems that most implementations use a Factory Pattern to delegate connection chores. However, after looking at the SCJD requirements, we only ever connect to one server in one given way (if you are local mode you would NOT need to instantiate a Factory object). To create a Factory, it needs to extend UnicastRemoteObject and you have to call it from the client using Naming.lookup(). To me it would seem, in the SCJD case, that you are creating a Factory for the sake of creating a factory (you write the client code to point towards a Factory, which points toward the DataServer, when you could write could to directly point from the client to the server).
I understand that creating a Factory allows the developer flexibility in the future, because he/she can easy switch or create new connections. Are there other benefits? Is my understanding of Factory architecture accurate/correct? Will I be docked points if I don't implement a Factory pattern?
I realize that the Factory pattern has significant values in production level code, but how relevent is it to SCJD?
Also, to implement a Factory server, would this be started in conjunction with the Data server? And would the Factory server utilize the same rmiregistry and security policy? Would it even have to?
Okay, I realize I just asked about 6 questions, but I really appreciate your help. Thoughts and suggestions are welcome and encouraged. Thanks!
 
Juan Ec
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
you will not be penalized if you don�t implement the X or Y pattern, you just have to make a good analysis, write the code, and provide good arguments on your decisions. anyway i shold tell you have an incomplete vision of the factory pattern
in your analysis you probably noticed that one of the things you should do is to let the client work with the database without knowing at all about its origin (local/remote).
remember the gof definition of the factory pattern:
"Define an interface for creating an object, but let subclasses decide which class to instantiate"

[ December 14, 2002: Message edited by: Jaun Katabasis ]
 
Mag Hoehme
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Steve,
the purpose of a Factory is to return the type of object that is required for the specified context. In the case of the SCJD, the factory could return a database connection, either a local one or a remote one.
"Factory pattern" may sound more elaborate than it eventually is. A Factory involves just a few elements. Here is a very simple example:

What do you mean by "Factory server"?
Hope this helps.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you carefully read the Data.unlock() javadoc, you'll realise that you will need to keep track of client identity in some way. Many in this group use an RMI factory to give each client its own Connection (aka RemoteData) object and keep track of client identity in that way.
This is just one of the possible implementations, though. You can do fine without an RMI factory.
I agree with the point that you should never use patterns just for the sake of it. If the problem in hand can be elegantly solved using a Factory or a Facade then by all means do recognise that fact, implement the pattern cleanly and use the pattern vocabulary to explain your design. But if your instantiation needs are essentially trivial then don't build an entire bloomin' factory to do it.
Some submissions read like a veritable pattern catalog, ending up with sixty classes entangled in the most intricate creational, structural and behavioural patterns. Well, gentlemen, I'm probably spoiling the fun by saying this but you're building an application, not a Christmas tree. Keep it simple.
- Peter
[ December 16, 2002: Message edited by: Peter den Haan ]
 
steve nicholls
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for all your advice. In order to track users (for unlock()), I will probably incorporate a Factory object into my design. Which brings me to the following question.
If I have a Factory object and a Server object do both need to extend UnicastRemoteObject? Or can I just set the Factory to extend UnicastRemoteObject and pass back the Server object? I am assuming that the Factory has to be placed on the server side, if we want to track users. (BTW - Mag, I just coined the phrase "Factory Server" as a Factory that extends UnicastRemoteObject. Wasn't sure what else to call it). Any thoughts or suggestions would be appreciated.
 
steve nicholls
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for all your advice. In order to track users (for unlock()), I will probably incorporate a Factory object into my design. Which brings me to the following question.
If I have a Factory object and a Server object do both need to extend UnicastRemoteObject? Or can I just set the Factory to extend UnicastRemoteObject and pass back the Server object? I am assuming that the Factory has to be placed on the server side, if we want to track users. (BTW - Mag, I just coined the phrase "Factory Server" as a Factory that extends UnicastRemoteObject). Any thoughts or suggestions would be appreciated.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by steve nicholls:
If I have a Factory object and a Server object do both need to extend UnicastRemoteObject? Or can I just set the Factory to extend UnicastRemoteObject and pass back the Server object?
Both need to be proper remote objects, living only on the server. The easiest way to achieve this is to have both classes extend UnicastRemoteObject, although you can export any Remote object by calling UnicastRemoteObject.exportObject().
- Peter
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic