koobas.hobune.stream
Why would someone choose to use a namespace rather than a singleton model?
I've been trying to find something that will create an sqlite database on android. I finally found something! It's from Krueger Systems. Looking over the code, they are using a namespace that is included in another script so it can run properly. I'm curious why someone would do that over making a singleton with all the database commands. Does it work better on other platforms? Or is it just a higher level of programming? Thanks!
Namespaces protects the class name collisions. In the custom namespace you can call calsses as you want.
Using a namespace and singleton pattern are very different things.
A namespace is generally just a way to organize/isolate the na$$anonymous$$g of classes, etc. so that there is not a conflict with other na$$anonymous$$g conventions in the same assembly.
Singleton pattern is where you impose a class invariant where there should only ever be one instance of a class at any given time. It is a global state that can be easily "reset" by instantiating a new instance of its class.
Can you be more specific about what exactly you mean by namespaces compared to singleton pattern?
Namespace:
namespace SQLite4Unity3d
{
public class SQLiteException : Exception
{
public SQLite3.Result Result { get; private set; }
protected SQLiteException (SQLite3.Result r,string message) : base(message)
{
Result = r;
}
public static SQLiteException New (SQLite3.Result r, string message)
{
return new SQLiteException (r, message);
}
}
public class NotNullConstraintViolationException : SQLiteException
{
public IEnumerable<Table$$anonymous$$apping.Column> Columns { get; protected set; }
protected NotNullConstraintViolationException (SQLite3.Result r, string message)
: this (r, message, null, null)
{
}
etc...
Database $$anonymous$$anager private static Database$$anonymous$$anager _instance;
public static Database$$anonymous$$anager Instance
{
get
{
if (_instance == null)
{
GameObject DB$$anonymous$$ = new GameObject("Database$$anonymous$$anager");
_instance = DB$$anonymous$$.AddComponent<Database$$anonymous$$anager>();
}
return _instance;
}
}
etc...
private static Database$$anonymous$$anager _instance;
public static Database$$anonymous$$anager Instance
{
get
{
if (_instance == null)
{
GameObject DB$$anonymous$$ = new GameObject("Database$$anonymous$$anager");
_instance = DB$$anonymous$$.AddComponent<Database$$anonymous$$anager>();
}
return _instance;
}
}
etc... which has all the database functions.
It's a bit like asking why someone would drive a car ins$$anonymous$$d of using a fork to eat.
All classes belong to a namespace. If you dont define one for your class, the class belongs to the global namespace. All unity classes belong to UnityEngine or UnityEditor namespaces. What namespace a class belongs to doesn't encourage or prevent you from using a singleton pattern when constructing instances of it.
Why someone wouldn't use a singleton pattern? Answering that would require quite an extensive knowledge of said API and how it's intwnded to be used.
One thing that comes to $$anonymous$$d is: if your program accesses multiple different databases and you need to have different instances of the DB handling classes for each DB, singleton pattern might not be a good choice. Or if the code runs on a server where multiple users have sessions accessing the DB concurrently, one singleton for all to share might not be the bestvway to go.
It's difficult to answer as a namespace and a singleton are two totally different things.
Putting things in namespaces is useful when you want to create frameworks that you want to use in different projects, and it allows you to avoid name conflicts.
If you want to gather static members and methods that do not need MonoBehaviour specific stuff, such as Coroutine, Update, etc. then you can create a static class with static members and static methods that will be available at all times.
If you need MonoBehaviour specifics, then you can create a Singleton pattern, which allows you to find/create/reference the unique instance at any given time.
It's because there is no particular reason to make the database classes into a singleton. In fact, there's little reason to use singleton pattern in the first place. Singletons may seem to make code easier to use on the surface, but quickly add needless and unavoidable dependency to everything referencing them, creating restrictive and hard-to-test code.
My recommendation is simply pass the database connection / manager resource to the components that need it (in the editor or at runtime). You should be able to assign the database manager field on the dependent behavior component in the Unity inspector editor window. Alternatively, there are numerous ways to have the dependent components locate the database manager in Unity at runtime or in the editor, like calling FindGameObjectsWithTag() and`GetComponent()` or FindObjectsOfType() (but do this sparingly, like once in Start(), etc.)
In this case, it might make sense or would be fine to have a static instance of the non-component database class in your own source file. A static instance is not a singleton unless it follows the singleton pattern. But I would avoid global state as much as possible.
