#Is this a good way to organize namespaces and classes?

1 messages · Page 1 of 1 (latest)

cold mesa
#

Hi everyone wanted to know is organizing namespaces and classes like this is a good approach, or are there any limitations to this method -

CompanyName.Shared.Mcq
    - McqManager.cs
    - McqData.cs

CompanyName.Game.ActOne
    - LevelManager.cs (inherits CompanyName.Shared.Mcq.McqManager)
    - QuestionPanel.cs (inherits CompanyName.Shared.Mcq.McqData)

CompanyName.Game.ActOne
    - LevelManager.cs (inherits CompanyName.Shared.Mcq.McqManager)
    - QuestionPanel.cs (inherits CompanyName.Shared.Mcq.McqData)

CompanyName.Game.ActThree
    - LevelManager.cs (inherits CompanyName.Shared.Mcq.McqManager)
    - QuestionPanel.cs (inherits CompanyName.Shared.Mcq.McqData)
#

You may want to copy this in a wider window to read it properly. Since Discord's window's width is causing text to wrap.

stable knot
#

there is also the option to group together elements that serve a common topic or purpose
like all custom Collection types,
or game mode types

so another option would be to group all managers together, but in this case .. hmmhh.. is there anything better you can use instead of actOne etc? not a fan of that naming

#

the other thing i dont like is that you'd have 3+ classes with different responsibilites that have the complete same name

#

even though in different namespaces,
it's fine, you can use the namespace to discern, problem is if you ever import 2 or more of those namespaces in a class and then get naming conflicts, and have to use fully qualified names or aliases for the classes, possibly.
another issue is when you want to add a component in the inspector, you see multiple "LevelManager" but dont know if you get the right one. well unless of course you instead drag the script from project view to the inspector

iron condor
#

problem is if you ever import 2 or more of those namespaces in a class and then get naming conflicts
While this is true, it seems rather edge-case. Namespaces exist specifically to resolve conflicts and seeing as each LevelManager is distinct by namespace, I'd say that's fine. I can't think of a case where you'd need to reference multiple LevelManagers from one place.

But in the unlikely event that you do, you can resolve it with a using alias.
Example:

using LevelOneManager = CompanyName.Game.ActOne.LevelManager;
using LevelTwoManager = CompanyName.Game.ActTwo.LevelManager;

and then you can just refer to them by LevelOneManager and LevelTwoManager

#

However, I personally think the structure is flawed to begin with. Why are there separate level managers?

#

There should only be one

#

It's a manager - not a level itself. The point is that it should manage the level, not define the level

cold mesa
#

Actually in my project, I won't have unique managers for different acts. Though there are going to be variations of it, like MainManager, PracticeManager, etc. But they're gonna be in Share.Mcq only.

What's going to be different in Acts are things like type of questions, and other similar scripts.

CompanyName.Shared.Mcq
    - QuestionData.cs

CompanyName.ActOne
    - ActOneData.cs : CompanyName.Shared.Mcq.QuestionData

CompanyName.ActTwo
    - ActTwoData.cs : CompanyName.Shared.Mcq.QuestionData

I should have written this earlier. But while writing this post, what came to my mind I just wrote it. So as common things like manager comes up first, so I wrote it as an example. I'm trying to recreate my problem for the post in simple terms that's why. I'll take a note to write names with proper context next time.

So basically QuestionData.cs is gonna be a abstract class. And all its derived classes are gonna be in different acts.

ancient zinc
#

For unity, such different data implementations (and if you're willing to spend the tie to extract it properly, functionality implementations) are more commonly solved with Scriptable Objects.

What I would imagine is that there would be a QuestionData class alone, that extends ScriptableObject, something like so:

[CreateAssetMenu(menuName = "Question Data")]
public class QuestionData : ScriptableObject {
  [field: SerializeField] public float Foo { get; set; }
  // todo other member data, methods etc.
}

A MonoBehaviour, for example a level manager in your specific act scene, could consume an object of that type:

public class ActManager : MonoBehaviour {
  [field: SerializeField] public QuestionData QuestionData { get; set; }
}

What's nice about this approach, is that once you've written the data fields that you need, you don't need to touch this code again. The creation of data, the setting up of your data fields and the linking of that data happens entirely from the Editor. Unless you need to add fields or behaviour to your question data.

unknown.png