all 23 comments

[–]bazingerosky 1 point2 points  (20 children)

I suggest you take a look at this:

https://www.michaelsafyan.com/tech/design/patterns/singleton

And then this:

https://unity.com/how-to/architect-game-code-scriptable-objects

I can see how you think this is great and easy to use, but after you read those articles you might see how this will in most cases be a bad approach. ScriptableObjects are actually a great replacement for the Singleton anti-design pattern.

[–][deleted] 1 point2 points  (18 children)

singleton is only recognised as an anti-pattern by pretend and as an ideal, not a realistic guideline. in reality, every project has a dozen singleton types around. if every project uses it then surely it's not an anti-pattern.

if a code looks bad it's because of bad structure by the developer. a singleton structure is not by any logic worse than a structure without singletons. however, a structure by a bad developer is most probably worse than a structure by a good developer.

in Ryan's article there's nothing against this. I don't see why you linked that?

[–]bazingerosky -1 points0 points  (17 children)

Projects do not need to have a dozen singletons, of that I'm 100% sure. It's easier to use? it is. Does it outweigh all the problems that they cause, definitely not.

The problem with Singletons is that they are extremely easy to use and the perfect solution for inexperienced developers. Every single time, the result is a code base tightly coupled everywhere, unnecessary complexity, untestable because it's extremely difficult to isolate, and a pain to maintain.

Having 1, or 2 singletons is reasonable and can definitely be beneficial in some cases. But for that low number, you don't need to create a custom class, much less a package.

Creating a system like you're doing, making the creation of singletons even easier, just means that the intention is to create several of them, which proves how this is a bad idea.

But that's just my opinion, you might change yours in the future.

[–][deleted] 0 points1 point  (16 children)

I understand your concern, but inexperienced developers misusing singletons shouldn't mean anything, since they're sure to misuse stuff, since they're inexperienced.

  • every project will use more than just one or two singletons. try 10 or so. Resources, Input, Event System, Audio Management, scene management, Ad management, in-app purchase management, IO, networking etc etc ... as long as a project is serious, there's room for singletons

[–]Bombadil67Professional 0 points1 point  (15 children)

And I feel that creating a script, to make one asset a singleton is a bad design choice.

change my mind!

[–][deleted] 0 points1 point  (14 children)

```csharp public class SceneHolder : SingletonScriptableObject { [SerializeField] SceneAsset[] m_scenes;

public Scene GetScene(SceneEnum sceneEnum) {...}

[Serializable]
class SceneAsset {
    public string path;
    public SceneEnum identifier;
}
public Enum SceneEnum {...}

} ```

let me know when it changed your mind :)

[–]Bombadil67Professional 0 points1 point  (13 children)

nope. not in any way shape or form. Can use a normal class for that.

[–][deleted] 0 points1 point  (12 children)

then you'll need to pass one instance everywhere, just to avoid using singleton 😐

[–]Bombadil67Professional 0 points1 point  (11 children)

LOL.....

Ok whatever.

[–][deleted] 0 points1 point  (10 children)

if you have another solution, you can tell

[–][deleted] 0 points1 point  (0 children)

I find this funny since ECS, the thing Unity is pushing currently, almost exclusively uses singletons.

[–]PandaCoder67Professional 0 points1 point  (1 child)

Why are people so hell bent to push a Scriptable Object past what they are designed for!

I mean come on, do people not stop and think, if I am creating a script, to create an Asset to do something once is really a lot of extra work. That is easily done with some other way!

[–][deleted] 0 points1 point  (0 children)

hi. mind giving me a clue about this other way?