X-Received: by 10.224.175.65 with SMTP id w1mr13949470qaz.7.1360098608610; Tue, 05 Feb 2013 13:10:08 -0800 (PST) X-Received: by 10.49.60.40 with SMTP id e8mr2257967qer.40.1360098608371; Tue, 05 Feb 2013 13:10:08 -0800 (PST) Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!p13no13622057qai.0!news-out.google.com!k2ni8440qap.0!nntp.google.com!p13no13622050qai.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.java.programmer Date: Tue, 5 Feb 2013 13:10:08 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.28.149.29; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T NNTP-Posting-Host: 69.28.149.29 References: <3c0d69c3-591d-4d99-8c13-30a0fd1684b3@googlegroups.com> <68pyk4ua9x9m.1nm4lckdwgp86.dlg@40tude.net> <51106eff$0$293$14726298@news.sunsite.dk> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <120b95db-a9a3-4580-9754-46426453280c@googlegroups.com> Subject: Re: Design Patterns From: Lew Injection-Date: Tue, 05 Feb 2013 21:10:08 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: csiph.com comp.lang.java.programmer:22126 Stefan Ram wrote: > Eric Sosman writes: >> A singleton class can be transformed into an uninstantiable >> class having only static methods. > > Static methods cannot be passed via reference or used to Do you mean "via a reference to their owning instance"? > implement interfaces. Therefore, there is a need for > non-static methods sometimes. But this does not mean a > singleton, I am thinking of a POJO first and foremost > until someone shows me where a POJO does not suffices, > but a singleton is needed. Most of the time, at least, it suffices to have only one instance of a class where otherwise one might be tempted to implement a Singleton. I have a strong bias toward using instance methods over static methods, in part because they can implement an interface method. It does not suffice that the method merely doesn't access instance state. It also needs to be "global" by design. Instance methods can be easier to control in multi-threaded contexts. It's often good to have a manager instance that controls the methods so that different units can use them independently. If you later decide that "singleton" was a mistake, instance methods don't need to be refactored. There's also a circular analysis where type state is maintained in mutable static variables, so one creates static methods on the theory that they don't access instance state. The risk of mistake with instance methods is lower than with static methods. So if I have a compelling argument for making a method static, fine, but tie or a close second goes to the instance implementation. -- Lew