Originally posted by Gustavo Adolpho Bonesso:
One real example could be a School, were you have only one Director... The class Director (could extends Employee with others attributes) can use the Singleton Pattern to determine that only one Director will be instantiate...
This is actually a perfect example of reduced reusability as a consequence of Singleton being used where it shouldn't. School 'has a' Director. That means School contains a member variable referencing a Director; no Singleton is needed here.
If you create these classes for academic organization 'A', and wanted them to be re-used by academic organization 'B', you could find that 'B' is an institution consisting of multiple things they call 'School' (yes, there are such places), each with its own 'Director'. Use of the Singleton pattern would force all of the schools to have the exact same Director!
The situation would be even worse with an example from the corporate world. In many organizations, a 'Department' would have a single director. A change in management style could result in a matrix-managed organization where you have 2 or more directors per department.
Singleton is at its best when it is managing access to some resource external to your program. Then you can't really "create" more of those resources in your code, you can only use what truly exists in physical reality. Examples might be the windowing system for your computer, a database connection that doesn't support concurrent access from multiple clients (older ODBC versions), etc.
[ June 07, 2002: Message edited by: Reid M. Pinchback ]