This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
I had been rambling through some literature on java design patterns and what people think about them and how they put it to their practical use.
Some developers argue that Singleton patterns are bad. Every single explanation I saw, the argument is shown as they really wrote a bad use case out of the pattern.
For eg having a singleton object as a global state. Well here I dont see a problem in having a global state, but the problem is using this global state to hold objects that secretly holds objects over a algorithm/flow sequence using an API. Well here the blame goes really with the API not the pattern.
There is argument saying it is considered a good code, only if its impossible to write a bad code around it. I dont think that is really practically achievable. Its almost impossible to achieve it....only we can do our best to minimize bad code around our code. Just because its possible to write bad code in Java....we dont blame Java language as a whole.
I agree with you but would like to add more to what you have stated:
Decisions like a class being singleton or not are taken at design time and with frameworks like Spring. Designers need to worry less on that part. Even the use of factory design pattern has decreased because of Dependency Injection (DI).
Well I started this thread exactly after reading google's article. This is completely absurd. They said singleton's are hard to test due to in-extractibly coupled.
Then they even proposed a solution to to pass in the singleton as a parameter in the user's constructor, allowing a tester to easily mock out the singleton for test.
I didnt get why then is Singleton a problem...where there is indeed a solution to the proposed problem?.And I also think its practically impossible to test a class on its own in all scenarious. Classes do interact to perform a logic, in which case at some point, we will hit the wall that we need to test classes with instance of another class composed.
I think the argument is purely a personal preference rather than a best practice principle.
The concept of object-oriented design patterns are created for and appropriate for large-scale computing systems created by multiple individuals and groups. They are design guides and help with the design process, and when implemented, help with communications between "humans" working on the system today and those to possibly join in the future.
That said, most Java-based large-scale systems are distributed applications running on multiple JRE and using many different resources. The Simpleton design pattern is problematic, anti-object-oriented and is best used as a teaching concept in undergraduate college courses. In the real-world, the Simpleton should be avoided, and when used is typically a sign on someone not initiated in the arts of software engineering.
Joined: Mar 11, 2009
Thanks for that Jimmy. Thats valuable.
Just to confirm do you mean Singleton or Simpleton(which I am not aware of).
Jimmy Clark wrote:
The Simpleton design pattern is problematic, anti-object-oriented
Can you provide some conceptual reasoning for it.
Can you please provide a backing example?. I have read a lot of example out there but nothing really a strong reason to avoid them as a whole. I just understand them as a unique cases where singleton is not the right choice...or at least the way they are implemented. They made singleton as a choice and when having problems I felt cant blame singleton pattern. That said I am only getting in to junior architechting roles, so before I ridicule the use of singletons,just want to convince myself with every reason to abandon them.
Joined: Apr 16, 2008
The Simpleton design pattern is based on the concept of restricting instantiation of a particular class to a limited number of instances. It could be one instance, it could be three instances, it could be ten, etc. The most important aspect here is the class, what is does, what functionality it executes, and what data it contains, and what role does this data and functionality have in the system. None of these things are specified in the design pattern. These are all implementation details.
Historically, the design pattern has been implemented in ways that create bottlenecks stemming from the "restrictions" and/or access control to needed resources. When designing applications that will execute on multiple JVMS, there are better ways to design without depending upon "restricting instantiation of a particular class to a limited number of instances."
Simpleton implementations are best applied for very small applications executing on a single JVM with simple logic and simple data structures, e.g. school assignments.
Again, everything really depends upon the data and the logic of the class. This varies from application to application. Whether it is a problem or not will depend upon these factors. Whether it will turn into a problem in the future depends on these factors.
When and if you start to develop deep software design skills, you will start to see better ways to coordinate your objects and shy away from thinking like a Simpleton