C#の名前空間とフォルダ階層が一致しないことのメリット

Question

うろ覚えですが、確かJavaだとjp.co.aaa.bbb.Hogeというクラスがあったら、jp\co\aaa\bbb\Hoge.javaというフォルダ階層にしなければいけなかったと記憶しています。
この仕様はパッケージを見ただけでどこにソースがあるのかわかりやすいというメリットがあると思います。

C#の場合、名前空間とフォルダ構成の関連に制限は無かったと思います。
この仕様のメリットは何でしょうか？
自分は

• Config, Resource, Sourceなどでフォルダ分けして整理しても名前空間の方にSourceと付けなくて済む
• あるプロジェクトからソースファイルをいくつか持ってきて自分のテスト用プロジェクト（動作確認用）を動かす場合、tmpなどのフォルダを作って全部そこに放り込んでおけば済む（自分で作ったソースと分けておき、かつ名前空間のフォルダ階層をいちいち作らずに済む）

というのを思いつきました。

Comments

[退会済みユーザー]

javaの場合、オートロードが規約で定まっているので、マニュピレートロードができません。また パッケージとネームスペースは別物です。

Answer 1

JAVAの一致させなきゃいけないことのメリットとして挙げている内容ですが、
ディレクトリ階層をたどって開いてようやく中身を見るので全くメリットに感じないんですが
からディレクトリを何回も開いてようやく探し出してソースを見てどこにあるのかわかりやすいって言われても、ねぇ

ちなみにＣ＃の方はほかのプロジェクトで使用しているクラスを一つだけ他で再利用したいときにはＨＤＤの中の置き場所が固定されないのがメリットになります（まぁＪＡＶＡ使いじゃないのでそれが当たり前の認識なんですが）
色んな機能をまとめたものをまるっと使う場合はプロジェクトを参照すればいいのだけど、
ちょこっとした1ファイルだけのためにプロジェクトを分けてってのは大げさな気がして
Ｃ＃ってかＶＳだとファイルの追加で既存項目の追加にしてそのまま追加ボタンを押さずに追加ボタンの右横の参画を押して参照か何かに切り替えるとファイルはコピーせずに同じものを見る形になるので修正漏れが起きなくなるので便利です
あんまりいい使い方ではないってのは理解してますけどね

Answer 2

こんにちは。

１つのファイルに複数の名前空間を定義できることはメリットと思います。
プライベートな名前空間をC#で定義できるかどうか把握していませんが、もし定義できるなら、外部I/Fを担うパブリックな名前空間と同じファイルに、実装をプライベートとして入れたいことはあると思います。

プライベート名前空間が無かった場合でも、internalのような名前にして「internalの中のものは使うな」というプログラミング規約にした時、同様です。（C++ではこのようにしてます。）

Answer 3

C# がフォルダ階層と名前空間の一致という「制約」を採用しなかったのは、それが優れているから、というより、それが好きな人がいるから、ということではないでしょうか。

C#は、VBやらC++やらJavaやらDelphiやら、いろんな言語のいいとこどりした言語です。
どの言語の使い手から見ても、「これ〇〇（自分が慣れ親しんだ言語）に似てる！」と思わせる、超絶八方美人な仕様となっています。

例えば名前空間を使う必要がないC++にはそんな制約ないし、もちろん名前空間という概念がないVB（.net以前）にもそんな制約はありません。
そんな言語で経験を積んだ人たちに新たな制約を課してもいいことないって判断じゃないでしょうか。
一致させた方が管理しやすいならそうしてくれ、それが嫌ならしなくてもいいよと。

多くのプログラミング言語は「プログラムはこう書くべき」という設計者の技術的思想を反映した仕様となっているのでしょうが、C#は「みんなに使ってほしい（そしてWindowsプログラムを書いてほしい）」というかなり異なったアプローチで作られているように思います。