aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Design Patterns ... again Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Design Patterns ... again" Watch "Design Patterns ... again" New topic
Author

Design Patterns ... again

Gennady Shapiro
Ranch Hand

Joined: Sep 25, 2001
Posts: 196
I have been trying to identify the design patterns that would complement my design rather than over-complicate it. Here's what I came up with:
Singleton - to enforce one instance of the db
Factory - a few applications, f.e. getConnection("file"|"rmi")
State/Mediator - to switch between search forms (this is not required , I am doing it to demo my GUI "control scheme")
Facade - mmm...I am still not sure if it's even worth mentioning
ReadWriteLock - to do the locking
Visitor - here's an interesting case. Normally, a 'SearchEngine' would be implemented as a visitor but Fly By Night is too trivial for this. I have implemented it but now I am thinking of going back to just passing references.
Chain of responsibility -- does Exception bubbling qualify for this or is it a pattern of its own?
MVC/Observer is implemented by swing's Table/Model , so its built-in, althought I have seen people mentioning it.
Adapters are awt standard.
Iterators are java2 standard.

Any comments? Am i missing anything?
Thanks
[This message has been edited by Gennady Shapiro (edited October 22, 2001).]
Thomas Mathai
Greenhorn

Joined: Apr 01, 2001
Posts: 9
If you search this forum, you will find Peter repeatedly warning
against the use of Singleton in connection with db.db.
What you really need here is a file lock to ensure that db.db is associated with at most one instance of Data. Singleton will not do this!
In fact, as Peter has pointed out, a Singleton Data will prevent you from extending your database to include additional tables in the future.
Hope this helps
Gennady Shapiro
Ranch Hand

Joined: Sep 25, 2001
Posts: 196
Thomas,
the way suncertify.db.Data is provided to us it opens file in "rw" mode so it automatically uses the db file exclusively, you don't need to worry about that.
However, if you leave it as is, an attempt by another thread to open the db will result in exception (which is a design choice), but if you choose a Singleton, another thread (perhaps a more sophisticated RMI server) will receive a good reference to this opened db file, now multiple servers (within single jvm) can talk to your database.
Plus singleton is better equiped to deal with failures and exception situations -- DB instantiation error handling becomes internal matter and can be handled better.
Also, singleton in itself does not stop you from extening your Data in any way, it's just a way of limiting instances of a class. I would like to hear arguments about this.
Again, this is a design choice. I happened to think Singleton here is very beneficial.
P.S. I always respect Peter's opinion but only God is infallible...and lately i am not so sure about that either.
Gennady Shapiro
Ranch Hand

Joined: Sep 25, 2001
Posts: 196
Anyway,
lets talk design patterns and their applications!!
Thomas Mathai
Greenhorn

Joined: Apr 01, 2001
Posts: 9
the way suncertify.db.Data is provided to us it opens file in "rw" mode so it automatically uses the db file exclusively, you don't need to worry about that.
However, if you leave it as is, an attempt by another thread to open the db will result in exception

Gennady:
Let me clarify what I said.
Let us assume there is one instance of Data associated with db.db. If you now create a second instance of Data (associated with db.db just like the first instance), we will then have two
instances both reading/writing db.db. This will create problems since there is no synchronization across them.
I do not think that an attempt to create a second instance will throw an exception as you appear to suggest. Correct me if I am wrong.
With a Singleton, you prevent the creation of a second instance of Data in the same JVM (but it will not prevent additional instantiations of Data from other JVMs).
Actually we WILL want to permit other instances of Data as long as each instance is reading/writing separate binary database files. Because each binary file is like a separate table in the
database. (There is only 1 table for this developer assignment.)
So what we really want to do is to ensure that at most one Data object is reading/writing db.db i.e. what we really want is a file lock.

[This message has been edited by Thomas Mathai (edited October 23, 2001).]
[This message has been edited by Thomas Mathai (edited October 23, 2001).]
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
I've got nothing to add to Thomas' words. It's been said numerous times that Singleton is one of the most abused design patterns around, and I tend to agree.
Use the Singleton pattern only when there is a fundamental, inherent reason why you cannot have more than one instance of a given class. The fact that you do not need or want more than one copy in a specific application is not good enough. What is true today will likely change tomorrow.
- Peter
Shivaji Bhosale
Ranch Hand

Joined: Mar 12, 2001
Posts: 70
I dont understand why you people concern regarding multiple instances of Data class.
After reading through I am feeling, Am I wrong, on my way of implementation?
I chose RMI as an implementation of an assignment. Here, in the server class of mine, I instantiate single instance of Data class & bind to the registry running at default port.
Methods needed for client are exposed in Data class only.
So client who looks to this registry will get the reference for Data object directly thr registry, no way getting of reference for some other Data object.
I feel do u guyz want to say, additionally, running registry, port other than default port ? Then having instantiating Data object & binding it to the registry ?
I am confused !
waiting for ur replies ...
Gennady Shapiro
Ranch Hand

Joined: Sep 25, 2001
Posts: 196
I am really not concerned all this much with Data and singleton. I just want to know if I missed a few well known design approaches.
For example, I was thinking of using Observer pattern for implement the status bar. At the end I decided against it because I don't want to over-complicate code with related overhead since there are many Observables and only one Observer, and it should be vice versa , just not worth the effort and added complexity.
Things like that. Design patterns. Anyone??
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Design Patterns ... again