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
--------------------------------
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
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
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
I problem that i was trying to solve was maitaining a single instance of Data and LockManager.
Originally posted by Eugene Kononov:
One of the criterias for grading the developer assignment is code reuse.
In a very likely case vthat 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.
but I seem to recall that the only part of the design that need to be flexible was the GUI.
�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
Originally posted by Eugene Kononov:
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.
Qusay
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |