Podcast

Episode 73: Design Patterns: Singleton

Hello, Debuggers. In today’s episode, we continue our series about design patterns with one of the most polemic design patterns of all, Singleton. We explain when you might want to use a Singleton, we go over the definition of this design pattern, we talk about two very common definitions, and finally, we go over some of the reasons why people do not like to use Singletons.

Thanks for tuning in this week and we hope you enjoy the show! Contact us at: thedebuglog@gmail.com

Download Here

Take a second to support The Debug Log on Patreon!
Previous post

Episode 72: A Master Study in Content Design with Joshua Herbert and Benjamin Gross

Next post

Episode 74: From Gamer to Game Developer with Zack Schneider

3 Comments

  1. Rory
    May 3, 2017 at 6:31 am — Reply

    Great episode guys.

    That being said, I am not a fan of singletons. I will leave my opinion at that.

    One thing tho is in this episode you were discussing getting into the unity mindset and using the game objects and mono behaviors. One thing I have not heard you discuss which is a hugely useful tool is scriptable objects. Personally, I use them to get around a lot of what unity does very inefficiently. It’s a deep topic though, easily an episode.

    Keep it up guys Lots of great content here. I recommend Debug log to everyone I mentor.

    • May 3, 2017 at 8:22 am — Reply

      Hey!

      I completely agree about the ScriptableObject. They are something of a Godsend in certain situations during Unity development and would make for a good technical episode for the show.

      Thanks for the feedback and suggestion!

  2. Lucas
    May 7, 2017 at 4:04 am — Reply

    Thanks for touching at that very controversial topic.

    I think one of the reasons why the singleton pattern is so disliked, is because, put in the wrong hands of an inexperienced developer, it will pretty much cause the same havoc as global variables does in any kind of software development.

    You should limit the use of it to maybe one or two instances in your code, going over, it will pretty much be unmaintainable at that point.

    Singletons are useful in cases where the instance really needs to be available and part of the code at all times and where other patterns applied cannot “solve the puzzle”
    However I like to abstract the logic of the specific singleton into a separate static class that is e.g. a GameManagerLogic – in that way there is only one reference to the singleton itself and the logic is encapsulated in a class by itself.
    The singleton itself can even be a SingletonBase class (so that you can do other singleton implementations if needed for e.g. a AudioManager)

    This is just due to have separation of concerns such that you do not unnecessarily interfere with the singleton’s base code, and can safely do your operations within a static class without much interference. It also helps that the logic that is just strictly regarding game management is encapsulated and you can really modify it to your needs or extend it if you so wish.

    As Rory also mentioned, a really good thing to get used to is utilising ScriptableObject’s (they are simply awesome) – as they are simple data containers and holders that can potentially also be data manipulators / classes – so they can fit whatever purpose that data needs (an inventory manager, weapon entity etc.)

    I would recommend you guys to look into the pattern of ECS (this is one that I am utilising) – as it clearly separates the concerns of the code into chunks that are very manageable, and one that can be used with great reusability throughout the code.

    Otherwise great episode keep on looking into more patterns :)

Leave a reply

Your email address will not be published. Required fields are marked *