• bvs23bkv33 (unregistered)

    comment = new Fristo();

  • Jaloopa (unregistered)

    People will notice this the frist time they try to use the doubly single singleton though

  • Little Bobby Tables (unregistered)

    "What? She dared accuse us of non-compliance? Grr! I'll see her non-compliance and raise her unnecessary-complication-with-the-specific-intention-of-confusing-everybody-and-making-her-look-stupid!"

  • (nodebb)

    Watermelon Project - Green on the outside, read on the inside.

  • James (unregistered)

    "That meant she could do the vast majority of her work in isolation, without talking too much to the existing team, so she did."

    There's TRWTF.

  • generallyagoodguy (unregistered)

    I don't know Java, but I wouldn't expect that hand rolled singleton implementation to be threadsafe.

  • (nodebb)

    Nothing like your code being revenge-fixed by the Brillant idiot who didn't like your review of their code.

  • Brian (unregistered)

    I've always viewed singletons as a code smell, and a pretty stinky one at that - it's just lipstick on a global variable, and a good indicator that you're not properly managing your encapsulation and interfaces. And now you're telling me there's a whole framework whose default scope is singleton? Yikes.

  • Angela Anuszewski (google)

    It's "stochastically", not "stochasticly".

  • Pierre (unregistered) in reply to Brian

    Nah the framework allows you to do it the right way by requesting to have the singleton injected in a constructor. You can also abuse the framework to bypass the injection and doing a request wherever you need it, yuck, I know that by experience from past projects I worked on. What a coincidence I spent yesterday removing one such singleton from an old software, everywhere there was AppControl.Instance.something. How nice to have a hidden dependency to a global variable in every class, be it a singleton.

  • Twither (unregistered) in reply to Brian

    Saying "Singletons are stinky" is TRWTF. Of course they can be misused, and probably are more often than not. Can all problems solved by singletons be solved without? Of course. But going out of your way to get rid of the singletons is the path of WTF. If singletons are the natural solution, lead to maintainable code, and the alternative leads to confusing and hard to understand code, the use the singleton.

  • Naomi (unregistered) in reply to Brian

    You have to understand the use cases. Maybe you're building a client for some web service, and that service requires you to authenticate before you can use it. Your connection to that service is global state that you'd want to encapsulate.

    However, the "classic" Singleton design pattern doesn't encapsulate it particularly well. If everything calls out to MyWebService.getInstance(), that's a dependency not only on the service, but on its singleton status. That's a problem. A more modern solution is so-called dependency injection:

    @Singleton
class MyWebService {

    @Inject MyWebService(/* dependencies... */) { /* ... */ }
    // ...
}

class SomeClientClass {

    private final MyWebService service;

    @Inject SomeClientClass(MyWebService service) {
        this.service = service;
    }
    // ...
}

    Now, in production, you let your DI framework materialize these objects for you. The architect knows the web service is a singleton. The client class doesn't. So, in your unit tests, you can construct the object manually, you can pass in mocks if you want to, and all those nice things.

    If at this point you're going, "hey, wait a minute, that's not a Singleton at all!", that's kind of my point! If you recognize that something does legitimately have shared state, and need an OO-friendly way to manage it, that's what these frameworks accomplish for you.

    By the way, if you don't find the web service example compelling, here are some other stateful things I've injected: a database connection, an executor service, a memoization cache, a pub/sub message queue, a user interface, and a filesystem wrapper. I'm sure you can see how those have to be shared state, and how it's good sense to abstract that away.

    Also, by the way, not all dependencies are singletons! That's just a common case/the relevant case right now!

  • Brittle Lobby Tables (unregistered)

    TRWTF is insisting on using the adverbial form of stochastic and then misspelling it.

  • (nodebb)

    I think the problem here isn't the singleton, rather the simpletons running the show.

  • Doubt (unregistered)

    Buttt..... Did it fix the problem!? Why would that fix the problem!? I am confused -_-'

  • Simon (unregistered) in reply to Brian

    "Singleton" is the default in Spring because they're also expecting those objects to be stateless... you don't need to constantly create and destroy instances if none of them hold data anyway. And if you do need to store state, that's where you need control over the scope anyway, and won't be relying on the default.

  • Little Bobby Tables (unregistered) in reply to Doubt

    Probably didn't, but the thought process very likely went:

    a) She can't get her code to work. Typical woman. She's obviously done something wrong.

    b) What!?!? Look at how she's tried to implement a singleton! That's rubbish! No longer her code won't work!

    c) There, fixed it. It's bound to work now. I'll check it in and watch her face as she puzzles out how her code suddenly works when it didn't yesterday.

    d) Aren't I the cleverest programmer in the company? Everybody else (especially the women) are to behold with awe.

  • Naomi (unregistered) in reply to Doubt

    It wouldn't fix anything. Actually, it's more likely to have the opposite effect. Spring won't know about getInstance() and getInstance() won't know about Spring, so they'll both create their own instance of the "singleton".

  • Naomi (unregistered) in reply to Little Bobby Tables

    If I had a dollar...

  • gnasher729 (unregistered) in reply to Brian

    I strongly believe that use of the term "code smell" is a real stinker. In relation to singletons, it's usually used by people who blindly follow a pattern without actually understanding it and confuse the pattern with a particular implementation.

  • Developer Dude (unregistered) in reply to generallyagoodguy

    Generally that isn't threadsafe.

    That is why, for years, since enums appeared, the standard practice for a Singleton in Java has been:

    public enum Singleton { INSTANCE; ... }

    Since enums are created by the class loaded and they are static, generally this is more thread safe. The only problem being if someone adds another enum instance.

  • Developer Dude (unregistered) in reply to Doubt

    TRWTF is that kind of implementation creates a problem instead of "fixing" one that doesn't exist.

  • Naomi (unregistered)

    That is why, for years, since enums appeared, the standard practice for a Singleton in Java has been:

    I don't know if I'd call the singleton enum pattern standard practice, but it is pretty cool. Especially since Java enums can implement interfaces, so you can hide the singleton nature from clients, if you want to.

    The only problem being if someone adds another enum instance.

    What's problematic about the doubleton pattern? :P

Leave a comment on “Newly Singleton”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article