File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Final check before upload Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Final check before upload" Watch "Final check before upload" New topic
Author

Final check before upload

Jim Bedenbaugh
Ranch Hand

Joined: Nov 09, 2001
Posts: 171
I'd appreciate any comments before I do my upload.
Besides having the README.TXT, DesignChoices.txt and UserDoc.txt files (I've gone over them 2 dozen times already ), the following is a summary of what I've done for the project:
Used MVC pattern for the GUI. The Model controls state of the data. The View builds components for display. The Controller directs activity for both and handles all actions initiated by the user. The View uses a JTable per requirements, but overall the View is very vanilla - just the facts. No bells or whistles.
The Controller talks to a Facade. The Facade passes all requests from the Controller for data, etc. All business logic resides in this Facade. The Facade (implements a Data Interface) handles all requests to the following: a Connection Factory, a Server and a Connection Builder. The Connection Builder (client side) gets connections to the Connection Factory (server side) class.
The Connection Factory is implemented with RMI. You can assume I properly integrated Remote and UnicastRemoteObject in the Connection Factory and the Server class. The ConnectionFactory builds a Data Factory and has a getter for the Server class. The Server class is embedded with a reference to the Data Factory. The Connection Factory will create a new Server thread for each client and return it to each client side Facade. Only one Data class is used by all the clients in remote mode.
The Server class implements a Data interface and Unreferenced. It takes composite data requests and breaks them into atomic requests and directs them to the appropriate class - either to the Data class through the Data Factory reference or to FieldInfo or DataInfo. The Server class has reference to a Lock Manager.
The Lock Manager is a singleton and is used only in remote mode. It only handles atomic requests to lock or unlock. It only returns a boolean to indicate if locking was successful or not. The blocking of records is done in the Server class.
Implemented a ChainedException class. All exception classes extend from here. Typically, exceptions are thrown at atomic levels and are caught at composite levels - usually the Controller on the client and the Server on the server side.
Modified Data class and then overrode the lock, unlock and criteriaFind methods.
Implemented a policy file for client and server, but don't really need it.
On server side, command line startup requires policy file, database name and DNS.
On client side, only need policy file at command line. Port and DNS are entered in a JDialog for remote mode. A JFileChooser is used for database selection in local mode.

That's pretty much it and it all works! I've tested till I'm sick of seeing this thing.
Anybody see any glaring holes?


Regards,
Jim
SCJP, SCJD, SCWCD, SCEA Part I
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Jim,

Anybody see any glaring holes?

Nope. Sounds well thought out. If your testing shows that everything works with multiple clents connected, then I'd say you're ready to upload, go take the essay exam and become a SCJD2.
Good Luck,
Michael Morris


Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Jim Bedenbaugh
Ranch Hand

Joined: Nov 09, 2001
Posts: 171
Originally posted by Michael Morris:
Hi Jim,

Nope. Sounds well thought out. If your testing shows that everything works with multiple clents connected, then I'd say you're ready to upload, go take the essay exam and become a SCJD2.


Thanks for the review.
I'm doing final testing today and will upload either today or tomorrow.
Many thanks to you, Nate and others for all the help.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

The Facade (implements a Data Interface)

Does this mean your Facade has the same public methods as Data, or does it have much less methods that are like bookFlight() searchFlight?
If it has all the methods of Data then it really isn't a Facade.
But from all your other designs, it looks good.
Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Sam Stackly
Ranch Hand

Joined: May 04, 2002
Posts: 109
Guys,
I am almost done with code and everything and really appreciate your comments about my design,
My design is very similar to Jim, except in my Facade class (DataAccessor) which has an instance of DataInterface as a member variable (DataInterface include all public method for Data class), I changed Data class to implement this interface and my RemoteDataInterface implements this interface too.
Now in my DataAccessor I have to ctor for local and remote connection (to get connection factory first and then calling getDataServer method to get RemoteDataInterface) and two methods for search and book flight. DataInterface instance play a Data class no matter if is remote or local.
So it means I didn�t add criteriaFind method inside of Data Class neither lock and unlock method. In server side (DataServer class) I create an instance of LockManager to deal with lock and unlock (passing recordNumber and <this> as a reference to DataServer )
Again I appreciate your comments,
Sam
Jim Bedenbaugh
Ranch Hand

Joined: Nov 09, 2001
Posts: 171
Originally posted by Mark Spritzler:

Does this mean your Facade has the same public methods as Data, or does it have much less methods that are like bookFlight() searchFlight?
If it has all the methods of Data then it really isn't a Facade.

We could probably get into some academic discussion about this, but the reality is that it's closer to being a Facade pattern than anything else in the GoF patterns, so that's what I call it (I'll get more particular about this when I take the SCEA cert, I suppose). I do include the the same methods as the Data class class, because the specs say:

Writing Data Client
To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration.

Well, I did exactly what they required. My Facade has two constructors, one for local mode and one for remote mode.
I also have a bookFlight() method, as well, that is called by my COntroller. Under normal circumstances, I would have only included these type of composite methods in the interface, but I tried to follow instructions to the letter, such as not changing the lock method signature, etc. Nonetheless, my Controller only calls the Facade, instead of maybe half a dozen classes.
That's why I felt I had no choice other than to use a LockManager (which I changed from being a Singleton at the last minute) - I could call the lock method on my Remote Implementation without changing the lock signature presented in the specs, but inside the lock method I could call the LockManager with anything it wanted too - including a clientID composed of the "this" of the Remote Implementation.
Essentially, the requirements forced you into certain patterns. You just had to figure which ones you thought were the best.
Nate Johnson
Ranch Hand

Joined: May 13, 2002
Posts: 301
Originally posted by Jim Bedenbaugh:

We could probably get into some academic discussion about this, but the reality is that it's closer to being a Facade pattern than anything else in the GoF patterns, so that's what I call it (I'll get more particular about this when I take the SCEA cert, I suppose). I do include the the same methods as the Data class class, because the specs say:

Writing Data Client
To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration.


I like academic discusions
Anyway, the way I understood patterns was that a facade is a simple interface to complex subsystems. Things like booking flights that require doing a lot of work, but is something in general that a developer would want to call. The developers that needed to do the dirty work could still get to the subsystems directly, but for the 80-90% of developers, the simpler facade methods would do the trick.
I took the "all public methods..." quote from sun as needing to implement the DAO pattern. That way a database could easily be swapped out for another database. You implement a few interfaces that would work for any db and implementations that talk to the Sun stuff, but then implementations could be written to talk to any database (flat file, relation db, oodb, etc). Then your business code never has to change since you would be using the generic interfaces and probably some connection factory.
I guess it depends on how you read the requirements... those were just my perceptions


scwcd, scjd, scjp<br /><a href="http://natejohnson.us" target="_blank" rel="nofollow">http://natejohnson.us</a><br /><a href="http://rice.kuali.org" target="_blank" rel="nofollow">http://rice.kuali.org</a>
Jim Bedenbaugh
Ranch Hand

Joined: Nov 09, 2001
Posts: 171
Originally posted by Nate Johnson:

Anyway, the way I understood patterns was that a facade is a simple interface to complex subsystems. Things like booking flights that require doing a lot of work, but is something in general that a developer would want to call. The developers that needed to do the dirty work could still get to the subsystems directly, but for the 80-90% of developers, the simpler facade methods would do the trick.

Yeah. I'm sitting here reading my Design Patterns by Gamma, et al. The way I read it, I did indeed implement a Facade. I guess Mark took exception to the DataInterface implementation, but even so, I don't know that doing so disqualifies my object as a Facade. I guess he'll weigh in on this, though.

I took the "all public methods..." quote from sun as needing to implement the DAO pattern. That way a database could easily be swapped out for another database. You implement a few interfaces that would work for any db and implementations that talk to the Sun stuff, but then implementations could be written to talk to any database (flat file, relation db, oodb, etc). Then your business code never has to change since you would be using the generic interfaces and probably some connection factory.

I guess the difference is my approach was really in terms of applying GoF patterns and not J2EE patterns, since I'm not really as familiar with those. Granted I deliberately used an MVC pattern and in the end my implementation of GoF patterns may have ended up looking a lot like some J2EE patterns, but I didn't consciously try to implement patterns from the J2EE catalog.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

To me the object you built is a Proxy object. It has the same Methods as another class, and when you call one of those methods it just passes it to the other class.
A Facade Pattern does not have the same methods as the other class, it has an instance of the other class that it makes calls on, but it simplifies the other class.
example
I have a class that has
lock, save, unlock, find, calcCosts, addSenderAddress, to a developer on the client side that is many methods. whereas all he wants to do is make an order.
so the facade class would have an instance of the above class and only have one method called placeOrder, in that method it would call find, lock, calcCosts, addSenderAddress, save, then unlock, all within that one method. Now that would be the only method that the client developer needs to know about or call.
That is the Facade pattern, the Facade made the other class much more simpler. And also allows the client developer to not even care about the underlying implementations, because that is someone elses job. It also allows you to swap out the underlying implementation, and replace it with something else, without having to change the Facade class.
Does this make more sense of why I would say that the class that you have isn't a true Facade class. You kind of combined the Facade methods with the Data methods. So all you really have to do is create a class that takes the Facade methods you have in your class and copy them into this new class, and have it have an instance of your other class.
This new Facade class is also where you pass either a Remote Mode version of Data, or the Local Mode of Data, and now the GUI Controller just has a Facade class to deal with and never has any idea of what is underlying, local or remote.
Does this make sense?
Mark
Jim Bedenbaugh
Ranch Hand

Joined: Nov 09, 2001
Posts: 171
You kind of combined the Facade methods with the Data methods.

Pretty much this is the case.

So all you really have to do is create a class that takes the Facade methods you have in your class and copy them into this new class, and have it have an instance of your other class.

Or I could just change my documentation and say I implemented a Proxy class.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

Or I could just change my documentation and say I implemented a Proxy class.

Yes that works too. Not he best solution but I don't think they will knock you donw any points for it.
Mark
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Final check before upload