異なる名前空間に同じクラス名のクラスを配置することについて

Question

タグにC#をつけていますが、C#に限った話ではなく、名前空間という概念を持つ言語の場合でもよいです。

疑問

主題の通りですが、例えば Hoge と Piyo という名前空間があるとします。
その名前空間それぞれに Foo という同じ名前のクラスを定義するということの是非について疑問です。

イメージとしては以下の感じです。

namespace Contracts
{
    // 契約上の顧客クラス
    public class Customer
    {
        ...
    }
}

namespace Deliveries
{
    // 配送上の顧客クラス
    public class Customer
    {
        ...
    }
}

個人的には、上記の「契約上の顧客クラス」と「配送上の顧客クラス」というものが概念上存在するので、このようにクラスの名前付けをしたいのですが、以下の点が気になっています。

• 可読性上問題ないのか？
• そもそも慣習的にこういうことはタブーなのか？
• 一般的にこういうことはされているのか？

ご意見宜しくお願い致します。

Comments

[m.ts10806]

言語限らないのであれば「Namespace」タグのみにされては？（「オブジェクト指向」は必要そうですが）

[baz]

おっしゃる通り変更いたしました。

Answer 1

C# ならたとえば System.Windows.Controls.Control や System.Windows.Forms.Control があります。
Windows Forms と Web Forms と WPF で当たり前のように違う名前空間で同じクラス名を使っています。
だから、ありかなしかで言えばありです。
メジャーな前例があるので文句は言いにくいでしょう。

ただ、単に ListView と言った時にどの ListView かわからないなどの不都合はあります。
もし同じクラス名を作るのであれば同様の混乱が起きることを想定して対策をとってください。

Comments

[baz]

早速のご回答ありがとうございます。
Zuishin 様としては、今までの経験上、プロジェクトでこういうやり方はされていますでしょうか。それともこういうときは ContractCustomer や DeliveryCustomer などの名前にされますでしょうか。

[Zuishin]

したことはありますが、using すると結局個々に名前空間で修飾しなきゃいけなくなるので同じ場面で使う可能性のあるものには違う名前をつけます。
System.IO.Path と System.Windows.Shapes.Path なんか鬱陶しいですね。

Answer 2

ケースバイケースです。文法間違いでない以上意図する場合もあるでしょうし、意図せず結果的にそうなるということもあるでしょう。

名称統一したいと思うこともあれば、別物は名前を変えるべきと考えることもあるでしょう。場合によりけりです。

Answer 3

java の場合です。
この画面は eclipse という IDE で list クラスを import せずに記述したときに、
どの パッケージの List を import するかの選択ダイアログです。