Хотя компилятор C# без проблем воспримет единственный файл кода С#, содержащий множество типов, такой подход может стать проблематичным в командном окружении. Если вы работаете над типом Circle, а ваш коллега — над типом Hexagon, тогда вам придется по очереди работать с монолитным файлом или сталкиваться с трудноразрешимыми (во всяком случае, отнимающими много времени) конфликтами при слиянии изменений.

Более удачный подход предусматривает помещение каждого класса в собственный файл, с определением в каждом из них пространства имен. Чтобы обеспечить упаковку типов в ту же самую логическую группу, просто помещайте заданные определения классов в область действия одного и того же пространства имен:

// Circle.cs

namespace MyShapes

{

  // Класс Circle

  public class Circle { /*  Интересные методы... */ }

}

// Hexagon.cs

namespace MyShapes

{

  // Hexagon class

  public class Hexagon { /* Еще интересные методы... */ }

}

// Square.cs

namespace MyShapes

{

  // Square class

  public class Square { /* И еще интересные методы...*/}

}

На заметку! Рекомендуется иметь в каждом файле кода только один класс. В ряде приводимых ранее примеров такое правило не соблюдалось, но причиной было упрощение изучения. В последующих главах каждый класс по возможности будет располагаться в собственном файле кода.

Обратите внимание на то, что пространство MyShapes действует как концептуальный "контейнер" для определяемых в нем классов. Когда в другом пространстве имен (скажем, CustomNamespaces) необходимо работать с типами из отдельного пространства имен, вы применяете ключевое слово using, как поступали бы в случае использования пространств имен из библиотек базовых классов .NET Core:

// Обратиться к пространству имен из библиотек базовых классов.

using System;

// Использовать типы, определенные в пространстве имен MyShapes.

using MyShapes;

Hexagon h = new Hexagon();

Circle c = new Circle();

Square s = new Square();

В примере предполагается, что файлы С#, где определено пространство имен MyShapes, являются частью того же самого проекта консольного приложения; другими словами, все эти файлы компилируются в единственную сборку. Если пространство имен MyShapes определено во внешней сборке, то для успешной компиляции потребуется также добавить ссылку на данную библиотеку. На протяжении настоящей главы вы изучите все детали построения приложений, взаимодействующих с внешними библиотеками.

Разрешение конфликтов имен с помощью полностью заданных имен

Говоря формально, вы не обязаны применять ключевое слово using языка C# при ссылках на типы, определенные во внешних пространствах имен. Вы можете использовать полностью заданные имена типов, которые, как упоминалось в главе 1, представляют собой имена типов, предваренные названиями пространств имен, где типы определены. Например:

// Обратите внимание, что пространство имен MyShapes больше не импортируется!

using System;

MyShapes.Hexagon h = new MyShapes.Hexagon();

MyShapes.Circle c = new MyShapes.Circle();

MyShapes.Square s = new MyShapes.Square();

Обычно необходимость в применении полностью заданных имен отсутствует. Они требуют большего объема клавиатурного ввода, но никак не влияют на размер кода и скорость выполнения. На самом деле в коде CIL типы всегда определяются с полностью заданными именами. С этой точки зрения ключевое слово using языка C# является просто средством экономии времени на наборе.

Тем не менее, полностью заданные имена могут быть полезными (а иногда и необходимыми) для избегания потенциальных конфликтов имен при использовании множества пространств имен, которые содержат идентично названные типы.

Предположим, что есть новое пространство имен My3DShapes, где определены три класса, которые способны визуализировать фигуры в трехмерном формате:

// Еще одно пространство имен для работы с фигурами.

// Circle.cs

namespace My3DShapes

{

  // Класс для представления трехмерного круга.

  public class Circle { }

}

// Hexagon.cs

namespace My3DShapes

{