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 please review my local implementation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "please review my local implementation" Watch "please review my local implementation" New topic
Author

please review my local implementation

Jane Weil
Greenhorn

Joined: Mar 04, 2003
Posts: 9
Hi buddy, my draft design is finished, I'm taking RMI to implmenet remote. I'm just using plain java class to implement local, if you guys think it's all right, I will continue using it, because I'm not sure if it is OK.
1. local design:
interface FlyByNightLocalBroker which is using same methods as Data
public class FlyByNightLocalBrokerBean implements FlyByNightLocalBroker
in its constructor, I use
<p>db = new Data("./../classes/suncertify/db/db.db");
to connect to database.
client side:
public class FlyByNightLocalClient
I simply use
<p>FlyByNightLocalBroker flyByNightLocalBroker = new FlyByNightLocalBrokerBean();
to get server side reference.
An outstanding issue is each client thread will create a database connection.
Is that OK?
thanks a lot.
Jane Weil
Greenhorn

Joined: Mar 04, 2003
Posts: 9
Hi Mark,
According to your explanation to others, seems like my above solution is right? Is it? thanks.
-------------------------------
Also I am of the advocate that since local mode is stand-alone, there is absolutely no need for any locking since the records would be locked by the same client anyway. There is no contention or concurrency here for the records.
---Mark
--------------------------------
Poorna Lakki
Greenhorn

Joined: Mar 04, 2003
Posts: 11
Originally posted by Jane Weil:
Hi Mark,
According to your explanation to others, seems like my above solution is right? Is it? thanks.
-------------------------------
Also I am of the advocate that since local mode is stand-alone, there is absolutely no need for any locking since the records would be locked by the same client anyway. There is no contention or concurrency here for the records.
---Mark
--------------------------------

Jane,
U don't have to connect to the database for every client. Try having the connection to the database as a static object in FlybyNightLocalBrokerBean. (In the constructor if this static object is null then connect to the database.)
Thanks,-Poorna Lakki
Jane Weil
Greenhorn

Joined: Mar 04, 2003
Posts: 9
Poorna,
Since local implementation is stand-alone, there is only one client, so we even don't need to make db static
Poorna Lakki
Greenhorn

Joined: Mar 04, 2003
Posts: 11
Originally posted by Jane Weil:
Poorna,
Since local implementation is stand-alone, there is only one client, so we even don't need to make db static

Jane,
u are right. No need to make it static. One more thing, if u make it static will it support multiple threads? I mean..will locking,unlocking still work? This could be a good test case for testing remote locking/unlocking.
-Poorna Lakki
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
There is no reason whatsoever to make the database static whether it be in local or remote mode. Making use of static variables or singletons suggests that one might have a thing or two to learn about turning a problem domain into an object model.
- Peter
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
I think what Peter meant to say was 'I can't think of a single reason reason to make it static. However, I don't know everything. Can you please explain your reasoning'?

M, author
The Sun Certified Java Developer Exam with J2SE 1.4


Java Regular Expressions
Poorna Lakki
Greenhorn

Joined: Mar 04, 2003
Posts: 11
Originally posted by Max Habibi:
I think what Peter meant to say was 'I can't think of a single reason reason to make it static. However, I don't know everything. Can you please explain your reasoning'?

M, author
The Sun Certified Java Developer Exam with J2SE 1.4


Max,
I problem that i was trying to solve was maitaining a single instance of Data and LockManager. But i guess making is static is not the only way to do it. The only disadvantage of making it static (that i can see) is code change will be necessary in case we need another database instance pointing to another database i.e., another static variable pointing it to the new database.
Thanks,-Poorna
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Hi Proona,
I think that the static usage is fine, given the way you're describing. Don't let me, or Peter, or anyone else, intimitate you from doing your assignment from the way that you feel is best.
Design is often a subject thing, and governed by a lot of factors. People tend to feel strongly that 'thier' way is the only way, but that's foolish. So long as you see those variables and document that, you'll be fine.
Think of it this way: do you really want credit for a design that didn't come from you?
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 09, 2003: Message edited by: Max Habibi ]
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

I problem that i was trying to solve was maitaining a single instance of Data and LockManager.

What Peter was trying to say to you is that making Data and LockManager singletons (or even static members of some wrapper class) may not be a good idea. One of the criterias for grading the developer assignment is code reuse. In a very likely case that an additional database table (such as customers.db) is added to support the business needs, your server implementation will need a major revision. But if you do it right, not a single line in any of the the server classes needs to change, no matter how many database tables are added.
Now, which server design do you think is better in terms of reusability, extendibility, and mainainability? While you will probably pass with your ill-conceived singletones, I encourage you to reconsider. Is it intimidating enough?
Eugene.
[ March 09, 2003: Message edited by: Eugene Kononov ]
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Originally posted by Eugene Kononov:
One of the criterias for grading the developer assignment is code reuse.

Actually, while code reuse is a good idea, I am not aware of it being an explicit criteria of the assignment. Maintainable and clarity, however, certainly are.


In a very likely case vthat an additional database table (such as customers.db)

Why likely? I may be wrong, but I seem to recall that the only part of the design that need to be flexible was the GUI. The rest simply need to be clear.

is added to support the business needs, your server implementation will need a major revision. But if you do it right, not a single line in any of the the server classes needs to change, no matter how many database tables are added.
Now, which server design do you think is better in terms of reusability, extendibility, and mainainability? While you will probably pass with your ill-conceived singletones, I encourage you to reconsider. Is it intimidating enough?
Eugene.

�right�, �better�, �ill-conceived�. No, I think you'd have to add a few more pejoratives. Eugene, I�m starting to think you have too much time on your hands
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
M
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

but I seem to recall that the only part of the design that need to be flexible was the GUI.

So, you wouldn't make an effort to make the other parts flexible? I am a bit shocked here. If we have to argue about the merits of flexibility in the software engieering, we should go back to Java In General (Beginner), if not to Programming-101.

�right�, �better�, �ill-conceived�. No, I think you'd have to add a few more pejoratives. Eugene, I�m starting to think you have too much time on your hands

I am not sure what you are trying to say, Max. There are objective criterias based upon which it is possible to distinguish between a bad design from a good design. I am not afraid to label a particular solution "bad", if it satisfies the requirements, but does it in a sloppy way, without any consideration for code reuse, mainainability, and extendibility. You may argue that a particular design is a matter of taste and choice, but I will submit to you that it is also a matter of high cohesion, low coupling, and good encapsulation.
But, as Bill O'Reilly likes to say, we'll let the audience decide...
Eugene.
[ March 09, 2003: Message edited by: Eugene Kononov ]
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Originally posted by Eugene Kononov:
I am not sure what you are trying to say, Max.

First, I'm saying that you shouldn't go dropping my smilies . Second, I'm saying that everyone should relax and be friendly. It's intimidating to post here, and I'd like new people to feel welcome, as well as old warhorses like yourself.

There are objective criterias based upon which it is possible to distinguish between a bad design from a good design.

Yes there are, and the most fundamental of those is, 'did you design to the spec?'. The SCJD is not a professional project: it is an exercise in coloring inside the lines, and designed to be a learning experience.

I am not afraid to label a particular solution "bad", if it satisfies the requirements, but does it in a sloppy way, without any consideration for code reuse, mainainability, and extendibility.

That's fine, and I'm glad that you're not afraid of sharing your opinion. However, I'm asking you to be less critical, and more constructive. You want to explain the benefits of one approach over another? Great! this is friendly and civil place for that.

You may argue that a particular design is a matter of taste and choice, but I will submit to you that it is also a matter of high cohesion, low coupling, and good encapsulation.

That's fine, and I'm open to that debate. Chances are, we probably agree on a lot of these kinds of issues. But I'd like to do it without resorting to harsh tones, and I'd like to do it in such a way that we don't alienate anyone, including yourself. Good?

But, as Bill O'Reilly likes to say, we'll let the audience decide...
Eugene.

How about we just lay out the arguments, and let people come to their own conclusions?
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 09, 2003: Message edited by: Max Habibi ]
Qusay Jaafar
Ranch Hand

Joined: May 06, 2002
Posts: 127
come'on guys,
CHEER UP


Qusay
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: please review my local implementation
 
Similar Threads
Lock Manager implementation
Request For Comments
Getting access to the DatabaseServerLoginModule
I need design advice
The Server