Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@stacked interesting idea. It might work.
We could also name our new process AD: appropriately designed. That might also convince them to use it -
@devios1 and I have. I’ve chosen to not reply to the email for a few days, for everyone’s sake.
... may god help his poor soul if he brings it up on the Scrum call today -
@practiseSafeHex @stacked might be onto something though. If it’s just the word that scares him (what else could it be—singletons are not scary) maybe just calling it by what it is would alleviate his fear.
Sadly this kind of catering to bosses’ (lack of) understanding is all too common in my experience. -
@beegC0de You can use singleton patterns in most, if not all, languages. Some languages makes you jump through more hoops to do so than others though.
It's surprisingly prevalent actually, just take a look at front-end state machines like Redux and the one in Angular or even just jQuery. Sure, they may implement it in a way that does not look like a singleton, but to you as the consumer, all you have is a single instance of a global object to manipulate.
If it quacks... 😊
The singleton gets it's bad reputation mostly from being a global object accessed from everywhere by everything, but using IoC, interfaces/contracts and similar techniques you can at lest reduce the impact of the down side.
Another example for you: A database connection that is heavy to open (login handshakes etc) could be better to pass around as a singleton rather than reopening for every read or write. Sure, some libraries/ORMs or languages help you a lot here, but there will be edge cases. -
@beegC0de depends how you build it to get at it, and what safeguards against duplication you build in. If the connection object is buildt in such a way that there will only ever be one instance, regardless of how you pass it around or access it, I'd call that a singleton.
It makes sense to create that safeguard, even if you don't plan to just global the shit out of it, to make sure 😊 -
@beegC0de as Hakash said, no a singleton is just a concept. It might be implemented in different ways, but it can be achieved in any language (that I know of).
Its simply a class that holds a reference / pointer / static variable to an instance of its own type. When you instantiate a new instance of the class, you get the same instance back each time.
Many people have an irrational hatred of them, as they feel they are over used or are a bad answer to doing something another way. Personally I don't see the issue in using them to a limited degree, particularly for storing state, or as Hakash pointed out, something big / heavy like a DB connection.
A DB connection is not always a singleton, but its common for it to be implemented / wrapped up as one to avoid having it in many places throughout the code. -
@beggarboy
FOLLOW UP TO STORY:
Them: Singletons are terrible and an anti-pattern. They cause developers to do X and they suck at Y. We should never use them.
Me: I'm adding push notifications and this business logic and state needs to be in 10+ random places throughout the app, can I use a singleton?
Them: Yeah sure that makes sense.
Implementing the application exactly like the client specified, because they won't listen.
Life of Programmer
Me: Oh I see were using a non-standard architecture on this app. I like this bit but what is this doing? never seen it before.
Him: Ah we use that to abstract the navigation layer.
Me: oh ok, interesting idea, but that means we need an extra file per screen + 1 per module. We also can't use this inbuilt control, which I really like, and we've to write a tonne of code to avoid that.
Him: Yeah we wanted to take a new approach to fix X, this is what we came up with. Were not 100% happy with it. Do you have any ideas?
**
Queue really long, multi-day architecture discussion. Lots of interesting points, neither side being precious or childish in anyway. Was honestly fantastic.
**
Me: So after researching your last email a bit, I think I found a happy middle ground. If we turn X into a singleton, we can store the state its generating inside itself. We can go back to using the in-built navigation control and have the data being fetched like Y. If you want to keep your dependency injection stuff, we can copy the Angular services approach and inject the singletons instead of all of these things. That means we can delete the entire layer Z.
Even with the app only having 25% of the screens, we could delete like 30+ files, and still have the architecture, at a high level, identical and textbook MVVM.
Him: singleton? no I don't like those, best off keeping it the way it is.
... are you fucking kidding me? You've reinvented probably 3 wheels, doubled the code in the app and forced us to take ownership of something the system handles ... but a singleton is a bad idea? ... based off no concrete evidence or facts, but a personal opinion.
... your face is a bad idea
rant
your face
singletons
architecture
decisions