• Prime Mover (unregistered)

    "The result is, instead of guaranteeing that instance of an object exists (because there can be only one), and just create broad globals."

    Come again?

  • Brian (unregistered)

    /** * @return Returns true always. */ public boolean isSingleton() { return false; }

    Returns true ... always ... ehrm, no ....

  • Prime Mover (unregistered) in reply to Brian

    (snigger) I lied!

  • RLB (unregistered)

    The only good Singleton is (was, alas) Mike.

  • MaxiTB (unregistered)

    Someone doesn't really know how IoC works, if they need a method on a object called isSingleton() lol

  • (nodebb)

    I hope that this is just due to someone taking old Spring code and not quite understanding it. You don't do it that way now anyway, as Spring's better at building factories and managing calling all that basic stuff than you are; often all you need to supply is a method that can actually build the object (for a class you don't fully control, like a thread pool) or mark the class for being managed that way (for your own code).

  • (nodebb)

    Plenty of WTF... but largely due to missing details in the article.....

    Consider a factory that returns an instance by interface. I mat be a custom instance (you are the only reference as of the point of return), or it may be a shared instance [Highlander!]... Knowing this may make functional decisions later on.

    As to singletons themselves, my peeve is when it is done internal to the class rather than external... Consider a Printer class with a "GetInstance) static that returns a printer... This indicates that there is only one printer in the universe. More accurately many printers may exist, but only one may be used by the application. Therefore the singleton represents THAT printer, not the printer class.

  • Michael R (unregistered)

    Did George run a git blame to check if the committer was Paula?

  • RussellF (unregistered) in reply to Prime Mover

    I think there's a "one" missing between "that" and "instance"

  • Teodor Potancok (github)

    Java at its finest. Such enterprise!

  • NotAThingThatHappens (unregistered)

    I have built my share of Singletons in my days. I have also converted many of Singletons into instance classes.

    Reason. The golden role of life: The only constant is change. The golden role of programming: Everything always grows

    In my experience, a Singleton is just too fixed to accommodate these realities.

  • Kay (unregistered)

    That actually looks very much like ThreadPoolExecutorFactoryBean has originally been written for an old version of the Spring dependency injection framework (https://spring.io/projects/spring-framework). Spring manages instance creation, initialization and caching of the result of its single call to getObject() - the factory code doesn't need to worry about anything regarding singleton pattern. Of course using such a factory outside of Spring feels totally awkward, because the boilerplate services provided by Spring are missing ...

  • (nodebb)

    My own view is that the Singleton pattern is in almost all cases a solution looking for a problem.

    The idea of an object we only need one of is fair enough, but the idea of an object of which we can only have one is a strong red herring. (It's not completely unheard of, but as in the example of a Printer class that TheCPUWizard cites, it is often thought of as interesting / important when it isn't even correct.)

  • Yikes (unregistered) in reply to Kay

    So you're saying, "If you liked it then you should have put some String on it" ?

  • (nodebb)

    @Steve_The_Cynic - What I do find quite useful is the idea of what is sometimes called the "Keyed Singleton Pattern, where there can be only one instance of an object type with a given (obviously unique) key value. When combined with a time/version element on the key, and a few other bells, it creates solutions that reliable scale and expand....

  • General Akbar (unregistered) in reply to TheCPUWizard

    "Keyed Singleton Pattern"???

    That's a Map !!!

  • (nodebb) in reply to Kay

    Indeed, this is the "old way" of making a configurable Spring bean - and to go with this, you'd have an xml structure setting the properties and you'd just have the pool available in the application context. The isSingleton() method is also part of the interface for the BeanFactory.

    Today, this seems outdated (and it is, seriously, it's been a decade!) but still works, albeit a little clunky outside of Spring.

    https://www.baeldung.com/spring-beanfactory

    Not a wtf, just old code.

    Addendum 2022-07-06 05:23: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/BeanFactory.html says

    Since: 13 April 2001

    So, 2 decades!

  • SG (unregistered)

    What Remy and George are missing is that it's a Spring factory class. It's not meant to be called by a developer writing Java code - the framework reads an XML descriptor, creates the class, sets the properties, and calls afterPropertiesSet to let the class instantiate itself... standard Spring behaviour (if somewhat old-school using XML these days). The getObject method is the bit that actually does something after the factory object has been fully initialised by the Spring container.

    As to the isSingleton() method, the purpose is to indicate whether the factory class is guaranteed to always return the same instance on every call... which again, is part of the framework metadata tracking.

    So apart from the dodgy comment, there simply isn't a WTF here... it's completely normal code from the internals of a dependency inversion framework. You'd never write code like the usage example, because the sole purpose of this code is to enable Spring to automatically supply a thread pool without interacting with the factory.

  • (nodebb)

    @SG -- Thank you for your second paragraph, confirming what I said earlier in my second paragraph! synergy for the win!!!

  • I'm not a robot (unregistered) in reply to welcor
    https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/BeanFactory.html says

    Since: 13 April 2001

    So, 2 decades!

    If you're arguing that they shouldn't be using BeanFactory because it's obsolete, then it doesn't matter how old BeanFactory itself is - you should be pointing out when the preferred alternative became available.

  • (nodebb) in reply to I'm not a robot

    You are technically correct, and we all know that is the best kind of correct ;)

    The option to not use xml for configuration of spring beans was added in 2007, in spring 2.5. https://spring.io/blog/2007/11/19/spring-framework-2-5-released I would argue that it wasn't a good substitute until spring 3.0, in 2009 - the first couple of years saw a lot of fixed bugs on the annotations.

    So, my original estimate of a decade holds up :D

Leave a comment on “All the Single Objects”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article