1

I'm writing a program where among lots of other stuff I need three classes we can call here writer, storage and reader.

Writer needs to access the storage class very very often while reader instead somewhat seldom especially compared to writer. Storage class is there only to store the data writer writes. The only thing the writer is doing, is just to write some short bursts of data quite often. The reader reads the written data from storage and then flushes the storage to free some space for the writer to write new data. To give some numbers and idea of the frequency of the accesses let's say that the writer is accessing the storage numerous times in minute and the reader is accessing it approximately once in an hour.

So the question is that do I need to use the singleton pattern in the storage class or is it enough to declare it as static class?

Also how I can ensure that when the reader class is using the storage, it releases the storage resource immediately after it has read and flushed the data from the storage? Most of the time the storage class should be available for the writer to write the data in it.

The singleton approach looks nice especially that I'm not from OOP background. I've heard that it's bad though.

zaplec
  • 1,681
  • 4
  • 23
  • 51
  • 1
    And to me, it more sounds like concurrency and synchronization problem. Besides that, proper use of constructors to create the objects is the first best choice. – nobeh Apr 12 '12 at 07:08
  • No, it's not a homework. I agree that this is also concurrency and synchronization problem, though there's only this rare moment where I need to make sure that writer and reader are not accessing the storage at the same time. Therefore I would also like to make sure that the reader executes as fast as possible. Notice that the reader needs to do that flush operation that is actually writing (unless there's a way to flush without writing). – zaplec Apr 12 '12 at 07:16
  • I suggest taking a look at different options at [java.util.concurrent.locks](http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/package-summary.html) – nobeh Apr 12 '12 at 07:21

3 Answers3

2

As always with these kinds of questions, I don't think there is a single correct answer.

First, there is already a very good answer to that question.

The typical implement of the singleton pattern relies on a static field that contains the one and only instance of that class. I don't like this approach at all because the static field is essentially a global variable with all its disadvantages (e.g. hidden dependencies and risk for increased coupling, detrimental to testability).

But the more general idea of a singleton in the sense that you only want a single instance of the class in your application is probably a good idea in the scenario you describe. However, rather than magically accessing it via a static variable I would pass it to the constructor of the class that is using it. That way, the dependencies between the classes are obvious and it will simplify testing (e.g. if you want to inject a mock rather than the real class). See here for more benefits on constructor injection.

Community
  • 1
  • 1
weberste
  • 1,884
  • 2
  • 17
  • 12
0

do I need to use the singleton pattern in the storage class or is it enough to declare it as static class?

These are unrelated questions.
Singleton is about how many instances of a class you are supposed to have.
Using singleton you enforce only 1 instance in your program.
If this is what you need then use a singleton.
For the rest you should read about producer/consumer pattern

Cratylus
  • 52,998
  • 69
  • 209
  • 339
0

Basically, singleton is pretty much the same as a static class. Both are bad and good in same circumstances, but singleton is more "object-orienty". In a prototype-based language, there is no real distinction.

Singletons get a bad rep because a lot of people are using them as a replacement for global variables (which now everyone "knows" are bad). Used this way, singletons are equally bad as global variables. Use a singleton if it really models an object which you are provably certain only has one instance. If it even theoretically may have another instance in a future, or if it doesn't model something specific, the singleton pattern should not be used - nor should a static class.

All this has nothing to do with your reader/writer problem; one is, as comments indicate, a producer/consumer pattern, or an observer pattern (depending how you implement it). The other is the basic object oriented design issue.

Amadan
  • 191,408
  • 23
  • 240
  • 301
  • The storage class is used somewhat as a huge global variable. The reader class needs quite a lot of memory and it's used about once in an hour, so writing directly in it is not an option. Then there are some cases where the writer class is destroyed or stopped, but the data should be available whenever the reader needs it, so that's why I thought that data should be written in it's own class that exists as long as the program is up and running. – zaplec Apr 12 '12 at 07:34