Язык программирования C#9 и платформа .NET5 - Эндрю Троелсен

слово await будет скрывать с глаз возвращаемый объект Task, что выглядит как прямой возврат лежащего в основе возвращаемого значения. Методы, не имеющие возвращаемого значения, просто возвращают void.

• Проверка параметров и другая обработка ошибок должна делаться в главной части метода с переносом фактической порции async в закрытую функцию.

• Для переменных, находящихся в стеке, объект ValueTask более эффективен, чем объект Task, который может стать причиной упаковки и распаковки.

• По соглашению об именовании методы, которые могут вызываться асинхронно, должны быть помечены с помощью суффикса Async.

Резюме

Глава начиналась с исследования роли пространства имен System.Threading. Как было показано, когда приложение создает дополнительные потоки выполнения, в результате появляется возможность выполнять множество задач (по виду) одновременно. Также было продемонстрировано несколько способов защиты чувствительных к потокам блоков кода, чтобы предотвратить повреждение разделяемых ресурсов.

Затем в главе исследовались новые модели для разработки многопоточных приложений, введенные в .NET 4.0, в частности Task Parallel Library и PLINQ. В завершение главы была раскрыта роль ключевых слов async и await. Вы видели, что эти ключевые слова используются многими типами в библиотеке TPL; однако большинство работ по созданию сложного кода для многопоточной обработки и синхронизации компилятор выполняет самостоятельно.

Часть V

Программирование с использованием сборок .NET Core

Глава 16

Построение и конфигурирование библиотек классов

В большинстве примеров, рассмотренных до сих пор, создавались "автономные" исполняемые приложения, где вся программная логика упаковывалась в единственную сборку (*.dll) и выполнялась с применением dotnet.ехе (или копии dotnet.ехе, носящей имя сборки). Такие сборки использовали в основном библиотеки базовых классов .NET Core. В то время как некоторые простые программы .NET Core могут быть сконструированы с применением только библиотек базовых классов, многократно используемая программная логика нередко изолируется в специальных библиотеках классов (файлах *.dll), которые могут разделяться между приложениями.

В настоящей главе вы сначала исследуете детали разнесения типов по пространствам имен .NET Core. После этого вы подробно ознакомитесь с библиотеками классов в .NET Core, выясните разницу между .NET Core и .NET Standard, а также научитесь конфигурировать приложения, публиковать консольные приложения .NET Core и упаковывать свои библиотеки в многократно используемые пакеты NuGet.

Определение специальных пространств имен

Прежде чем погружаться в детали развертывания и конфигурирования библиотек, сначала необходимо узнать, каким образом упаковывать свои специальные типы в пространства имен .NET Core. Вплоть до этого места в книге создавались небольшие тестовые программы, которые задействовали существующие пространства имен из мира .NET Core (в частности System). Однако когда строится крупное приложение со многими типами, возможно, будет удобно группировать связанные типы в специальные пространства имен. В C# такая цель достигается с применением ключевого слова namespace. Явное определение специальных пространств имен становится еще более важным при построении разделяемых сборок, т.к. для использования ваших типов другие разработчики будут нуждаться в ссылке на вашу библиотеку и импортировании специальных пространств имен. Специальные пространства имен также предотвращают конфликты имен, отделяя ваши специальные классы от других специальных классов, которые могут иметь совпадающие имена.

Чтобы исследовать все аспекты непосредственно, начните с создания нового проекта консольного приложения .NET Core под названием CustomNamespaces. Предположим, что требуется разработать коллекцию геометрических классов с именами Square (квадрат), Circle (круг) и Hexagon (шестиугольник). Учитывая сходные между ними черты, было бы желательно сгруппировать их в уникальном пространстве имен MyShapes внутри сборки CustomNamespaces.ехе.

Хотя компилятор 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, представляют собой имена типов, предваренные названиями