unityのC#での名前空間の使い方について、とアクセス修飾子について教えてください。

Question

知りたいこと

Unityの名前空間について、質問です。

自分の今の理解してるのは、
クラス名が他の人が作成したクラス名と被ってしまうと、衝突が起きるので、
コンパイルを通すときにエラーが発生するので、
特にチーム開発の時には、基本的には名前空間を使って、クラス名の衝突を避ける。

というのは理解できてます。

で、知りたいことは、
皆さんは、namespaceはどこまでの粒度で命名されていますか？

例えば、PlayerとEnemyのカテゴリー別でスクリプトをフォルダの中に分けているとします。
この場合、Playerの名前空間と、Enemyの名前空間を作るとか、、です。

例として、以下にnamespaceを使わないManagerクラスのコードを記載します。
また「疑問に思うこと」では、２つのコードにPlayerの名前空間とEnemyの名前空間を使っています。

public class PlayerManager : Monovihaviour{
   //処理
}

public class EnemyManager : Monovihaviour{
   //処理
}

上記のスクリプトでは、クラス名は完結にはなっています。

PlayerならPlayerのみのnamespaceに。
EnemyならEnemyのみのnamespaceに。

ここまでの粒度の名前空間って、逆に使いずらいような気がしています。

ちなみに、今までは一つのプロジェクトに、プロジェクト名のnamespaceをつけていました。

namespaceは以下の「疑問に思うこと」の２つのコードで、
試しにManager.csスクリプトを作成してみたのですが、同じクラス名にはできませんでした。

疑問に思うこと

次に、namespaceを使って、Managerクラスを作っている場合は

• PlayerManager.cs > Manager.cs
• EnemyManager.cs > Manager1.cs

Manager.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using Enemy;

namespace Player
{
    public class Manager : MonoBehaviour
    {
        public int playerHP;
        void Start()
        {
            Enemy.Manager1 manager = new Enemy.Manager1();
            manager.enemyHP = 0;

        }
    }
}

Manager1.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using Player;

namespace Enemy
{
    public class Manager1 : MonoBehaviour
    {
        public int enemyHP;
        void Start()
        {
            Player.Manager manager = new Player.Manager();
            manager.playerHP = 10;
        }
    }
}

別件ですが、簡単な質問をもう一つだけ。

publicなので、usingを使わずともアクセスができると思うので、
UnityでのInternalアクセス修飾子の同一アセンブリのみっていうのがいまいち理解できていません。
UnityHubでプロジェクトを２つ作成したとしたら、publicにしたら、この違う２つのプロジェクトのクラス間もアクセスできてしまうのでしょうか？
そうならinternalにほとんどしないといけないのでは？と思ってますが、
例えば上の疑問に思うことに記載しているコードだと、他のプロジェクトからアクセスできるのでしょうか？

Comments

[退会済みユーザー]

> 名前空間の使い方について、とアクセス修飾子について教えてください

質問の「別件ですが・・・」以降がアクセス修飾子の質問で、前半の名前空間とは関係がない話のようですが、であればスレッドを別けて質問してはいかが？

[LINQLINQ]

はい。
そうしてみます！

Answer 1

衝突を避ける

実際には MFC くらいでしか「何これふざけてるの！？」とかいう衝突経験をしたことはないので，
あまりこの点を意識した形で namespace を用いてはいません．
（いかにも衝突しそうな名称をわざと用いてやるぜ！　くらいしないと，まず衝突しないような気がする．）

そのため下記のような感覚で用いています．

namespaceはどこまでの粒度で命名されていますか？

ソースコード群をフォルダにわけるじゃないですか．それと同じような感覚の粒度にしています．
「ソースファイル群をある同一のフォルダに突っ込む理由」と，「class 等々をある同一の namespace に突っ込む理由」がかなり似ているかな…みたいな．

なので，ソースファイル群がフォルダ階層内にあるとき，
ある程度上位階層のフォルダ構成がほぼほぼ namespace になっていたりします．

Comments

[fana]

Visual Studio で C# のとき，
ソリューションエクスプローラでの「フォルダ」と，実際のファイルシステムの「フォルダ」は同一のものになっていて，
ソリューションエクスプローラでクラスを新規作成すると→追加した箇所のフォルダ階層がそのまま namespace になった形のソースが追加される．

なので，このような手順でやってると，完全に「フォルダ階層＝namespace」になっちゃうんだけど，
でもそれはちょっと違うかなぁ，と感じる．

[fana]

C++ のときには，
ソリューションエクスプローラでの「フォルダ」ってのは，単なるそこでの表示階層みたいな概念でしかなくて，実際のファイルシステムの「フォルダ」とは無関係．
（自分としてはこっちに慣れてるから，C#側はなんか嫌．）

Answer 2

個人的な意見で良ければ。

私の場合は、「内容レベル」(= 大枠の処理レベル)で分離しますね。

namespaceの強みは『重複を避ける』ことにあると思っているので、「クラスレベルでの分離」ではなく、
処理レベルでの分離ですね。

(ゲームは作ったことないので詳しくはわかりませんが)Enemy, Playerは単にキャラの分類なので、
Characters.Enemy, Characters.Player とかみたいにほぼ同じnamespaceでやります。
ですが、(ゲーム内の)フィールドを表現するクラスの場合はStages.GameField とかみたいに別のnamespaceで。

一括処理程度のものでも、「ファイル処理系」はFileManipulator名前空間、「画像処理系」はImageProcessor名前空間... とかみたいに役割というか、対象範囲みたいなもので分離しますかね。

後は、実務レベルだと複数人で開発するようなので、「担当者の名前をnamespaceにする」というコーディング規約があるところもあるようです。(ネットの情報ですが)

たとえば私が担当する場合は、BeatStar.Person とかみたいな感じ? でしょうか。

この考え方であれば、質問者さんが感じておられる問題を解決できるのではないでしょうか。

Comments

[LINQLINQ]

とても参考になりました。
処理レベルで分けるんですね。

そういわれるとEnemyとPlayerで分けないで、これからは処理単位で名前空間を作ってみます。