SCJD Book page 138 - Singleton question

[Keith Nagle]

Hi there. I am working through the great SCJD book by Andrew Monkhouse & Terry Camerlengo.
Unfortunately I have run into something that I can't make sense of!

On page 138, a decision is made to [b]not[b] make the DVDFileAccess class a singleton.
The issue is that I'm having trouble figuring out why this decision was made. It's not entirely clear to me.
The decision is based around 2 points:

The first states that a lot of work can be performed in parallel if multiple clients are working on a CPU system.
Am I correct in stating that based on this point, it doesn't make sense for this class to be a singleton as
in a multi-threaded environment this singleton instance would be acting as a mutex??

The second point states that if DVDFileAccess was made a singleton, then any class that leverages the
DVDFileAccess class would have to be coded differently. My question is why? It's not clear to me.

If anyone can clear up these two points, I would really appreciate it!

Many thanks & Regards

[Carlos Morillo]

Hi Keith,

I would strongly suggest and recommend that you read the book "Head First Design Patterns"
by Eric and Elisabeth Freeman and take a look at the Singleton, Factory, Facade and Adapter patterns.

Not sure if you already got your assignment instructions from Sun-Oracle but keep in mind that
in the Monkhouse book like in the SCJD assignment we are given an interface to be implemented by
a Data class.

In Denny's DVDs you have the DvdDatabase class that implements DBClient is a facade and an adapter.
Using composition this facade has a DvdFileAccess and a ReservationsManager.

To make the DvdDatabase class thread safe the authors chose to use a synchronized block when they seek()
and read()/write() to/from the RandomAccessFile and they are also choosing to use the java.util.concurrent API
which in my view is more complex at the time of extend functionality and maintain the code by a junior developer.
The authors did that on purpose.

Yes, the Data class implementing the interface provided by Sun needs to support requests from multiple clients.
How you implement it and solve it it's up to you as long as you justify it clearly why you decided your design choices
in choices.txt.

I did make my Data class a Singleton with synchronized public methods because in my view it is the simplest and easiest
approach and the easiest for a junior developer to extend and maintain as compared to the java.util.concurrent API.

HTH,

Carlos.

[Roel De Nijs]

Carlos Morillo wrote:I did make my Data class a Singleton with synchronized public methods because in my view it is the simplest and easiest
approach and the easiest for a junior developer to extend and maintain as compared to the java.util.concurrent API.

I agree completely

[Keith Nagle]

Excellent guys will take a look at the singleton pattern in more detail. I should've done this in the first place!
Thanks again.

P.S. Congrats on your SCJD score Roel - really impressive! ;)