Can I and is there a need to avoid singleton pattern?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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