применяться ни один из следующих модификаторов: virtual, abstract, override, new, sealed и extern.

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

public partial class MyClass

partial void DoSomethingElse () ;

public void DoSomething ()

Console.WriteLine( DoSomething() execution started. );

Метод DoSomething () начал вьшолняться

DoSomethingElse О ;

Console.WriteLine( DoSomething() execution finished. );

Метод DoSomething 0 завершен

public partial class MyClass {

partial void DoSomethingElse() {

Console.WriteLine( DoSomethingElse0 called. );

Вызван метод DoSomethingElse ()

Здесь частичный метод DoSomethingElse определяется и вызывается в первом определении частичного класса, а реализуется - во втором. В таком случае вывод при вызове DoSomething из консольного приложения будет таким, как и ожидалось:

DoSomethingО execution started. DoSomethingElse () called. DoSomething () execution finished.

В случае удаления второго определения частичного класса или вообще всей реализации частичного метода (или превращения этого кода в комментарии), однако, вывод будет выглядеть следующим образом:

DoSomethingО execution started. DoSomethingО execution finished.

Вы можете предположить, что здесь происходит следующее: при вызове метода DoSomethingElse исполняющая среда обнаруживает, что у этого метода нет реализации, и потому переходит к выполнению следующей строки кода. На самом деле происходит нечто более изощренное. При компиляции кода, в котором содержится определение частичного метода без реализации, компилятор фактически вообще удаляет весь этот метод целиком. Он также удаляет и все связанные с этим методом вызовы. В результате при выполнении кода никакой проверки не предмет наличия реализации не делается, поскольку нет никакого вызова, который бы запрашивал такую проверку. Все это приводит к небольшому, но, тем не менее, существенному, улучшению производительности.

Как и частичные классы, частичные методы играют полезную роль в настройке генерируемого автоматически или создаваемого конструктором кода. Конструктор может объявлять частичные методы, которые разработчик может как реализовать, так и не реализовать, в зависимости от ситуации. Если он выбирает не реализовать их, на

производительности это никак не сказывается, потому что в скомпилированном коде такого метода все равно, по сути, уже не существует.

А теперь подумайте о том, почему у частичных методов не может быть возвращаемого типа? Если вы сможете ответить на этот вопрос, значит, вы полностью разобрались в данной теме; именно потому вопрос оставлен для самостоятельной проработки.

Пример приложения

Для иллюстрации некоторых из приведенных выше приемов в настоящем разделе описывается процесс создания модуля класса, который будет использоваться в качестве основы и в последующих главах. В состав этого модуля входит два класса.

□ Класс Card, представляющий стандартную игральную карту трефовой, бубновой, червовой или пиковой масти достоинством от туза до короля.

□ Класс Deck, представляющий полную колоду из 52 карт и предусматривающий осуществление доступа к картам по их позиции в колоде, а также обладающий возможностью тасования колоды.

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

Продумывание приложения

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

Класс Card

Класс Card, по сути, является контейнером для двух доступных только для чтения полей: suit (масть) и rank (достоинство). Причина, по которой эти поля должны быть доступными только для чтения, состоит в том, что в наличии пустой карты нет никакого смысла, и возможность изменять карты после их создания не требуется. Для упрощения данного процесса нужно будет сделать используемый по умолчанию конструктор приватным, а также предоставить альтернативный конструктор, способный создавать карту указываемой масти и достоинства.

Помимо этого, в классе Card еще потребуется переопределить метод ToString объекта SystemObject, чтобы легко получать представляющую карту строку в понятном для человека виде. Чтобы немного упростить дело, для полей suit и rank потребуется предоставить перечисления.

Таким образом, получается, что структура класса Card должна выглядеть так, как показано на рис. 10.8.

Рис. 10.8. Структура класса Card

Класс Deck

Класс Deck должен обслуживать 52 объекта Card. Для этого вполне подойдет и простой массив. Напрямую получать доступ к этому массиву будет невозможно, потому что доступ к объекту Card должен осуществляться через метод GetCard, возвращающий объект Card с заданным индексом. Помимо этого в классе Deck должен еще также присутствовать метод Shuffle для тасования карт в массиве. Таким образом, получается, что структура класса Deck должна выглядеть так, как показано на рис. 10.9.

Card

+suit +rank

0...*

+ToString()

Deck

-cards : Card[]

+GetCard()

-hOeckO

i-ShuffleO

Puc. 10.9. Структура класса Deck

Написание библиотеки классов

в этом примере предполагается, что вы уже достаточно хорошо знакомы с IDE-средой, чтобы не нуждаться в практических занятиях, так что явным образом шаги здесь не перечисляются, поскольку они ничем не отличаются от тех, что уже не раз доводилось использовать. Здесь все основное внимание уделяется детальному рассмотрению кода, хотя некоторые указания все же встречаются для исключения вероятности возникновения каких-нибудь проблем.

Все классы и перечисления должны содержаться в проекте типа библиотеки классов по имени ChlOCardLib. Таким образом, получается, что в этом проекте всего должно быть четыре файла .сз, а именно: Card.cs с определением класса Card, Deck.cs с определением класса Deck, а также Suit.cs и Rank.cs с определениями соответствующих перечислений.

Большую часть этого кода можно собрать с помощью входящего в состав VS инструмента построения диаграмм классов.

Тем, кто использует VCE, а потому не имеет доступа к инструменту построения диаграмм, не стоит беспокоиться. В каждом из следующих разделов будет также приводиться и весь генерируемый этим инструментом код, благодаря чему они тоже смогут спокойно следить за происходящим процессом. В данном проекте никаких отличий в коде между двумя этими IDE-средами нет.

Для начала необходимо выполнить описанные ниже действия.

1. Создать новый проект типа библиотеки классов, присвоить ему имя ChlOCardLib и сохранить в каталоге С: \BegVCSharp\ChapterlO.

2. Удалить из этого проекта файл Classl.cs.