I'm working on the implementation of the Bodgitt & Scarper assignment. The assignment provides an Interface called DBAccess that must be implemented by the Data class. There isn't any specification requirement prohibiting me from implementing the Data class as a Singleton, but if I implement the Data class as a Singleton, then the class constructor will be "private." This would prevent any automated test programs, used by the SCJD test evaluators, from externally instantiating my Data class in order to test it.
I know that I must explain my choice in the Choices.txt document before submitting my assignment.
Is there any bona fide reason that you know of that prevents me from implementing the Data class as a Singleton?
Like Carlos pointed already out I used a singleton and I got a pretty good score But I know your fear: I was also afraid of the "automatic failure", so when Roberto told me he used a singleton Data class too I was convinced that such an approach was just fine.
Harry Henriques wrote:Is there any bona fide reason that you know of that prevents me from implementing the Data class as a Singleton?
I only have positive experiences with that approach: it keeps your code very easy and simple (certainly if you combine it with just-synchronize-every-method). I don't have any regret doing it like that and if I had to do it again, I would opt again for the Singleton.
I used a sigleton for my Data class too. The primary logic for me anyway is to think the data file is like a database. It gets "shared" for network use so a singleton will make every users access the same instance.
Just to be on the safe side it would be reasonable to use Singleton not directly, but in combination with DAOFactory.
This approach gives you freedom to change an implementation of Data class instantiation without changes in clients code.
SCJP 6.0(95%), SCWCD 5(94%), SCJD (working on B&S v.2.3.1)