3 ms·

You have highlighted the good parts about using singletons. Now say your application wanted to play two different music streams (lets pretend you added a mix fe

by robmcm 13y ago

You have highlighted the good parts about using singletons. Now say your application wanted to play two different music streams (lets pretend you added a mix feature), you are now stumped. I first ran into the pain of singletons when using them in a framework. This framework formed the bases for small modules, which when loaded together into the same application domain blew up. My solution was to use IOC/DI. I could still have singletons , but they are just instanced managed by the container. This mean I am not relying on static values for state, which in my view is as bad as global variables. I guess this is really the problem most people associate with the singleton model, not that there is a single instance in your application, but that typically people use static variables to store the instance.

sdegutis 13y ago
> you are now stumped No, I just refactor my code to not use a singleton anymore. This only involves deleting the static accessor, adding a few properties, and passing a value downward. It would take all of 5 minutes. I don't see any value in designing my architecture around a feature I might never add.
- robmcm 13y ago
  I depends on the complexity of your application, sure it could be easy, it could also be a nightmare. People make the same arguments about using interfaces (think Java not Objective-C ones), they are only useful when you need them, but almost all of the time it's easier to do it in advance than at a later date. At the end of the day it's your call as the architect of your application. If you can convince yourself using a singleton is a better fit that another method go for it, chances are you'll know your application better than a one of the GOF. If it then trips you up down the line, you learn from it and revise your thinking the next time you face this problem.
- deleted 13y ago
  [deleted]
- bradenb 13y ago
  If it's a simple 5 minute change, why not implement it and use DI for a single instance? I imagine you would save a good amount of time by being able to run automated tests now rather than the manual tests you described in your other reply.
  - sdegutis 13y ago
    Apple makes it notoriously hard to do any kind of testing for ObjC/Cocoa apps, especially testing the GUI [1]. My solution is to only write really tiny apps, and manually test them. I still use TDD, I just make sure the app is small enough that the regression suite can be done manually in a minute or two. [1]: I'm aware of third party solutions like Kiwi and Cedar, but I haven't found them to make this process much more pleasant than the built-in tools. Apple is really just an overbearing mom in this case, forcing you to use the sweater she chooses, and making life difficult if you don't.

by robmcm 13y ago

sdegutis 13y ago

> you are now stumped No, I just refactor my code to not use a singleton anymore. This only involves deleting the static accessor, adding a few properties, and passing a value downward. It would take all of 5 minutes. I don't see any value in designing my architecture around a feature I might never add.

robmcm 13y ago
I depends on the complexity of your application, sure it could be easy, it could also be a nightmare. People make the same arguments about using interfaces (think Java not Objective-C ones), they are only useful when you need them, but almost all of the time it's easier to do it in advance than at a later date. At the end of the day it's your call as the architect of your application. If you can convince yourself using a singleton is a better fit that another method go for it, chances are you'll know your application better than a one of the GOF. If it then trips you up down the line, you learn from it and revise your thinking the next time you face this problem.
deleted 13y ago
[deleted]
bradenb 13y ago
If it's a simple 5 minute change, why not implement it and use DI for a single instance? I imagine you would save a good amount of time by being able to run automated tests now rather than the manual tests you described in your other reply.
- sdegutis 13y ago
  Apple makes it notoriously hard to do any kind of testing for ObjC/Cocoa apps, especially testing the GUI [1]. My solution is to only write really tiny apps, and manually test them. I still use TDD, I just make sure the app is small enough that the regression suite can be done manually in a minute or two. [1]: I'm aware of third party solutions like Kiwi and Cedar, but I haven't found them to make this process much more pleasant than the built-in tools. Apple is really just an overbearing mom in this case, forcing you to use the sweater she chooses, and making life difficult if you don't.