名前空間は、関連するコードをまとめ、名前の衝突を避けるための仕組みで、ごく単純なコードベースを除けば、たいていのコードに登場します。
構文は次のとおりです:
namespace MyNameSpace
{
public class MyClass {}
public class OtherClass {}
}
名前空間に含まれる型を、その名前空間のスコープの外から参照するには、ドット構文を使って型名の前に名前空間名を付けます。あるいは、もっとよく使われる方法として、ファイルの先頭(または名前空間の中)にusingディレクティブを書けば、接頭辞を付けずに型を使えます。同じ名前空間の中では、型名を修飾する必要はありません。
namespace MySpace
{
public class MyClass {}
public class Foo
{
public void Bar()
{
var baz = new MyClass();
}
}
}
public class Qux
{
public void Box()
{
var nux = new MySpace.MyClass();
}
}
namespace OtherSpace
{
using MySpace;
public class Tix
{
public void Jeg()
{
var lor = new MyClass();
}
}
}
名前空間には、using MyAlias = MySpace;という構文で別名を付けられます。そうすれば、その名前空間を使える場所ならどこでも、その別名を使えます。
経営陣は、リモートコントロールカーのプロジェクトremote-control-competitionにダーウィン的な原則を適用し始めました。エンジニアは_Red_と_Blue_の2つのチームに分けられ、それぞれが独立して設計を改善するよう任されています。もう一方のチームの設計上の判断を気にする必要はありません。
コードを調べて、テストのために2つの取り組みをどのように最もうまく組み合わせられるかを検討するよう依頼されています。
コードの意図をよりよく表すために、namespacesを使ってください。
現在、MotorやTelemetryといった重要な型は、RemoteControlCar本体は言うまでもなく、それを囲む静的クラス<Color>RemoteControlCarTeamの中に入れ子になっています。この外側のクラスの唯一の目的は、同じ名前の型をプログラム内で共存させることです。その目的は、名前空間を使うことでよりよく表現できます。次の演習でわかるように、こうした目的にはnamespaceがstatic classよりも有利です。
経営陣は、定義上はチームをRedRemoteControlCarTeamとBlueRemoteControlCarTeamと呼ぶべきだと固く主張していますが、チームを参照するときにはこの名前はかなり扱いにくいものです。車を組み立てるときには、より短い識別子RedとBlueを使う方法を見つけてください。