Forums Register Login

Final check before upload

+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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
CLUCK LIKE A CHICKEN! Now look at this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 1110 times.
Similar Threads
Overall Architecture
Final comments
Fbn question about design
NX SCJD: but passed with 155/155
Design review
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 02:04:01.