Programming stuff

Принцип замещения Лисков и контракты

2012-02-28T15:02:00.001+02:00

Идея этой заметки навеяна статьей Александра Бындю “Дополнение к LSP” и может рассматриваться, как развернутый комментарий к статье Александра.

Итак, вопрос следующий, предположим, один из членов команды пытается реализовать интерфейс IList of T в классе DoubleList of T таким образом, чтобы при добавлении элемента с помощью метода Add, добавлялся бы не один, а два одинаковых элемента. Поскольку класс List of T всегда добавляет только один элемент, то можно считать, что данное поведение нарушает принцип замещения Лисков (LSP – Liskov Substitution Principle).

UPDATE: Если вы вначале хотите познакомиться с определением принципа замещения Лисков, то оно приведено в конце статьи в разделе “Принцип замещения Лисков. Определение”.

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

Для начала нужно внести небольшую правку в условие задачи (да, я понимаю, что это не честно, но в данном случае это оправдано). В исходной задаче говорилось о реализации классом DoubleList интерфейса IList of T, однако на самом деле в .NET Framework метод Add объявлен в интерфейсе ICollection of T, а значит, следует рассматривать, нарушает ли класс DoubleList of T контракт коллекции, а не списка.

ПРИМЕЧАНИЕ
Для простоты чтения кода и запуска примеров, я буду использовать не обобщенную версию класса DoubleList, а специализированный контейнер для хранения строк, т.е. по сути, наш DoubleList будет реализовать интерфейс ICollection of string.

public class DoubleList : ICollection<string>
{
    private readonly List<string> _backingList = new List<string>();
 
    public void Add(string item)
    {
        // Вместо добавления элемента один раз, добавляем его 2 раза 
        _backingList.Add(item);
        _backingList.Add(item);
    }
 
    // Остальные методы не важны 
}

Теперь, предположим, что где-то в коде мы используем интерфейс ICollection of string (т.е. имеем полиморфное использование) и рассчитываем на то, что количество элементов увеличится строго на один. Подобное поведение можно выразить либо с помощью формального постусловия (например, с использованием Code Contract), либо можно выразить в виде юнит-теста. Поскольку к контрактам мы перейдем позже, то давайте рассмотрим вначале юнит-тест:

[Test]
public void TestAddMethodAddsOnlyOneElement()
{
    ICollection<string> collection = new DoubleList();
    int oldCount = collection.Count;
 
    collection.Add("foo");
    Assert.That(collection.Count, Is.EqualTo(oldCount + 1));
}

Да, действительно, этот тест будет нормально работать при использовании в качестве объекта collection List of string, и будет падать в случае использования DoubleList-а.

Но вот только один вопрос: а вправе ли мы ожидать от метода Add интерфейса ICollection of T именно такого поведения? Когда речь заходит о корректности (проще говоря, о том, баг это или нет, причем не важно, где: в коде или дизайне), то она определяется лишь тем, соответствует ли поведение кода спецификации или нет. Спецификация может быть формальной или не формальной, но программа некорректна лишь тогда, когда она перестает делать то, для чего она предназначена, а если никто не знает, для чего она предназначена, то уже никто не может сказать, что она работает не правильно.

Некоторое выражение, такое как x = y / 2, само по себе не является ни корректным, ни не корректным. Все зависит от того, каким должно быть отношение между x и y (подробнее об этом см. “Проектирование по контракту. Корректность ПО”). Ситуация с методом Add аналогична: без формального или хотя бы неформального описания того, что должен делать этот метод мы не может утверждать правильно ли он реализован наследником. Если же мы откроем официальную документацию для ICollection (Of T).Add Method, то все что мы увидим, это одну строчку, в которой будет сказано, что этот метод добавляет элемент в коллекцию. При этом все остальное (например, а точно ли он будет добавлен или в каком количестве), это лишь наши с вами допущения и единственное, что можно сделать, это постараться выяснить, как ведут себя другие реализации интерфейса ICollection of T.

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

[TestCaseSource("GetAllCollections")]
public void TestAddToCollectionTwiceAddsTwoElement(ICollection<string> collection)
{
    int oldCount = collection.Count;
    if (collection.IsReadOnly)
    {
        Console.WriteLine("Current collection type ({0}) is readonly. Skipping it...",
        collection.GetType());
        return;
    }
 
    collection.Add("foo");
    collection.Add("foo");
    Assert.That(collection.Count, Is.EqualTo(oldCount + 2));
}

Еще раз обращаю внимание на проверку предусловия метода Add, контракты – это не игра в одни ворота, поэтому мы должны выполнять свою часть договора, чтобы вызываемый код выполнял свою. Сам тест, является параметризованным (из состава NUnit), входные значения которого будут браться из метода GetAllCollections. Я не будут заморачиваться с поиском всех существующих классов, реализующих интерфейс ICollection of T, а просто добавлю некоторые популярные типы коллекций вручную:

private static ICollection<string>[] GetAllCollections()
{
    return new ICollection<string>[] 
                { 
                    new List<string>(), 
                    new HashSet<string>(), 
                    new Collection<string>(), 
                    new BindingList<string>(), 
                    new LinkedList<string>(), 
                    new ObservableCollection<string>(), 
                    new ReadOnlyCollection<string>(new List<string>()), 
                    new SortedSet<string>(), 
                    new string[]{}, 
                };
}

Теперь запускаем приведенный выше тест и видим, что как минимум два типа коллекций добавляют лишь один элемент, хотя мы просили добавить два. Это, конечно же, типы коллекций, которые не позволяют хранить дубликаты, такие как HashSet of T и SortedSet of T.

А теперь давайте вернемся к исходному вопросу: нарушает ли реализация метода Add классом DoubleList принцип замещения Лисков? Ответ: Нет, не нарушает!

Метод Add интерфейса ICollection of T не налагает никаких ограничений на то, какое количество элементов будет в коллекции после добавления, а значит, мы не можем требовать от всех классов, реализующих этот интерфейс, следовать определенному правилу. На самом деле, более правдоподобным (исходя из поведения коллекций, реализующих ICollection of T) является следующее предусловие: после вызова метода Add, следующий за ним вызов метода Contains должен вернуть true и количество элементов коллекции не должно уменьшиться (т.е. newCount >= oldCount).

В таком случае, если в нашем тесте заменить существующее утверждение на:

Assert.IsTrue(collection.Contains("foo"));

то все тесты будут проходить успешно.

Заключение

Можно смело говорить о том, что DoubleList не нарушает принцип замещения Лисков, либо нарушает вместе с некоторыми стандартными классами коллекций из BCL. С другой стороны, я согласен, что дизайн класса DoubleList «кривоват», но не из-за нарушения некоторого принципа, понять формулировку которого в здравом уме практически невозможно (*), я бы скорее апеллировал к тому, что подобное поведение является интуитивно не понятным и наверняка приведет к проблемам в сопровождении.

Не зря Мейер в своей толстенной книге (см. доп. ссылки) столь важную роль отводит формальной спецификации программ с помощью утверждений (предусловий, постусловий и инвариантов). Именно отсутствие формального описания того, что должен делать метод делает таким сложным написания наследника, который бы работал «правильно», поскольку что такое «правильно», никто сказать не может. Сигнатура метода (и возможный комментарий) являются слишком неформальными, чтобы понять «изменится ли поведение при использовании наследника вместо базового класса».

В следующий раз мы посмотрим, как Code Contracts (поддержка которых частично включена в состав mscorlib) могут помочь в решении нашей задачи, и о том, какое же формальное постусловие есть у метода Add.

-------------------------

(*) Я отойду от обычного правила оформление сноски прямо в тексте и сделаю отдельный подраздел, посвященный определению принципа замещения Лисков.

Принцип замещения Лисков. Определение

В замечательной книге Джеймса Коплиена «Программирование на языке С++» дается отличное, и совершенно непонятное определение принципа замещения Лисков:

...если для каждого объекта o1 типа S существует объект o2 типа T такой, что для всех программ P, определенных в терминах T, поведение P не изменяется при замене o2 на o1, то S является подтипом (subtype) для T.

(If for each object o1 of type S there is an object o2 of type T such that for all programs P deﬁned in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.)

В целом, все хорошо, за исключением того, что совершенно не понятно, что означает «в контексте Т» и совсем не понятно, что означает, «поведение P не изменится», когда это самое поведение нигде не описано.

Другое популярное, но не более понятное определение, можно найти в книге Боба Мартина:

Должна быть возможность вместо базового типа подставить любое его подтип.

Это определение проще, но едва ли яснее. В любом объектно-ориентированном языке программирования, существует неявное преобразование от наследника к базовому классу (при учете использования открытого наследования), таким образом, это требование стоит отнести скорее к компилятору или языку программированию, а не к классам определяемым пользователям. Сам Мартин в своей книге (а также в статье The Liskov Substituion Principle) говорит о важности контрактов, и в частности, о важности предусловий и постусловий для спецификации поведения виртуальных методов.

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

Дополнительные ссылки

Бертран Мейер. Объектно-ориентированное конструирование программных систем
Роберт К. Мартин. Принципы, паттерны и методики гибкой разработки на языке C#
Robert C. Martin The Liskov Substitution Principle
Robert C. Martin Design Principles and Patterns
Проектирование по контракту. О корректности ПО
Проектирование по контракту. Наследование

Повторное использование знаний

2012-02-13T20:12:00.001+02:00

Уже не первый раз натыкаюсь на обсуждения вопросов о том, кто и как изучает новые технологии и о том, как справится с тем огромном потоком «нововведений», которые ежегодно появляются в индустрии ПО. Однажды я уже отвечал на этот вопрос на кывт-е, и после очередного вопроса решил оформить эти мысли более структурированным образом.

Если оглядеться вокруг, то может сложиться впечатление, что отрасль разработки ПО шагает такими громадными шагами, что угнаться за ней нет никакой возможности. И если рассматривать всю отрасль в целом, то действительно это так и есть. Как-то сразу вспоминается старина Брукс со своим «Мифическим человеко-месяцем», когда он в заключении к своей книге пишет о том, как изменилась индустрия ПО в середине 90-х по сравнению с 50-ми годами. В те далекие годы (да, 90-е тоже уже далеки, так что уж говорить за эпоху зарождения индустрии сорока годами ранее) можно было прочитать все журналы (!),компьютерной тематики, которые выходили в свет. Сейчас же ежемесячно появляется десятки книг только по одной из популярных технологий, а количество статей просто не поддается счету.

С одной стороны, это заставляет относиться к выбору источников информации более осознанным и благоразумным образом. И именно эта мысль побудила меня к формированию списка наиболее интересных книг по программированию в целом, и отдельно, наиболее значимых книг по языку C# и платформе .NET. Но помимо качественных источников информации (список книг хорошо было бы дополнить списком блогов, подкастов и видеоуроков) важным качеством любого программиста является еще структурирование и «повторное использование» полученных знаний.

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

А что, если попытаться провести параллели между общепринятыми практиками проектирования софта и нашими знаниями? Вот, например, декомпозиция задачи отлично применима, как в программировании, так и при обучении. Все мы прекрасно знаем, насколько легко сделать все сложно (простите за каламбур), если смешать в одном методе простенькую бизнес-логику и логику по работе с С-строками. Если методу требуется десяток более или менее простых операций со строками, то понять, что в нем происходит, будет очень сложно из-за всех этих strlen, strcpy, strcmp, strcat и многих других операций, в каждой из которых может крыться ошибка.

ПРИМЕЧАНИЕ
Принято считать, что главное достоинство инкапсуляции – это защита внутренней реализации класса от внешних клиентов; дескать, благодаря инкапсуляции, «поставщик услуг» можем изменить внутреннее поведение (или представление) не затронув при этом клиентов. Однако инкапсуляция – это игра не в одни ворота; помимо того, что класс сможет изменить свою реализацию, инкапсуляция позволяет разгрузить клиента от ненужных деталей реализации, делая его (клиента) жизнь намного проще.

Смешав в одном месте довольно простую логику вместе с плохо спроектированной абстракцией, мы получаем комбинаторный рост сложности, который взорвет мозг еще при написании кода, не говоря уже за его поддержку. То же самое можно заметить, например, при обсуждении некоторой задачи внутри команды, когда собеседник на тебя вываливает огромный объем информации, без большей части которой оба собеседника могли бы обойтись. При изучении чего-то нового эта же проблема проявляется даже более остро: one step at a time – это любимый подход Джона Скита при описании возможностей языка C#, которым он успешно пользуется в своей книге “C# In Depth”, и именно этот подход делает его книгу простой для чтения и понимания.

Абстракции образуют иерархию (*)

(*) Это рисунок из книги Гради Буча «Объектно-ориентированный анализ и проектирование с примерами приложений».

Теперь давайте рассмотрим еще один аспект разработки, который можно напрямую использовать и при обучении. По словам Гради Буча – любая сложная система является иерархичной. Именно иерархия и модульность позволяют хоть как-то справляться с невероятной сложностью моделируемых систем. И если рассмотреть любую современную технологию, то можно заметить, что количество слоев в ней будет огромным, и что каждый из них строится на основе хорошо проверенных слоях нижнего уровня.

Повторное использование знание на примере WCF

Давайте в качестве примера рассмотрим WCF.

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

Современные технологии построения распределенных приложений довольно похожи. Все они строятся на основе проверенных паттернов, используют транспортные протоколы нижнего уровня и, в той или иной мере, борются с заблуждениями о распределенных приложениях (Fallacies of Distributed Computing).

Так, например, если у вас есть опыт работы с .NET Remoting-ом, то вы можете использовать его повторно при переходе на WCF: каждая из этих технологий является таким себе «слоеным» пирогом, с возможностью конфигурировать и настраивать самые разные уровни. В обеих технологиях мы можем использовать разные методы инстанцирования и конкурентности, настраивать безопасность и управлять сериализацией.

Знания низкоуровневых коммуникационных протоколов вы также сможете использовать повторно, поскольку рано или поздно в вашей системе начнутся проблемы, с которой не удастся разобраться без WireShark-а и анализа пакетов. Кроме того, многие проблемы или их решения могут быть заложены в самой природе транспортного протокола, и без этих знаний вы просто не сможете принять разумного решения: использовать ли в этой ситуации binding на основе протокола HTTP или TCP.

То же самое относится и к «сервисной» составляющей WCF. Сервисная архитектура – это отдельный аспект, который можно изучить за пределами WCF (например, используя веб-сервисы) и использовать его повторно уже в контексте новой технологии. Конечно, каждый из строительных блоков, на котором строится технология, может использоваться специфическим образом, но знание основополагающих принципов позволит разобраться в новой технологии на порядок легче.

ПРИМЕЧАНИЕ
Однажды я попробовал ответить на вопрос, «Что такое WCF?», стараясь воспользоваться приведенным здесь способом повторного использования знаний и максимально использовать аналогии с приемниками WCF, такими как .NET Remoting и веб-сервисы.

Обобщение знаний на примере автоматического управления памятью

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

Наследование – это одна из главных «визитных карточек» ООП и один из главных механизмов повторного использования, поэтому неудивительно, что именно им часто злоупотребляют. При проектировании ПО очень часто возникает проблема, под названием «преждевременным обобщением» (premature generalization), когда на слишком ранних этапах разработки вводятся базовые классы с определенным поведением, хотя еще не понятно, что именно является «общим» в данном конкретном случае. Так, например, весьма часто можно увидеть иерархию из 5 базовых классов для простого класса Customer, хотя на текущем этапе вовсе неясно, зачем это нужно.

ПРИМЕЧАНИЕ
Причины такого положения дел в проектировании ПО очень хорошо описал Бертран Мейер: «Произвольно или нет, но многие учебные презентации создают впечатление, что структуру наследования следует проектировать от наиболее общего (верхней ее части) к более специфическим частям (листьям). В частности, это происходит потому, что лучший способ описать существующую структуру – это идти от общего к частному, от фигур к замкнутым фигурам, затем к многоугольникам, прямоугольникам, квадратам. Но лучший способ описания структуры вовсе не означает, что он является и лучшим способом ее создания.
В идеальном мире, населенном совершенными людьми, мы бы сразу же обнаруживали правильные абстракции, выводили бы из них категории, затем их подкатегории и так далее. В реальном мире, однако, мы часто вначале обнаруживаем частный случай и лишь потом открываем общую абстракцию.»

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

Я: Я знаю, что множественное наследование – это фигня!
Он: Почему?
Я: Потому, что его нет в Java, а других языков я не знаю!

Довольно опрометчиво делать подобные выводы, если единственный язык, который я знаю – это Java. Скорее всего, я смогу сделать более правильные выводы и структурировать свои знания более осознанно, познакомившись хотя бы с несколькими языками, поддерживающими множественное наследование, такими как С++ и Eiffel.

Давайте, в качестве примера, рассмотрим несколько способов автоматического управления памяти и представим их в иерархической форме.

Автоматическое управление памятью является наиболее общим понятием, под который попадает несколько частных случаев. Так, например, можно выделить два наиболее типичных решения, основанных (1) на сборке мусора (garbage collection) и (2) на подсчете ссылок; при этом сборщики мусора могут использовать поколения (generations) или нет.

Каждое из решений обладает своими плюсами и минусами. Так, управление памятью на основе подсчета ссылок будет страдать от «кольцевых» зависимостей (когда объекта А содержит ссылку на объект B, тот содержит ссылку на объект C, а он опять ссылается на А), но при этом будет обеспечивать детерминированность очистки ресурсов. Сборщик мусора же решит проблему с циклическими ссылками, но расплачиваться за это придется отсутствием детерминированности освобождения ресурсов.

При изучении разных языков программирования, можно стараться запомнить, как именно реализовано автоматическое управление памятью в каждом из них, но после изучения нескольких языков эффективнее будет обобщить эти знания и использовать их повторно. Конечно, каждая платформа или язык программирования обладают своими особенностями, но знания основных механизмов управления памятью существенно сократят кривую обучения, ведь понять и запомнить придется лишь различия, а не весь механизм целиком. Именно поэтому «прагматики» Дэйв Томас и Энди Хант в своей книге «Программист-прагматик. Путь от подмастерья к мастеру» советовали изучать по одному языку программированию каждый год и знакомиться с другими платформами и операционными системами. Подобное расширение кругозора позволит шире смотреть на новые задачи, а также позволит обобщить и структурировать уже существующие знания.

Заключение

Сколько бы «новых» технологий не выходило бы в свет, сколько бы новых уровней абстракции ни изобретали, знание «основ» всегда будет полезным. Значительно проще понять несколько основополагающих принципов, вместо изучения сотни, казалось бы, несвязанных фактов. Знание низкоуровневых концепций можно использовать повторно, что значительно сократит время изучения «новых технологий», поскольку по большей части, они таковыми не являются. Кроме того, рано или поздно «абстракции дадут течь» и чтобы ее устранить, придется понять, как же она устроена внутри.

Attached свойства для ограничения текстового ввода

2012-02-06T21:23:00.001+02:00

WPF – это уже далеко не новая технология на рынке, но относительно новая для меня. И, как это часто бывает при изучении чего-то нового, появляется желание/необходимость в изобретении велосипедов с квадратными колесами и литыми дисками для решения некоторых типовых задач.

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

В Windows Forms эта задача решалась довольно легко, а когда в распоряжении был тот же TextBox от DevExpress со встроенной возможностью ограничения ввода с помощью регулярных выражений, то все было вообще просто. Примеров решения этой же задачи в WPF довольно много, большинство из которых сводится к одному из двух вариантов: использование наследника класса TextBox или добавление attached property с нужными ограничениями.

ПРИМЕЧАНИЕ
Если вам не очень интересны мои рассуждения, а нужны сразу же примеры кода, то вы можете либо скачать весь проект WpfEx с GitHub, либо же скачать основную реализацию, которая содержится в TextBoxBehavior.cs и TextBoxDoubleValidator.cs.

Ну что, приступим?

Поскольку наследование вводит довольно жесткое ограничение, то лично мне в этом случае больше нравится использование attached свойств, благо этот механизм позволяет ограничить применение этих свойств к элементам управления определенного типа (я не хочу, чтобы это attached свойство IsDouble можно было применить к TextBlock-у для которого это не имеет смысла).

Кроме того нужно учесть, что при ограничении ввода пользователя нельзя использовать какие-то конкретные разделители целой и дробной части (такие как ‘.’ (точка) или ‘,’ (запятая)), а также знаки ‘+’ и ‘-‘, поскольку все это зависит от региональных настроек пользователя.

Чтобы реализовать возможность ограничения ввода данных, нам нужно перехватить событие ввода данных пользователем внучную, проанализировать его и отменить эти изменения, если они нам не подходят. В отличие от Windows Forms, в котором принято использование пары событий XXXChanged и XXXChanging, в WPF для этих же целей используются Preview версии событий, которые могут быть обработаны таким образом, чтобы основное событие не срабатывало. (Классическим примером может служить обработка событий от мыши или клавиатуры, запрещающие некоторые клавиши или их комбинации).

И все было бы хорошо, если бы класс TextBox вместе с событием TextChanged содержал бы еще и PreviewTextChanged, которое можно было бы обработать и «прервать» ввод данных пользователем, если мы считаем вводимый текст некорректным. А поскольку его нет, то и приходится всем и каждому свой лисапет изобретать.

Решение задачи

Решение задачи сводится к созданию класса TextBoxBehavior, содержащего attached свойство IsDoubleProperty, после установки которого пользователь не сможет вводить в данное текстовое поле ничего кроме символов +, -, . (разделителя целой и дробной части), а также цифр (не забываем, что нам нужно использовать настройки текущего потока, а не захардкодженные значения).

public class TextBoxBehavior
{
    // Attached свойство булевого типа, установка которого приведет к 
    // ограничению вводимых пользователем данных
    public static readonly DependencyProperty IsDoubleProperty = 
        DependencyProperty.RegisterAttached( 
            "IsDouble", typeof (bool),
             typeof (TextBoxBehavior),
             new FrameworkPropertyMetadata(false, OnIsDoubleChanged));



     
    // Данный атрибут не позволит использовать IsDouble ни с какими другими 
    // UI элементами, кроме TextBox или его наследников
    [AttachedPropertyBrowsableForType(typeof (TextBox))]
    public static bool GetIsDouble(DependencyObject element)
    {}


    
    public static void SetIsDouble(DependencyObject element, bool value)
    {}
    
    // Вызовется, при установке TextBoxBehavior.IsDouble="True" в XAML-е

    private static void OnIsDoubleChanged(DependencyObject d,
                                             DependencyPropertyChangedEventArgs e)
     {
         // Уличная магия
     }
}

Следующим, и основным этапом является реализация той «основной магии», о которой говорится в комментарии в методе OnIsDoubleChanged.

Основная сложность реализации этого метода состоит в следующем: во-первых, нам нужно понять, что является валидными данными, а что нужно отсекать, и во-вторых, нам нужно каким-то образом получить «вводимый» пользователем текст, поскольку готового события, типа PreviewTextChanged в нашем распоряжении нет.

Формирование измененной строки

Для получения строки, вводимой пользователем в методе OnIsDoubleChanged нужно подписаться на два события: (1) PreviewTextInput и (2) перехватить событие «вставки» текста из буфера обмена:

// Вызовется, при установке TextBoxBehavior.IsDouble="True" в XAML-е
private static void OnIsDoubleChanged(DependencyObject d,
                                         DependencyPropertyChangedEventArgs e)
{
    // Поскольку мы ограничили наше attached свойство только классом
    // TextBox или его наследниками, то следующее преобразование - безопасно
    var textBox = (TextBox) d;

    
    // Теперь нам нужно обработать два важных слчая:
    // 1. Ручной ввод данных пользователем
    // 2. Вставка данных из буфера обмена
    textBox.PreviewTextInput += PreviewTextInputForDouble;
    DataObject.AddPastingHandler(textBox, OnPasteForDouble);
}

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

private static void PreviewTextInputForDouble(object sender,
    TextCompositionEventArgs e)
{
    // e.Text содержит только новый текст, так что без текущего 
    // состояния TextBox-а не обойтись


    var textBox = (TextBox)sender; 
    string fullText; 
                 
    // Если TextBox содержит выделенный текст, то заменяем его на e.Text
    if (textBox.SelectionLength > 0)
    {
        fullText = textBox.Text.Replace(textBox.SelectedText, e.Text);
    }
    else
    {
        // Иначе нам нужно вставить новый текст в позицию курсора
        fullText = textBox.Text.Insert(textBox.CaretIndex, e.Text);
    }
     
    // Теперь валидируем полученный текст
    bool isTextValid = TextBoxDoubleValidator.IsValid(fullText);
    
    // И предотвращаем событие TextChanged если текст невалиден
    e.Handled = !isTextValid;
}

Класс TextBoxDoubleValidator

Вторым важным моментом является реализация логики валидации вновь введенного текста, ответственность за которую отведена методу IsValid отдельного класса TextBoxDoubleValidator.

Самым простым способом понять, как должен вести себя метод IsValid этого класса, это написать для него юнит-тест, который покроет все corner case-ы (это как раз один из тех случаев, когда параметризованные юнит-тесты рулят со страшной силой):

ПРИМЕЧАНИЕ
Это как раз тот случай, когда юнит тест – это не просто тест, проверяющий корректность реализации определенной функциональности. Это как раз тот случай, о котором неоднократно говорил Кент Бек, описывая accountability; прочитав этот тест можно понять, о чем думал разработчик метода валидации, «повторно использовать» его знания и найти ошибки в его рассуждениях и, тем самым, вероятно и в коде реализации. Это не просто набор тестов – это важная часть спецификации этого метода!

[TestCase("", Result = true)]
[TestCase(".", Result = true)]
[TestCase("-.", Result = true)]
[TestCase("-.1", Result = true)]
[TestCase("+", Result = true)]
[TestCase("-", Result = true)]
[TestCase(".0", Result = true)]
[TestCase("1.0", Result = true)]
[TestCase("+1.0", Result = true)]
[TestCase("-1.0", Result = true)]
[TestCase("001.0", Result = true)]
[TestCase(" ", Result = false)]
[TestCase("..", Result = false)]
[TestCase("..1", Result = false)]
[TestCase("1+0", Result = false)]
[TestCase("1.a", Result = false)]
[TestCase("1..1", Result = false)]
[TestCase("a11", Result = false)]
[SetCulture("en-US")]
public bool TestIsTextValid(string text)
{
    bool isValid = TextBoxDoubleValidator.IsValid(text);
    Console.WriteLine("'{0}' is {1}", text, isValid ? "valid" : "not valid");
    return isValid;
}

Тестовый метод возвращает true, если параметр text является валидным, и это означает, что соответствующий текст можно будет вбить в TextBox с attached свойством IsDouble. Обратите внимание на несколько моментов: (1) использование атрибута SetCulture, который устанавливает нужную локаль и (2) на некоторые входные значения, такие значения как “-.”, которые не являются корректными значениями для типа Double.

Явная установка локали нужна для того, чтобы тесты не падали у разработчиков с другими персональными настройками, ведь в русской локали, в качестве разделителя используется символ ‘,’ (запятая), а в американской – ‘.’ (точка). Такой странный текст, как “-.” является корректным, поскольку мы должны пользователю завершить ввод, если он хочет ввести строку “-.1”, которая является корректным значением для Double. (Интересно, что на StackOverflow для решения этой задачи очень часто советуют просто использовать Double.TryParse, который явно не будет работать в некоторых случаях).

ПРИМЕЧАНИЕ
Я не хочу захламлять статью деталями реализации метода IsValid, хочу лишь отметить использование в теле этого метода ThreadLocal<T>, который позволяет получить и закэшировать DoubleSeparator локальный для каждого потока. Полную реализацию метода TextBoxDoubleValidator.IsValid можно найти здесь, более подробную информацию об ThreadLocal<T> можно почитать у Джо Албахари в статье Работа с потоками. Часть 3.

Альтернативные решения

Помимо перехвата событий PreviewTextInput и вставки текста из буфера обмена существуют и другие решения. Так, например, я встречал попытку решить эту же задачу путем перехвата события PreviewKeyDown с фильтрацией всех клавиш кроме цифровых. Однако это решение сложнее, поскольку все равно придется заморачиваться с «суммарным» состоянием TextBox-а, да и чисто теоретически, разделителем целой и дробной части может быть не один символ, а целая строка (NumberFormatInfo.NumberDecimalSeparator возвращает string, а не char).

Есть еще вариант в событии KeyDown сохранить предыдущее состояние TextBox.Text, а в событии TextChanged вернуть ему старое значение, если новое значение не устраивает. Но это решение выглядит неестественным, да и реализовать его с помощью attached свойств будет не так-то просто.

Заключение

Когда мы в последний раз обсуждали с коллегами отсутствие в WPF полезных и весьма типовых возможностей, то мы пришли к выводу, что этому есть объяснение, и в этом есть и положительная сторона. Объяснение сводится к тому, что от закона дырявых абстракций никуда не деться и WPF будучи «абстракцией» весьма сложной, течет как решето. Полезная же сторона заключается в том, что отсутствие некоторых полезных возможностей заставляет нас иногда думать (!) и не забывать о том, что мы программисты, а не умельцы копи-пасты.

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

18 фактов о Джоне Ските

2012-01-30T21:33:00.001+02:00

Практически на каждом своем выступлении, будь то семинар или воркшоп, рано или поздно заходит речь об известных представителей .NET community и одним из первых в этом списке идет Джон Скит (Jon Skeet), гуру stackoverflow.com и автор одной из самых интересных книг по языку C# - “C# in Depth”.

Чтобы рассказать о том, кто есть Джон и что он сделал для индустрии, достаточно привести о нем несколько фактов. Многие слышали факты о Чаке Норрисе, такие как «Чак Норрис досчитал до бесконечности. Дважды» или что «Чак Норрис единственный человек, который обыграл стену в теннис». Но далеко не все знают о том, что подобные факты есть и о Джоне Ските (сам факт существования которых уже о многом говорит).

Итак, вот они:

1. Джон Скит может делить на 0.
2. Если код Джона Скита не компилируется, то компилятор извиняется за это.
3. Если поискать в Гугле “guru”, то Гугл выдает: «Возможно, вы имели ввиду: Джон Скит?»
4. Джон Скит ради интереса написал последний проект полностью в MS Paint.
5. Джон Скит не следует стандартам кодирования, его код и есть стандарт кодирования.
6. Однажды Джон Скит ответил на вопрос за 42 секунды до того, как он был задан.
7. Джон Скит неизменяем. Если что-то должно измениться, то изменяется вся вселенная.
8. Джон Скит уже написал книгу по C# 6.0. Через три года Андерс Хейлсберг прочитает ее, чтобы выяснить, все ли правильно поняла команда разработчиков языка C#.
9. Джон Скит единственный человек из топ 100 пользователей SO. Остальные – это боты, написанные Джоном, чтобы как-то развеяться между ответами на вопросы.
A. «Обедающие философы» ждут, пока доест Джон Скит.
B. Когда Джон Скит указывает на null, null дрожит от страха.
C. Если Джон Скит публикует дубликат на StackOverflow, то исходный вопрос закрывается, как дубликат.
D. При вызове метода обратного вызова Джона Скита, CLR добавляет «пожалуйста».
E. Джон Скит не пользуется отладчиком. В его программах не бывает ошибок.
F. CLR использует Just-In-Time компиляцию, потому что каждая машинная инструкция должна быть одобрена Джоном Скитом.
10. Когда выполняется программа Джона Скита, сборщик мусора отдыхает. Его объекты сами знают, когда самоуничтожиться.
11. Мозг Джона Скита работает в двоичном режиме.
12. Изначально сайт StackOverflow.com назывался JonSkeet.com и был переименован только благодаря скромности Джона Скита.
13. У Джона Скита не бывает проблем с производительностью. Он заставляет всю вселенную ждать своей очереди.
14. Джон Скит может выполнить бесконечный цикл за 1.55 секунды.
15. Джон Скит не отвечает на вопросы на StackOverflow, он смотрит на них и они сами находят ответ.
16. Потоки Джона Скита никогда не спят. Они выжидают.
17. Если Интернет – это паутина, то Джон Скит – это паук.
18. Джон Скит может выполнять парное программирование с самим собой.

Большая часть фактов взята отсюда, часть немного переделана, часть оставлена без изменений. Еще один факт, который не входит в перечень выше, но о котором стоит упомянуть, следующий. Джон, на самом деле, не является «профессиональным» .NET разработчиком, поскольку на работе (в Гугле) он пишет на Java, а язык C# является всего лишь его хобби;)

Первый workshop по .NET и архитектуре

2012-01-18T23:42:00.001+02:00

Завтра, 19 января мы в Учебном Центре попробуем провести первый workshop по .NET и архитектуре. Правда посвящен он будет не совсем обычной, казалось бы, для такого воркшопа теме, а именно “Приемам функционального программирования на платформе .NET”.

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

Основное отличие воркшопа (или воршопа, как выразился кто-то из наших девочек в одной из рассылок) заключается в том, что это будет скорее полуторачасовой обмен опытом, нежели формат преподаватель/студент. Это означает более живую дискуссию, нежели на семинаре, ну а что конкретно из этого получится – узнаем завтра.

Да, если кому интересно, то вход свободный. Место проведения: Киев, Радищева, 10/14, корпус Б. Четверг, 19 января, 17-30. Регистрироваться на это дело все равно нужно, и сделать это можно здесь.

The Art of Unit Testing

2012-01-11T23:12:00.001+02:00

Есть некоторые категории знаний, которые профессиональный разработчик познает в процессе своей работы, не прилагая к этому особенных дополнительных усилий. Вот, например, мало кто из нас читал замечательную книгу по регулярным выражениям Джеффри Фирддла, чтобы познакомиться с одноименной темой. Безусловно, есть масса людей, для которых «регвыры» стали смыслом жизни и без подобных фундаментальных знаний никак не обойтись. Но в большинстве случаев пары мелких статей и справки в соответствующем разделе документации будет достаточно для более или менее комфортной работы с регулярными выражениями (если такое понятие, как «комфортная работа» с регулярными выражениями вообще существуетJ).

Аналогичным образом мы обычно относимся и к изучению юнит тестирования. Ведь юнит-тесты – это же не rocket science; для их изучения не требуется многолетняя подготовка и множество бессонных ночей проведенных за изучением толстенных «талмудов» от гуру юнит-тестирования. Концепцию автоматизированного тестирования кода можно объяснить за 10 минут, а познакомившись с одним из тестовых фреймворков семейства xUnit (еще 15 минут), вы сможете работать с любым другим фреймворком практически сразу же. Затем нужно будет потратить еще 20 минут на изучение какого-нибудь изоляционного фреймворка, типа Rhino Mocks, и, вуаля, у нас есть еще один профессионал в области юнит-тестов.

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

Забегая вперед, стоит сказать, что я заблуждался и книга The Art of Unit Testing by Roy Osherove будет полезна даже опытным разработчикам, но давайте обо всем по порядку.

Структура книги такова, что автор идет от наиболее простых и базовых понятий к более продвинутым вещам. Начинается все с простых примеров и определений, дается введение в TDD, рассказывается о «швах» приложения и об использовании «фейков», таких как моки и стабы, а также кратко описываются разные изоляционные фреймворки.

С самого начала Рой пытается вдолбить в голову читателя одну важную мысль: качественные тесты не менее важны, чем качественный production код! О том, что такое хорошие тесты, посвящена целая глава 7 The pillars of good tests, но даже за ее пределами тень «хороших» тестов будет преследовать читателя практически постоянно. О качестве кода написаны, наверное, десятки книг и бесчисленное множество статей; все мы знаем о том, как важно писать простой в сопровождении код и что делать для повышения его качества. Но к качеству тестов наше отношение зачастую не столь осмысленное, хотя плохие тесты могут испортить вам жизнь ничуть не хуже го$#о-кода в бизнес-логике.

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

Очень здорово, что помимо принципов юнит тестирования Рой уделяет внимание и таким важным аспектам, как внедрение юнит тестирования в организации, тестирование унаследованного (legacy) кода и влиянию тестов на дизайн приложения. В вопросах дизайна Рой считает, что testable дизайн обусловлен, прежде всего, ограничениями языка или среды программирования и не существует в динамических языках программирования (поскольку там мы «замокать» можем все, что угодно). Я с таким подходом не согласен, поскольку считаю, что хороший дизайн по умолчанию хорошо тестируем, и что возможность написания юнит тестов является хорошим признаком простоты контрактов классов и признаком того, что класс не берет на себя слишком много.

ПРИМЕЧАНИЕ
Подробнее об использовании юнит тестов как «лакмусовой бумажки» плохого дизайна можно почитать в заметке “Идеальная архитектура”.

По признанию самого Роя он потратил на написание книги 3 года - и это больше, чем он потратил на «создание» двух своих детейJ и периодически это чувствуется. Так, например, в разных местах книги используются разный формат диаграмм классов, иногда отличается наименование тестовых классов и методов, да и вообще, ощущение дежавю периодически посещает. Есть и другие мелкие замечания. Так, автор на протяжении двух сотен страниц использует стандартный синтаксис утверждений библиотеки NUnit, а с 200-й страницы, вдруг начинает использовать Assert.That и заявляет о том, что этот синтаксис более декларативен. Очевидно, что года через полтора после начала работы над книгой Рой добрался до этого синтаксиса, который ему понравился, а сил и времени на изменение предыдущих примеров уже не было.

Единственным существенным замечанием к этой книге является слабое раскрытие темы параметризованных юнит тестов. Да, Рой упоминает вскользь об этой возможности, но уж очень поверхностно и где-то ближе к концу книги. Чувствуется некоторая несправедливость, когда о том, что плохо рассчитывать на порядок запуска юнит тестов автор тратит 4 (!) страницы, а на параметризованные тесты, которые могут сэкономить массу времени и существенно повысить читабельность тестов, тратится от силы 2 абзаца.

Можно найти и другие моменты, в которых ваше мнение будет отличаться от мнения автора, но в целом, книга “The Art of Unit Testing” является одним из лучших источников информации по теме юнит тестирования, которая может либо изменить ваше мировоззрение в правильную сторону, либо обобщить и структурировать уже существующие знания.

Оценка: 4+

Дополнительные ссылки по теме

Ретроспектива 2011

2012-01-03T09:39:00.001+02:00

Мы живем с вами в удивительное время, ежедневно занимаемся любимым делом, за которое, к тому же, еще и неплохо платят. Количество «новых» технологий растет, как на дрожжах, поэтому сейчас, как никогда раньше, важно уметь отфильтровывать важное от несущественного и понимать, в какие направления следует «инвестировать» свое время. Ведь на самом деле, все эти новые технологии - не что иное, как хорошо забытые старые; зачастую это лишь проверенные временем идеи, которые воплощаются в жизнь в новой форме.

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

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

Самое интересное, что изначально это заметка начиналась совсем иначе, да и вообще, вместо желания пофилософствовать я хотел кратенько подвести итоги года и напомнить о тех интересных статьях, которые здесь появились, но потом, как говорится, «Остапа понесло» (с). Поскольку финальная цель все же не изменилась, так что теперь, с помощью нехитрого литературного приема под названием «перескакивание с одной темы на другую» давайте я постараюсь вернуться к исходной теме.

Большинство моих статей можно разделить на 3 категории: (1) язык C# и платформа .NET; (2) архитектура, проектирование или философия программирования; (3) ревью или анонсы книг. Часть статей первой и второй категории оказались в журналах RSDN Magazine и Технология Клиент-Сервер, а часть из них попала на сайт SoftwarePeople.ru (не знаю почему, но эти ребята вызывают у меня нескрываемое уважение; может быть, потому что именно они привозили Тима Листера и Тома ДеМарко, не знаю), так что можно сделать вывод, что направление выбрано более или менее верное.

Итак, вот некоторые заметки, которые я бы хотел выделить за прошедший год (кстати, если у кого-то будет другое мнение по этому поводу – буду рад его услышать).

По языку C# и платформе .NET

Философия и бла-бла-бла

Книги

Классические книги по C#/.NET

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

Стабы и моки

2011-12-19T06:33:00.001+02:00

Существует категория классов, которые тестировать весьма просто. Если класс зависит только от примитивных типов данных и не имеет никаких связей с другими бизнес-сущностями, то достаточно создать экземпляр этого класса, «пнуть» его некоторым образом путем изменения свойства или вызова метода и проверить ожидаемое состояние.

Это самый простой и эффективный способ тестирования, и любой толковый дизайн отталкивается от подобных классов, которые являются «строительными блоками» нижнего уровня, на основе которых затем уже строятся более сложные абстракции. Но количество классов, которые живут в такой «изоляции» не много по своей природе. Даже если мы по нормальному выделили всю логику по работе с базой данных (или сервисом) в отдельный класс (или набор классов), то рано или поздно появится кто-то, кто эти классы будет использовать для получения более высокоуровневого поведения и этого «кого-то» тоже нужно будет тестировать.

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

// Модель представления, предназначенная для управления входом 
// пользователя в систему
public class LoginViewModel
{ 
    public LoginViewModel() 
    { 
        // Читаем имя последнего пользователя
        UserName = ReadLastUserName(); 
    } 
    
    // Имя пользователя; может быть изменено пользователем
    public string UserName { get; set; } 
    
    // Логиним пользователя UserName 
    public void Login() 
    { 
        // Не обращаем внимание на дополнительную логику, которая должна быть 
        // выполнена. Считаем что нам достаточно просто сохранить имя текущего
        // пользователя
        SaveLastUserName(UserName); 
    } 
    
    // Читаем имя последнего залогиненного пользователя
    private string ReadLastUserName() 
    { 
        // Не важно, как она на самом деле реализована ...
        // Просто возвращаем что-нибудь, чтобы компилятор не возражал
        return "Jonh Doe"; 
    } 
    
    // Сохраняем имя последнего пользователя
    private void SaveLastUserName(string lastUserName) 
    { 
        // Опять таки, нам не интересно, как она реализована
    }
}

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

ПРИМЕЧАНИЕ
Не нужно бросать в меня камнями с криками «Да кто сегодня вообще такую хрень написать можно? Ведь уже столько всего написано о вреде такого подхода, да и вообще, у нас есть юнити-шмунити и другие полезности, так что это нереальный баян двадцатилетней давности!». Кстати, да, это баян, но, во-первых, речь не юнитях и других контейнерах, а о базовых принципах, а во-вторых, подобное «интеграционное» тестирование все еще невероятно популярно, во всяком случае, среди многих моих «зарубежных» коллег.

Создания «швов» для тестирования приложения

Даже если не задумываться о том, какое количество новомодных принципов проектирования нарушает наша вью-модель, четко видно, что ее дизайн несколько … убог. Ведь даже если проектировать старым ~~дедовским~~ бучевским методом, то становится понятно, что всю работу по сохранению имени последнего пользователя, логику по работе с базой данных (или другим внешним источником данных) нужно спрятать подальше с глаз долой и сделать это «проблемой» кого-то другого и использовать уже этого «кого-то» в качестве «строительного блока» для получения более высокоуровневого поведения:

internal class LastUsernameProvider
{ 
    // Читаем имя последнего пользователя из некоторого источника данных
    public string ReadLastUserName() { return "Jonh Doe"; } 
    // Сохраняем это имя, откуда его можно будет впоследствии прочитать
    public void SaveLastUserName(string userName) { }
}
 
public class LoginViewModel
{ 
    // Добавляем поле для получения и сохранения имени последнего пользователя
    private readonly LastUsernameProvider _provider = 
                         new LastUsernameProvider(); 
    
    public LoginViewModel() 
    { 
        // Теперь просто вызываем функцию нового вспомогательного класса
        UserName = _provider.ReadLastUserName(); 
    } 
    
    public string UserName { get; set; }
    
    public void Login() 
    { 
        // Все действия по сохранению имени последнего пользователя также
        // делегируем новому классу
        _provider.SaveLastUserName(UserName); 
    }
}

Пока что написание модульного теста все еще остается затруднительным, но становится понятным, как можно достаточно просто «подделать» реальную реализацию класса LastUsernameProvider и сымитировать нужное для нас поведение. Достаточно выделить методы этого класса в отдельный интерфейс или просто сделать их виртуальными и переопределить в наследнике. После чего останется лишь «прикрутить» нужный нам объект в нашу вью-модель.

ПРИМЕЧАНИЕ
Честно говоря, я не большой фанат изменений в дизайне только ради «тестируемости» кода. Как показывает практика, нормальный ОО дизайн либо уже является достаточно «тестируемым» или же требует лишь минимальных телодвижений, чтобы сделать его таковым. Некоторые дополнительные мысли по этому поводу можно найти в заметке «Идеальная архитектура».

Даже не прибегая ни к каким сторонним библиотекам для «инджекта» зависимостей мы можем сделать это самостоятельно несколько простыми способами. Нужную зависимость можно передать через дополнительный конструктор, через свойство или создать фабричный метод, который будет возвращать интерфейс ILastUsernmameProvider.

Давайте рассмотрим вариант с конструктором, который является довольно простым и популярным (при небольшом количестве внешних зависимостей он работает просто прекрасно).

// Выделяем методы в интерфейс
internal interface ILastUsernameProvider
{ 
    string ReadLastUserName(); 
    void SaveLastUserName(string userName);
}
 
internal class LastUsernameProvider : ILastUsernameProvider
{ 
    // Читаем имя последнего пользователя из некоторого источника данных
    public string ReadLastUserName() { return "Jonh Doe"; } 
    // Сохраняем это имя, откуда его можно будет впоследствии прочитать
    public void SaveLastUserName(string userName) { }
}
 
public class LoginViewModel
{ 
    private readonly ILastUsernameProvider _provider; 
    
    // Единственный открытый конструктор создает реальный провайдер
    public LoginViewModel() 
        : this(new LastUsernameProvider()) 
    {} 
    
    // "Внутренний" предназначен только для тестирования и может принимать "фейк"
    internal LoginViewModel(ILastUsernameProvider provider) 
    { 
        _provider = provider; 
        UserName = _provider.ReadLastUserName(); 
    } 

    
    public string UserName { get; set; } 
    
    public void Login() 
    { 
        _provider.SaveLastUserName(UserName); 
    }
}

Поскольку дополнительный конструктор является внутренним (internal), то он доступен только внутри этой сборке, а также «дружеской» сборке юнит-тестов. Конечно, если тестируемые классы являются внутренними, то проблемы не будет ни какой, но поскольку все «клиенты» внутреннего класса находятся в одной сборке, то и контролировать их проще. Подобный подход, основанный на добавлении внутреннего метода для установки «фальшивого» поведения является разумным компромиссом упрощения тестирования кода, не налагая ограничения на использования более сложных механизмов управления зависимостями, типа IoC контейнеров.

ПРИМЕЧАНИЕ
Одним из недостатков при работе с интерфейсами является падение читабельности, поскольку не понятно, сколько реализаций интерфейса существует и где находится реализация того или иного метода интерфейса. Такие инструменты, как Решарпер существенно смягчают эту проблему, поскольку поддерживают не только навигацию к объявлению метода (Go To Declaration), но также и навигацию к реализации метода (Go To Implementation):

Проверка состояния vs проверка поведения

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

Для нормальной реализации этих тестов нам нужна «фейковая» реализация интерфейса, при этом в первом случае, нам нужно вернуть произвольное имя последнего пользователя в методе ReadLastUserName, а во втором случае – удостовериться, что вызван метод SaveLastUserName.

Именно в этом и отличаются два типа «фейковых» классов: стабы предназначены для получения нужного состояния тестируемого объекта, а моки применяются для проверки ожидаемого поведения тестируемого объекта.

Стабы никогда не применяются в утверждениях, они простые «слуги», которые лишь моделируют внешнее окружение тестового класса; при этом в утверждениях проверяется состояние именно тестового класса, которое зависит от установленного состояния стаба.

// Стаб возвращающее указанное имя последнего пользователя
internal class LastUsernameProviderStub : ILastUsernameProvider
{ 
    // Добавляем публичное поле, для простоты тестирования и 
    // возможности повторного использования этого класса
    public string UserName; 
    
    // Реализация метода очень простая - просто возвращаем UserName
    public string ReadLastUserName() 
    { 
        return UserName; 
    } 
    
    // Этот метод в данном случае вообще не интересен
    public void SaveLastUserName(string userName) { }
}
 
[TestFixture]
public class LoginViewModelTests
{ 
    // Тестовый метод для проверки правильной реализации конструктора вью-модели
    [Test] 
    public void TestViewModelConstructor() 
    { 
        var stub = new LastUsernameProviderStub(); 
        
        // "моделируем" внешнее окружение
        stub.UserName = "Jon Skeet"; // Ух-ты!!
        var vm = new LoginViewModel(stub); 
        
        // Проверяем состояние тестируемого класса
        Assert.That(vm.UserName, Is.EqualTo(stub.UserName)); 
    }    
}

У моков же другая роль. Моки «подсовываются» тестируемому объекту, но не для того, чтобы создать требуемое окружение (хотя они могут выполнять и эту роль), а прежде всего для того, чтобы потом можно было проверить, что тестируемый объект выполнил требуемые действия. (Именно поэтому такой вид тестирования называется behavior testing, в отличие от стабов, которые применяются для state-based testing).

// Мок позволяет проверить, что метод SaveLastUserName был вызван 
// с определенными параметрами
internal class LastUsernameProviderMock : ILastUsernameProvider
{ 
    // Теперь в этом поле будет сохранятся имя последнего сохраненного пользователя
    public string SavedUserName; 
    
    // Нам все еще нужно вернуть правильное значение из этого метода,
    // так что наш "мок" также является и "стабом"
    public string ReadLastUserName() { return "Jonh Skeet";} 
    
    // А вот в этом методе мы сохраним параметр в SavedUserName для 
    public void SaveLastUserName(string userName) 
    { 
        SavedUserName = userName; 
    }
}
 
// Проверяем, что при вызове метода Login будет сохранено имя последнего пользователя
[Test]
public void TestLogin()
{ 
    var mock = new LastUsernameProviderMock(); 
    var vm = new LoginViewModel(mock); 
    
    // Изменяем состояние вью-модели путем изменения ее свойства
    vm.UserName = "Bob Martin"; 
    // А затем вызываем метод Login
    vm.Login(); 
    // Теперь мы проверяем, что был вызван метод SaveLastUserName
    Assert.That(mock.SavedUserName, Is.EqualTo(vm.UserName));
}

А зачем мне знать об этих отличиях?

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

Однако рано или поздно вам может надоесть это чудесное занятие по ручной реализации интерфейсов и вы обратите свое внимание на один из Isolation фреймворков, таких как Rhino Mocks, Moq или Microsoft Moles. Там эти термины встретятся обязательно и понимание отличий между этими типами фейков вам очень пригодится.

Я осознанно не касался ни одного из этих фреймворков, поскольку каждый из них заслуживает отдельной статьи и ИМО лишь усложнит понимание этих понятий. Но если вам все же интересно посмотреть на некоторые из этих фреймворков более подробно, то об одном из них я писал более подробно: “Microsoft Moles”.

Кто такой “хороший программист”?

2011-11-29T03:40:00.001+02:00

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

Что отличает хорошего программиста от посредственного? И как самому стать хорошим программистом и заслужить среди друзей и коллег «почет и уважение»?

Честно говоря, не знаю. Зачастую даже сложно сказать, что понимается под этой фразой «хороший программист». С одной стороны, мы привыкли думать, что «хороший» программист – это обязательно гик в очках и растянутом свитере, победитель олимпиады по программированию, который в уме может умножать шестизначные цифры и читать машинный код прямо в двоичном формате. С другой стороны, на собеседованиях мы тоже пытаемся найти «хороших» программистов и там у нас есть другие критерии отбора: поскольку победителей олимпиад не так и много, а вакансий «ведущих» и «главных» пруд пруди, то эта планка опускается до более приземленного уровня. Так на собеседованиях мы задаем (или нам задают) вопросы попроще: что-нибудь о конкретных языках или технологиях, в результате чего проверяется скорее память кандидата, а не его умение думать головой.

Думать головой? Ну что ж, это очень даже неплохая отличительная черта хорошего программиста. Как ни крути, но именно серое (или какое оно там) вещество, расположенное в нашей голове, привело нас в эту профессию; и именно «думанием» профессиональный программист зарабатывает себе на жизнь, занимаясь этим большую часть своего времени. А раз так, то почему бы не подумать о том, как стать, если не хорошим программистом в общепринятом понимании, то хотя бы немного лучше по сравнению с тем, кем был вчера.

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

Вот, например, как часто вы задаете себе подобные вопросы: «Чем отличается ваш код сегодня от вашего кода полугодичной давности? Становится ли он лучше или, быть может, он уже давно достиг совершенства? Как изменились ваши взгляды на разработку ПО за это время? Что нового вы узнали из этой безграничной области? Когда в последний раз вы написали что-либо ради интереса, а не ради «производственной необходимости»? Когда в последний раз вы помогли кому-то с техническим вопросом?»

Конечно, ответы на эти вопросы не скажут, хороший вы программист или нет. Смысл их в том, чтобы понять, становитесь вы «лучше» или топчетесь на месте. Хороший программист – это не гениальный подросток, а простой толковый парень или девушка, любящие свое дело. Человек, в котором сочетается прагматизм и стремление к совершенству, любовь к новому и глубокие знания настоящего, стремление к обучению и желание учить кого-то еще. Большинство хороших программистов прекрасно понимают, что они знают очень мало и находят в себе желание и стремление это исправлять. У каждого из нас свой путь к получению новых знаний и здесь, как и в программировании, тоже не стоит искать «серебряную пулю».

Так что, учите, читайте, узнавайте что-то новое, пишите и рассказывайте об этом. И вообще, не думайте о том, хороший вы программист или нет, глупости все это. Ведь самое интересное в этом деле – это путь, а не результат!

Идеальная архитектура

2011-11-23T22:51:00.001+02:00

Существует много разных взглядов на разработку архитектуры и дизайна современных приложений. Некоторые архитекторы стремятся продумать все до мелочей, разрисовать use case-ы всех классов и модулей, проанализировать миллион возможных способов их использования, все их обязательно задокументировать и уже потом приступить к этапу кодирования.

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

Когда речь заходит о дизайне классов, архитектуре модулей или об ответственности различных слоев приложения, то решающую роль при их проектировании играют понятия сцепления (cohesion) и связанности (coupling). Еще Кристофер Александер, «папа» шаблонов проектирования, писал о том, что основной задачей при декомпозиции системы является осуществление двух условий: (1) максимизация связей внутри компонентов (высокое внутреннее сцепление, tight internal cohesion) и (2) минимизация связей между компонентами (низкая внешняя связанность, loose external coupling).

ПРИМЕЧАНИЕ
Подробнее об истории возникновения такого уникального понятия, как шаблоны проектирования (design patterns) можно прочитать в статье: Шаблоны проектирования. История успеха.

Благодаря Бобу Мартину и некоторым другим известным личностям, в нашем арсенале появились принципы, такие как S.O.L.I.D., которые позволяют определить более точно (или, быть может, более формально), отвечает ли дизайн системы приведенным выше основополагающим принципам или нет. Я же обычно, прежде чем переходить к «тяжелой артиллерии», в виде подобных принципов использую более простой подход. Я задаю себе следующий вопрос: «а насколько реально покрыть основную функциональность этого класса модульными тестами?» Если ответ положительный, то наверняка указанный класс обладает достаточно высоким сцеплением и низкой связанностью с другими классами. Если даже чисто теоретическое написание юнит-теста невозможно, поскольку ответственность класса непонятна, он содержит кучу несвязанных друг с другом полей и методов, и зависит от двух десятков других сущностей, тогда с дизайном явно что-то не так.

Рисунок 1 – И как это чудо тестировать? А ведь в реальной жизни связей может быть в пару раз больше

СОВЕТ
Используйте принцип «тестируемости» класса в качестве «лакмусовой бумажки» хорошего дизайна класса. Даже если вы не напишите ни строчки тестового кода (хотя зря!), ответ на этот вопрос в 90% случаев поможет понять, насколько все «хорошо» или «плохо» с его дизайном.

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

При решении архитектурных вопросов, таких как выбор платформы построения распределенных приложений, выбор UI-фреймворка или архитектуры слоя доступа данных, разумно задавать себе другой вопрос: «А что будет, если принятое сейчас решение будет ошибочным?» или «А вообще, должен ли я принять окончательное решение прямо сейчас?».

Абстракция и инкапсуляция, все еще являются нашими лучшими друзьями и вот как раз они прекрасно применимы, как к отдельным классам, так и целым модулям или слоям приложения. Использования WCF должно быть максимально спрятано в коммуникационном слое, UI фреймворк не должен торчать из всех базовых классов, а архитектура слоя доступа к данным не должна налагать ограничения на бизнес-классы приложения. Конечно, согласно “закону дырявых абстракций”, периодически ненужные подробности все же будут пробираться в другие слои приложения, но нам нужно хотя бы постараться их ограничить.

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

СОВЕТ
Если «лакмусовой бумажкой» качества дизайна классов была их тестируемость, то лакмусовой бумажкой качества архитектуры можно считать ее «гибкость». Спросите у себя: «А что будет, если текущее архитектурное решение окажется неверным?», «Какое количество модулей подвергнется при этом изменениям?». По возможности, архитектурные решения не должны «вырубаться в камне», и последствия архитектурных ошибок должны быть в разумной степени ограничены.

Отступление от темы. Clean Architecture от Боба Мартина

О важности прагматичного взгляда на архитектуру написано довольно много. Гради Буч в своей знаменитой книге неоднократно останавливается на важности абстрагирования и инкапсуляции на самых разных уровнях. В замечательной книге «97 этюдов для архитекторов программных систем» многие авторы не раз говорят о вреде «вырубания решений в камне» и преимуществах простоты перед гибкостью в вопросах архитектуры.

Одним из последних известных авторов, тему архитектуры поднял Боб Мартин. В одной из своих презентаций, а также в одном из своих постов об архитектуре Боб написал следующее: … Хорошая архитектура позволяет ОТКЛАДЫВАТЬ принятие ключевых решений… Хорошая архитектура максимизирует количество НЕ ПРИНЯТЫХ решений.

Я, конечно, не на все 100% согласен со стариной Бобом о том, что можно отложить все архитектурные решения, но согласен с тем, что хорошая архитектура позволяет отложить многие из них. И здесь даже дело не только и не столько во времени принятия этих решений, а в стоимости их последующих исправлений.

ПРИМЕЧАНИЕ
Презентацию Боба Мартина, о которой я упоминал выше, можно найти здесь, небольшое видео, с обсуждением этого вопроса, здесь. И вот несколько постов Боба на эту же тему: Clean Architecture и Screaming Architecture.

Заключение

Я очень советую читателям не воспринимать приведенные выше принципы как «серебряную пулю», которая гарантированно даст вам ответ на вопрос о том, как получить «идеальный дизайн» или «идеальную архитектуру». Подобные вопросы могут лишь показать пробелы, но не могут показать правильный путь, они способны лишь зажечь тревожный огонек в вашей голове и побудить вас к более тщательному анализу дизайна класса или принимаемых архитектурных решений.

Observable.Generate и перечисление списков

2011-11-09T23:45:00.001+02:00

В библиотеке реактивных расширений (a.k.a. Rx – Reactive Extensions) существует вспомогательный метод Observable.Generate, который позволяет генерировать простые observable-последовательности.

IObservable<string> xs = Observable.Generate<int, string>(     
     initialState: 0, // начальное значение
     condition: x => x < 10, // условие завершения генерации
     iterate: x => x + 1, // изменение значения
     resultSelector: x => x.ToString() // преобразование текущего значения в результат
     );
 
xs.Subscribe(x => Console.WriteLine("x: {0}", x));

ПРИМЕЧАНИЕ
Обратите внимание на явное указание параметров обобщенного метода. Причина такого странного поведения (ведь обобщенные параметры методов должны спокойно выводиться компилятором) в том, что в компиляторе языка C# есть известный баг, в результате которого, вывод типов плохо дружит с именованными параметрами. Подробнее об этом можно почитать на stackoverflow или на connect-e. Да, кстати, это дело пофиксили в Visual Studio 11.

Метод Generate напоминает простой цикл for, который состоит из тех же самых этапов: инициализации начального значения, условия выхода из цикла и изменения переменной цикла. И если мы захотим сгенерировать обычную последовательность в памяти, то мы будем использовать именно цикл for внутри блока итераторов:

static IEnumerable<string> GenerateSequence()
{
     for (
         int x = 0; //initialState
         x < 10;  // condition
         x = x + 1  // iterate
         )
     {
         yield return x.ToString(); // resultSelector
     }
}
 
static void Main(string[] args)
{
     var xs = GenerateSequence();
     foreach (var x in xs)
         Console.WriteLine("x: {0}", x);
}

Оба варианта кода эквивалентны, но если в первом случае создается push-последовательность (в виде интерфейса IObservable of T), которая будет самостоятельно уведомлять о поступлении новых элементов, то во втором случае мы получаем pull-последовательность (в виде интерфейса IEnumerable of T), из которой нужно «плоскогубцами» эти элементы вытаскивать.

ПРИМЕЧАНИЕ
Если очень коротко, то pull-модель – это такая модель взаимодействия приложения с окружающим миром, когда ведущую роль выполняет именно приложение. Если посмотреть на интерфейс IEnumerable, то именно вызывающий код «управляет» потоком элементом, вызывая метод MoveNext для перехода к следующему. В push-модели действия разворачиваются по-другому: внешнее окружение само уведомляет приложение о некоторых событиях (например, о наличии новых данных), а приложение лишь «реагирует» на них. Подробнее об этих моделях, о дуализме интерфейсов IEnumerable/IObservable, а также о других возможностях библиотеки реактивных расширений можно почитать в статье: Реактивные расширения и асинхронные операции.

Поскольку интерфейсы push и pull-последовательностей (IObservable of T и IEnumerable of T, соответственно) являются такими похожими, то к нам в голову легко может затесаться мысль о преобразовании из одной формы последовательности в другую:

int[] ai = new[] { 1, 2, 3 };
 
IObservable<int> oi = Observable.Generate(
     /*initialState:*/ ai.GetEnumerator(),
     /*condition:*/ e => e.MoveNext(),
     /*iterate:*/ e => e,
     /*resultSelector:*/ e => (int)e.Current
     );
 
oi.Subscribe(i => Console.WriteLine("i: {0}", i));

В целом ничего криминального, и при выполнении этого кода мы ожидаемо получим:

1
2
3

Но что, если вместо массива нам захочется сделать тоже самое со списком:

List<int> li = new List<int> {1, 2, 3};
IObservable<int> oi = Observable.Generate(
     /*initialState:*/ li.GetEnumerator(),
     /*condition:*/ e => e.MoveNext(),
     /*iterate:*/ e => e,
     /*resultSelector:*/ e => e.Current
     );
 
oi.Subscribe(i => Console.WriteLine("i: {0}", i));

И, совершенно естественно, что в этом случае мы получим … бесконечную последовательность нулей.

ПРИМЕЧАНИЕ
Да, я знаю, что самым простым способом преобразования простой последовательности в observable-последовательность, является использование метода расширения Observable.ToObservable, который «расширяет» интерфейс IEnumerable. Но, предположим, что мы либо о нем не знаем, либо нам нужна более сложная логика, доступная в методе Generate.

Причина такого поведения кроется в том, что енумератор класса List of T (а также большинства других коллекций BCL) является структурой, а не классом. А, как нам известно, изменяемые структуры (ведь енумератор изменяет свое внутреннее состояние) не очень вяжется с передачей по значению. В результате этого мы постоянно пробуем изменить копию енумератора, а не исходный енумертор, переданный нами в методе Generate.

Изменяемые структуры – это зло, и только стремление к оптимизации кода для наиболее распространенного сценария использования енумераторов привели к тому, что разработчики BCL сделали их структурами, а не классами. Поскольку наиболее частым сценарием использования енумерторов в C# 2.0 было использование его в цикле foreach, который никак не страдал от проблем с изменяемыми структурами, то было принято решение сэкономить несколько тактов процессора и использовать для енумератора именно структуру, а не класс.

ПРИМЕЧАНИЕ
Подробности о том, почему это было сделано именно так, можно почитать в одном из постов Sasha Goldshtein, а также в ответе Эрика Липперта на stackoverflow. О других же проблемах изменяемых значимых типов можно почитать в статье: О вреде изменяемых значимых типов.

Решается эта проблема довольно просто: для этого достаточно привести исходное значение енумератора к интерфейсу, что приведет к его упаковке и последующей модификации «общей» переменной, расположенной в управляемой куче, а не к изменению копии:

List<int> li = new List<int> {1, 2, 3};              
IObservable<int> oi = Observable.Generate(
     /*initialState:*/ (IEnumerator<int>)li.GetEnumerator(),
     /*condition:*/ e => e.MoveNext(),
     /*iterate:*/ e => e,
     /*resultSelector:*/ e => e.Current
     );
 
oi.Subscribe(i => Console.WriteLine("i: {0}", i));

Повторная генерация исключений

2011-11-03T00:24:00.001+02:00

Обработка исключений появилась в mainstream языках программирования вот уже более трех десятилетий назад, но сегодня все еще можно встретить разработчиков, которые боятся их использовать. Некоторые считают, что генерация исключений в конструкторе повредит их хрупкой карме и их настигнет кара в виде поддержки кода двадцатилетней давности, написанного стадом безумных индусов. Некоторые все еще застряли в эпохе языка С и даже в языке C# интенсивно используют коды возврата в виде магических чисел или даже строк, считая, что исключения придумали трусы, а настоящие самураи могут обойтись и без них. (Хотя мы-то с вами знаем, что настоящие самураи следуют “Принципу самурая” и никаких кодов возврата не используют).

Дополнительную сложность добавляют конкретные платформы и языки программирования. Сегодня на собеседовании C# разработчика, когда речь заходит об обработке исключений, обязательно прозвучит вопрос: “А в чем отличие “проброса” исключения с помощью конструкций throw; и throw ex;?”. И хотя, это страшный баян и большинство разработчиков давно знают правильный ответ на этот вопрос, в реальном коде встретить “некошерный” вариант очень даже просто.

Особенность платформы .NET заключается в том, что в ней не существует (а точнее, как мы вскоре увидим – не существовало) способа перехвата исключения в одном месте и последующего его генерирования в другом. Если разработчик бизнес-приложения или библиотеки сталкивался с такой задачей, то решалась она очень простым способом: исходное исключение заворачивалось в другой объект в виде вложенного исключения и пробрасывалось уже новое исключение.

Давайте рассмотрим такой пример. Предположим у нас есть кастомный класс исключения по имени CustomException, а также простой класс SampleClass, конструктор которого генерирует это самое исключение.

// Простое кастомное исключение, чтобы было, что перехватывать
class CustomException : Exception { }
 
class SampleClass
{     
    // Совершенно бесполезный класс,     
    // конструктор которого только и делает, что бросает исключение     
    public SampleClass() { throw new CustomException(); }
}

Теперь давайте создадим объект этого класса с помощью generic метода, а также сделаем синглтон этого класса:

// Простой фабричный метод, создающий экземпляр объекта
public static T CreateInstance<T>() where T : new()
{
     return new T();
}
 
// Простой класс синглтона
class SampleClassSingleton
{
     private static SampleClass _instance = new SampleClass();
     static SampleClassSingleton() { }
     public static SampleClass Instance { get { return _instance; } }
}

Вопрос в следующем, какой блок catch будет выполнен при вызове метода CreateInstance<SampleClass>() или при обращении к SampleClassSingleton.Instance?

try
{
     CreateInstance<SampleClass>();
     // или
      var instance = SampleClassSingleton.Instance;
}
catch (CustomException e)
{
     Console.WriteLine(e);
}
catch (Exception e)
{
     Console.WriteLine(e);
}

Не думаю, что для кого-то этот код будет большим откровением, но в обоих случаях “ожидаемый” блок catch(CustomException e) выполнен не будет, вместо этого будет выполнен блок catch(Exception e).

В первом случае (т.е. при использовании generic метода CreateInstance) на самом деле конструктор по умолчанию не вызывается напрямую, вместо этого используется Activator.CreateInstance, который оборачивает исходное исключение в TargetInvocationException. Именно поэтому срабатывает блок catch(Exception e), поскольку TargetInvocationException никак не подходит нашему первому блоку обработки исключений.

ПРЕДУПРЕЖДЕНИЕ
Не пишите в логи только e.Message, поскольку когда ляжет ваш продакш сервер от этой информации вам будет ни холодно ни жарко, поскольку наиболее ценная информация может таиться в одном из вложенных исключений. Даже в составе .Net Framework существует множество мест, которые оборачивают исходное исключение и пробрасывают его в качестве вложенного, ни говоря уже за кастомный код, который может обернуть нужное вам исключение в десяток вложенных.

При использовании синглтона, ситуация аналогична: поскольку инициализация поля _instance происходит в статическом конструкторе, то любые исключения, которые происходят во время его выполнения делают тип «невалидным». В результате, все последующие обращения к этому типу приводят к генерации исключения TypeLoadException с соответствующим вложенным исключением

ПРИМЕЧАНИЕ
Подробнее о том, для чего нужен пустой статический конструктор и к каким проблемам может привести его отсутствие см. О синглтонах и статических конструторах.

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

public static T CreateInstance<T>() where T : new()
{
     try
     {
         return new T();
     }
     catch (TargetInvocationException e)
     {
         // Исходный стек вызовов потерян, теперь все будут думать, что виноваты мы!
         throw e.InnerException;
     }
}

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

Однако в .Net Framewor 4.5 появился класс, способный помочь в решении этой проблемы. Это класс ExceptionDispatchInfo, способный сохранить исходное исключение и потом пробросить его заново не теряя информацию о стеке вызовов. Конечно, основной смысл его применения не связан с “выпрямлением” статических конструкторов или метода Activator.CreateInstance. Главная его задача заключается в решении вопросов асинхронности и многопоточности, когда исключение происходит в одном потоке, а пробрасывается в другом.

Давайте рассмотрим следующий код:

Task<int> task = Task<int>.Factory.StartNew(() => { throw new CustomException(); });
try
{
     int result = task.Result;
}
catch (CustomException e)
{
     // Неа, сюда нам с вами не попасть:(
     Console.WriteLine("CustomException caught: " + e);
}
catch (AggregateException e)
{
     // А вот и наше исходное исключение!
     var inner = e.GetBaseException();
     Console.WriteLine("Aggregate exception caught: " + inner);
}

Если “задача” падает с исключением, то исходное исключение (в нашем случае CustomException) будет завернуто в AggregateException. Причин такому поведению несколько: во-первых, хотя задача по своей природе представляет собой оболочку над некоторой длительной асинхронной операцией с единственным результатом, в некоторых случаях результат одной задачи может основываться на результатах параллельного выполнения нескольких задач. Например, мы можем объединить несколько задач в одну с помощью Task.WaitAll или мы можем связать несколько задач с помощью продолжений. Второй причиной такого поведения является невозможность проброса исходного исключения без искажения его стека вызовов.

Однако после появления в языке C# 5.0 новых возможностей по работе с асинхронностью, приоритеты несколько изменились. Одной из главных фич ключевых слов await и async является простота преобразования синхронного кода в асинхронный, но помимо «выпрямления» потока исполнения (который даже в случае применение задач оставляет желать лучшего), должна быть решена и задача обработки исключений. Поэтому при получении результатов задачи с помощью ключевого слова await, исходное AggregateException разворачивается и пробрасывается исходное исключение:

public static async void SimpleTask()
{
     Task<int> task = Task<int>.Factory.StartNew(() => { throw new CustomException(); });
     try
     {
         // await «разворачивает» исходное исключение сгенерированное внутри задачи
         // и пробрасывает именно его, а не AggregateException!
         int result = await task;
     }
     catch (CustomException e)
     {
         // Теперь вызывается этот обработчик, как и в случае синхронного вызова
         Console.WriteLine("CustomException caught: " + e);
     }
}

ПРИМЕЧАНИЕ
Если вы не знакомы такими фичами языка C# 5.0, как async и await, то восполнить этот пробел можно с помощью статьи: Асинхронные операции в C# 5

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

Для начала давайте для класса Task<T> создадим класс с методом расширения GetResult, который будет очень похож на свойство Result, но будет «выпрямлять» AggregateException и пробрасывать вложенное исключение без потери стека вызовов.

ПРИМЕЧАНИЕ
Такое поведение уже реализовано в составе .Net Framework 4.5 с помощью Task<T>.GetAwaiter().GetResult(), но давайте забудем об этом и сделаем тоже самое самостоятельно.

Пользоваться классом ExceptionDispatchInfo довольно просто: для этого достаточно захватить исключение в одном месте с помощью статического метода Capture, а затем пробросить это исключение в другом месте (и, возможно даже в другом потоке) с помощью метода Throw.

static class TaskExtensions
{
     public static T GetResult<T>(this Task<T> task)
     {
         try
         {
             T result = task.Result;
             return result;
         }
         catch (AggregateException e)
         {
             ExceptionDispatchInfo di = ExceptionDispatchInfo.Capture(e.InnerException);
             di.Throw();
             return default(T);
         }
     }
}

Теперь, если изменить предыдущий фрагмент кода и заменить task.Result на вызов метода Task.GetResult, то мы сможем перехватывать конкретный тип исключения вместо исключения AggregateException.

Task<int> task = Task<int>.Factory.StartNew(() => { throw new CustomException(); });
try
{
     int result = task.GetResult();
}
catch (CustomException e)
{
     // Теперь мы можем перехватывать CustomException, а не AggregateException
     Console.WriteLine("CustomException caught: " + e);
}

Аналогичным образом можно изменить наш метод CreateInstance, который будет перехватывать исключение TargetInvocationException и пробрасывать вложенное исключение:

public static T CreateInstance<T>() where T : new()
{
     try
     {
         var t = new T();
         return t;
     }
     catch (TargetInvocationException e)
     {
         // Захватываем вложенное исключение в ExceptionDispatchInfo
         ExceptionDispatchInfo di = ExceptionDispatchInfo.Capture(e.InnerException);
         // Пробрасываем это исключение с сохранением всей информации
         di.Throw();
         // Компилятор не знает, что di.Throws() всегда генерит исключение, поэтому
         // без этой строки кода мы получим ошибку компиляции, что метод не всегда
         // возвращает результат
         return default(T);
     }
}

Теперь, при попытке вызвать этот метод из функции Main мы получим вразумительное исключение с нормальным стеком исполнения:

ConsoleApplication1.CustomException: Exception of type 'ConsoleApplication1.CustomException' was thrown.
at ConsoleApplication1.SampleClass..ctor() in
c:\Projects\ConsoleApplication1\ConsoleApplication1\Program.cs:line 19
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at ConsoleApplication1.Program.CreateInstance[T]() in c
\Projects\ConsoleApplication1\ConsoleApplication1\Program.cs:
line 50
at ConsoleApplication1.Program.Main(String[] args) in c:\ \Projects\ConsoleApplication1\ConsoleApplication1\Program.cs:line 63

Класс синглтона можно реализовать подобным образом.

Класс ExceptionDispatchInfo едва ли будет киллер-фичей новой версии .Net Framework, однако с наступлением эры асинхронности у него точно найдется достойная область применения. Так, например, он уже используется в библиотеке реактивных расширений для реализации паттерна await (эта реализация доступна только в экспериментальном релизе) и может использоваться всеми, кто захочет реализовать этот паттерн самостоятельно.

Проблемы передачи списка перечислений или Почему абстракции «текут»

2011-10-26T23:54:00.001+03:00

Все нетривиальные абстракции дырявы
Джоэл Спольски – Закон дырявых абстракций

А иногда дырявятся и довольно простые абстракции
Автор этой статьи

Большинство современных разработчиков знакомы с «законом дырявых абстракций» по знаменитой заметке Джоэла Спольски с одноименным названием. Заключается этот закон в том, что как бы ни был хорош протокол взаимодействия, фреймворк или набор классов, моделирующих предметную область, рано или поздно нам приходится спускаться на уровень ниже и разбираться с тем, как же эта абстракция устроена. Внутреннее устройство абстракции должно быть проблемой самой абстракции, но возможно это только в наиболее общих случаев и лишь до тех пор, пока все идет хорошо (*).

Когда-то давно, в «небольшой» мелкомягкой компании решили, а почему бы нам не «абстрагироваться» от местоположения объекта и сделать сам факт того, является ли объект локальным или удаленным, лишь «деталью реализации». Так появились технологии DCOM и ее наследник .NET Remoting, которые скрывали от разработчика, является ли объект удаленным или нет. При этом появились все эти «прозрачные прокси», которые позволяли работать с удаленным объектом, даже не зная об этом. Однако, со временем выяснилось, что эта информация архиважна для разработчика, поскольку удаленный объект может генерировать совершенно другой перечень исключений, да и стоимость работы с ним несравнимо выше, чем взаимодействие с локальным объектом.

Конечно, такое «сокрытие информации» бывает полезным, однако в общем случае это приводит скорее к усложнению жизни разработчика, а не к ее упрощению. Именно поэтому новая версия технологии для разработки распределенных приложений под названием WCF от такой практики ушла и, хотя грань между локальным и удаленным объектом осталась очень тонкой, но она все же, осталась.

Подобных примеров, когда нам нужно знать не только видимое поведение (абстракцию), но и понимать внутреннее устройство (реализацию), довольно много. В большинстве языков программирования работа с разными типами коллекций делается очень похожим образом. Коллекции могут «прятаться» за базовыми классами или интерфейсами (как в .NET), или использовать какой-то другой способ обощения (как, например, в языке С++). Но, несмотря на то, что мы можем работать с разными коллекции практически одинаково, мы не можем полностью «отвязать» наши классы от конкретных типов коллекций. Несмотря на видимое сходство, нам нужно понимать, что лучше использовать в данный момент: вектор или двусвязный список, hash-set или sorted set. От внутренней реализации коллекции зависят сложности основных операций: поиска элемента, вставки в середину или в конец коллекции и знать о таких различиях просто необходимо.

Давайте рассмотрим конкретный пример. Все мы знаем, что такие типы как List<T> (или std::vector в С++) реализованы на основе простого массива. Если коллекция уже заполнена, то при добавлении нового элемента будет создан новый внутренний массив, при этом он «вырастит» не на один элемент, а несколько сильнее (**). Многие знают о таком поведении, но в большинстве случаев мы можем не обращать на это никакого внимания: это является «личной проблемой» класса List<T> и нам до нет никакого дела.

Но давайте предположим, что нам нужно передать список перечислений (enum-ов) через WCF или просто сериализовать такой список с помощью классов DataContractSerializer или NetDataContractSerializer(***). При этом перечисление объявлено следующим образом:

public enum Color
{
    Green = 1,
    Red,
    Blue
}

Не обращайте внимания на то, что это перечисление не помечено никакими атрибутами, это не является помехой для NeDataContractSerializer-а. Главная особенность этого перечисления заключается в том, что в нем нет нулевого значения; значения перечислений начинаются с 1.

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

public static string Serialize<T>(T obj)
{
    // Используем именно NetDataContractSerializer, хотя в данном случае
    // поведение DataContractSerializer аналогичным
    var serializer = new NetDataContractSerializer();
    var sb = new StringBuilder();
    using (var writer = XmlWriter.Create(sb))
    {
        serializer.WriteObject(writer, obj);
        writer.Flush();
        return sb.ToString();
    }
}

Color color = (Color) 55;
Serialize(color);

При попытке выполнить этот код, мы получим следующее сообщение об ошибке: Enum value '55' is invalid for type Color' and cannot be serialized.. Такое поведение является вполне логичным, ведь таким способом мы защищаемся от передачи неизвестных значений между разными приложениями.

Теперь давайте попробуем передать коллекцию из одного элемента:

var colors = new List<Color> {Color.Green};
var s = Serialize(colors);

Однако этот, с виду вполне безобидный код, также приводит к ошибке времени выполнения с тем же самым содержанием и отличие заключается лишь в том, что сериализатор не может справиться со значением перечисления, равным 0. На что за … Откуда мог вообще взялся 0? Мы ведь пытаемся передать простую коллекцию с одним элементом, при этом значение этого элемента абсолютно корректно. Однако DataContractSerializer/NetDataContractSerializer, как и старая добрая бинарная сериализация, использует рефлексию для получения доступа ко всем полям. В результате чего, все внутреннее представление объекта, которое содержится как в открытых, так и закрытых полях, будет сериализовано в выходной поток.

Поскольку класс List<T> построен на основе массива, то при сериализации будет сериализован массив целиком, не зависимо от того, сколько элементов содержится в списке. Так, например, при сериализации коллекции из двух элементов:

var list = new List<int> {1, 2};
string s = Serialize(list);

В выходном потоке мы получим не два элемента, как мы могли бы ожидать, а 4 (т.е. количество элементов, соответствующих свойству Capacity, а не Count):

<ArrayOfint>
	<_items z:Id="2" z:Size="4">
		<int>1</int>
		<int>2</int>
		<int>0</int>
		<int>0</int>
	</_items>
	<_size>2</_size>
	<_version>2</_version>
</ArrayOfint>

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

Это еще один пример «протекания» абстракции, когда внутренняя реализация даже такого простого класса, как List<T> может помешать нам его нормально сериализовать.

Решение проблемы

Решений у этой проблемы несколько, при этом каждое из решений обладает своими недостатками.

1. Добавление значения по умолчанию

Самым простым решением этой проблемы является добавление в перечисление значения, равного 0 либо изменить значение одного из существующих элементов:

public enum Color
{
    None = 0,
    Green = 1, // или Green = 0
    Red,
    Blue
}

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

2. Передача коллекции без «пустых» элементов

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

var li1 = new List<Color> { Color.Green }; // Содержит еще 3 элемента, равных 0
var li2 = new List<Color>(li1);

В этом случае, переменная li1 будет содержать три дополнительных пустых элемента (при этом Count будет равен 1, а Capacity – 4), а переменная li2 – нет (внутренний массив второго списка будет содержать только 1 элемент).

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

3. Использование других типов коллекций в интерфейсе сервисов

Использование других структур данных, таких как массив, либо вместо DataContractSerializer-а использовать XML-сериализацию, которая использует только открытые члены, решит эту проблему. Но насколько это удобно или нет, решать уже вам.

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

З.Ы. Кстати, дважды подумайте, чтобы передавать значимые типы через WCF в типе List<T>. Если у вас будет коллекция из 524-х элементов, то будут переданы еще 500 дополнительных объектов значимого типа!

---------------------

(*) Джоэл далеко не первый и не последний автор, предложивший отличную метафору для этих целей. Так, например, Ли Кэмпбел однажды отлично сказал об этом же, но несколько другими словами: «Вы должны понимать как минимум на один уровень абстракции ниже того уровня, на котором кодируете». Подробности в небольшой заметке: О понимании нужного уровня абстракции.

(**) Обычно подобные структуры данных увеличивают свой внутренний массив в два раза. Так, например, при добавлении элементов в List<T>, «емкость» будет изменяться таким образом: 0, 4, 8, 16, 32, 64, 128, 256, 512, 1024 …

(***) Разница между двумя основными типами сериализаторов WCF достаточно важна. NetDataContractSerializer в отличие от DataContractSerializer, нарушает принципы SOA и добавляет информацию о CLR типе в выходной поток, что нарушает «кроссплатформенность» сервис-ориентированной парадигмы. Подробнее об этом можно почитать в заметках: Что такое WCF или Декларативное использование NetDataContractSerializer.

Доклады по асинхронному и реактивному программированию

2011-10-12T22:22:00.001+03:00

На следующей неделе я проведу два семинара (или доклада, если хотите) в Киеве.

20.10.11 Библиотека реактивных расширений. Киев, Радищева 10/14, начало в 17-00 (это четверг)
21.10.11 Асинхронное программирование в .NET. Kiev ALT.NET, Киев, Амосова 12, 19-й этаж, начало в 18-15 (а это – пятница)

Реактивные расширения

Первый из них пройдет в следующий четверг и будет посвящен реактивному программированию, а если быть более точным, то библиотеке реактивных расширений (a.k.a. Rx – Reactive Extensions). Вход свободный, чтобы попасть на семинар достаточно зарегистрироваться.

План семинара примерно такой (его, если честно, еще добить нужно):

Двойственность интерфейсов IEnumerable и IObservable
Обработка событий пользовательского интерфейса
Реактивные расширения и асинхронные операции

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

Асинхронное программирование

Второй доклад будет проходить в пятницу в рамках Kiev ALT.NET и будет посвящен асинхронному программированию. По сути, это будет мое четвертое выступление с этой темой (*), так что семинар уже откатан до блеска.

План семинара

Синхронные и асинхронные операции
Класс AsyncEnumerator из PowerThreading
Основы TPL
C# 5: async и await

Поскольку времени будет меньше, чем на предыдущих семинарах, то долго обсуждать паттерны асинхронного программирования в .NET и проблемы синхронного кода мы не будем, а кинемся сразу в бой: на AsyncEnumerator, TPL и новые фишки пятого C#.

Хотя у каждого семинара есть определенная тема я стараюсь (и более того, всячески поощряю) разные отступления, чтобы даже в рамках семинара/доклада обсудить разные интересности. Так, в прошлые разы мы обсуждали самые разные вопросы, начиная от вопросов дизайна языка C# и вопросов “утиной типизации”, встроенной в язык C#, заканчивая способами завершения работы потока и недостатками вызова метода Thread.Abort. Общение получается живым и интересным, и дает пищу для размышлений всем ее участникам.

В общем, приходите, будет интересно!

---------------------------------

(*) О первом своем опыте я уже писал, первый блин, вроде как, комом не вышел; да и последующие семинары показали, что материал подобран правильно.

Dispose pattern

2011-09-27T21:03:00.001+03:00

“Не стоит следовать некоторой идиоме только потому, что так делают все или так где-то написано”
Мысли автора статьи во время чтения и рефакторинга чужого кода

Ни для кого не будет секретом, что платформа .NET поддерживает автоматическое управление памятью. Это значит, что если вы создадите объект с помощью ключевого слова new, то вам не нужно будет самостоятельно заботиться о его освобождении. Сборщик мусора определит «достижимость» объекта, и если на объект не осталось корневых ссылок, то он будет освобожден. Однако, как только речь заходит о ресурсах, таких как сокет, буфер неуправляемой памяти, дескриптор операционной системы и т.д., то сборщик мусора, по большому счету, умывает руки и весь головняк по работе с такими ресурсами ложится на плечи разработчика.

А как же финализаторы? – спросите вы. Ну, да, есть такое дело, финализаторы действительно предназначены для освобождения ресурсов, но проблема в том, что время их вызова не детерминировано, а это значит, что никто не знает, когда они будут вызваны и будут ли вызваны вообще. Да и порядок вызова финализаторов не определен, поэтому при вызове финализатора некоторые «части» вашего объекта уже могут быть «разрушены», поскольку их финализаторы уже были вызваны. В общем, финализаторы – они-то есть, но это скорее «страховочный трос», а не нормальное средство управления ресурсами.

Идиома RAII

В языке С++, в котором нет никаких встроенных средств для автоматического управления памятью помимо умных указателей, уже давно активно применяется паттерн (или идиома) для своевременного освобождения ресурсов (*). Эта идиома носит название «Захват ресурса есть инициализация» (RAII - Resource Acquisition Is Initialization) и заключается в следующем. Ресурс захватывается в конструкторе и освобождается в деструкторе, а поскольку деструкторы вызываются автоматически, то и дополнительных усилий по управлению ресурсами больше не требуется.

Не удивительно, что эта же идея детерминированного управления ресурсами перекачивала и в другие более «умные» и «управляемые» среды, такие как .NET или Java (**) в виде интерфейса IDisposable (в языке C#) и метода dispose (в Java). Но, поскольку эти среды более умные, по сравнению со старичком С++, и основные проблемы, связанные с управлением памятью, в них решены, то переехала эта идиома не слишком хорошо. Нет, поймите меня правильно, переехала она вполне успешно, но для этого вам нужно использовать блок using (для языка C#) или try-with-resources statement (в Java 7), если же вы «забудете» ими воспользоваться, то от вашего детерминированного освобождения ресурсов не останется и следа.

// Открываем файл внутри блока using
using (FileStream file = File.OpenRead("foo.txt"))
{
    // Выходим из функции при выполнении некоторого условия
    if (someCondition) return;
    // Файл будет закрыт автоматически при выходе из блока using
}
// А что, если кто-то откроет файла вне блока using?
FileStream file2 = File.OpenRead("foo.txt");

Однако это не единственная сложность, которая возникает при работе с ресурсами в .NET. Как мы вскоре увидим, использование обычного метода для освобождения ресурсов обладает и некоторыми другими проблемами. Поскольку метод Dispose освобождает ресурсы, то вызов финализатора уже не нужен и его нужно отменить, кроме того, метод Dispose разрушает инвариант класса, что дает пользователю возможность получить разрушенный или частично разрушенный объект. А это требует дополнительных проверок как в методе Dispose, так и во всех публичных методах класса.

Все это привело к тому, что относительно простая идиома RAII вылилась на платформе .NET в паттерн, который так и называется “Dispose паттерн”. Однако прежде чем переходить к его рассмотрению, давайте рассмотрим два типа ресурсов, существующие на платформе .NET: управляемые и неуправляемые ресурсы.

Управляемые и неуправляемые ресурсы

В .NET существует два типа ресурсов: управляемые и неуправляемые. Причем отличить их довольно просто: к неуправляемым ресурсам относятся только «сырые» ресурсы, типа IntPtr, сырые дескрипторы сокетов или что-то в этом духе; если же с помощью идиомы RAII этот ресурс упаковали в объект, захватывающий его в конструкторе и освобождающий в методе Dispose, то такой ресурс уже является управляемым. По сути, управляемые ресурсы – это «умные оболочки» для неуправляемых ресурсов, для освобождения которых не нужно вызывать какие-то хитроумные функции, а достаточно вызвать метод Dispose интерфейса IDisposable.

class NativeResourceWrapper : IDisposable
{
    // IntPtr – неуправляемый ресурс
    private IntPtr nativeResourceHandle;
    public NativeResourceWrapper()
    {
        // «Захватываем» неуправляемый ресурс путем вызова специальной функции
        nativeResourceHandle = AcquireNativeResource();
    }
    public void Dispose()
    {
        // Освобождаем захваченный ресурс, опять же, путем вызова какой-то специальной
        // функции
        ReleaseNativeResource(nativeResourceHandle);
    }
    // Есть еще и финализатор, но его роль будет раскрыта позднее
    ~NativeResourceWrapper() {...}

}

Таким образом, любой объект может владеть ресурсами двух типов: он может непосредственно содержать неуправляемый ресурс (например, IntPtr) или же он может содержать ссылку на управляемый ресурс (например, NativeResourceWrapper), при этом в обоих случаях объект, содержащий один из этих ресурсов, сам становится управляемым ресурсом. Это может показаться не слишком принципиальным, но понимать разницу между двумя типами ресурсов очень важно, поскольку работать с ними приходится по-разному.

Dispose pattern

Итак, мы знаем, что объект может владеть двумя типами ресурсов: управляемыми и неуправляемыми; а также то, что у нас есть два способа освобождения ресурсов: детерминированный, с помощью метода Dispose и недетерминированный, с помощью финализатора (***). А теперь давайте посмотрим, как со всем этим добром жить и, главное, как это добро освобождать.

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

1. Класс, содержащий управляемые или неуправляемые ресурсы реализует интерфейс IDisposable

class Boo : IDisposable {}

2. Класс содержит метод Dispose(bool disposing), который и делает всю работу по освобождению ресурсов; параметр disposing говорит о том, вызывается ли этот метод из метода Dispose или из финализатора. Этот метод должен быть protected virtual для не-sealed классов и private для sealed классов

// Для не-sealed классов
protected virtual void Dispose(bool disposing) {} 
// Для sealed классов
private void Dispose(bool disposing) {}

3. Метод Dispose всегда реализуется следующим образом: вначале вызывается метод Dispose(true), а затем может следовать вызов метода GC.SuppressFinalize(), который предотвращает вызов финализатора.

public void Dispose()
{
    Dispose(true /*called by user directly*/);
    GC.SuppressFinalize(this);
}

Метод GC.SuppressFinalize(), во-первых, должен вызываться после вызова Dispose(true), а не перед ним, поскольку если метод Dispose(true) «упадет» с исключением, то выполнение финализатора не отменится. Во-вторых, GC.SuppressFinalize() должен вызываться даже для классов, не содержащих финализаторы, поскольку финализатор может появиться у его наследника (т.е. мы должны вызывать метод GC.SuppressFinalize() во всех не-sealed классах).

4. Метод Dispose(bool disposing) содержит две части: (1) если этот метод вызван из метода Dispose (т.е. параметр disposing равен true), то мы освобождаем управляемые и неуправляемые ресурсы и (2) если метод вызван из финализатора во время сборки мусора (параметр disposing равен false), то мы освобождаем только неуправляемые ресурсы.

void Dispose(bool disposing)
{
    if (disposing)
    {
        // Освобождаем только управляемые ресурсы
    }

    // Освобождаем неуправляемые ресурсы
}

5. (ОПЦИОНАЛЬНО) Класс может содержать финализатор и вызывать из него Dispose(bool disposing) передавая false в качестве параметра.

~Boo()
{
    Dispose(false /*not called by user directly*/);
}

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

6. (ОПЦИОНАЛЬНО) Класс может содержать поле bool _disposed, которое говорит о том, что ресурсы объекта уже освобождены. Disposable-классы должны спокойно позволять повторный вызов метода Dispose, а также генерировать исключение при доступе к любым другим публичным методам или свойствам (поскольку инвариант объекта уже разрушен).

void Dispose(bool disposing)
{
    if (disposed)
        return; // Ресурсы уже освобождены
    // Освобождаем ресурсы
    disposed = true;
}
 
public void SomeMethod()
{
    if (disposed)
        throw new ObjectDisposedException();
}

7. (ОПЦИОНАЛЬНО) Класс может наследовать от CriticalFinalizerObject, если предыдущих шести пунктов мало и вы хотите большей экзотики. Наследование от этого класса дает вам дополнительные гарантии:

Финализатор таких классов компилируется JIT-компилятором сразу при конструировании экземпляра, а не отложено по мере необходимости. Это дает возможность успешно выполниться финализатору даже в случае острой нехватки памяти.
Как мы уже говорили, CLR не гарантирует порядок вызова финализаторов, что делает невозможным обращение внутри финализатора к другим объектам, содержащим неуправляемые ресурсы. Однако CLR гарантирует что финализаторы «простых смертных» объектов будут вызваны до наследников CriticalFinalizerObject. Это дает возможность, в частности, из финализаторов ваших классов (если они не наследуют от CriticalFinalizerObject) обращаться к полю SafeHandle, которое точно будет освобождено позднее.
Финализаторы таких классов будут вызваны даже в случае экстренной выгрузки домена приложения.

// А вы уверены, что оно вам нужно?
class Foo : CriticalFinalizerObject { }

Прагматичный взгляд на Dispose паттерн

Если вам показалось, что работа с ресурсами в .NET неоправдано сложна, то у меня по этому поводу есть две новости: одна хорошая, а другая – не очень. Новость «не очень» заключается в том, что работа с ресурсами даже сложнее, чем здесь описано (*****), хорошая же заключается в том, что в большинстве случаев вся эта сложность нас с вами касаться практически не будет.

Вся сложности реализации Dispose паттерна связаны с предположением о том, что один и тот же класс (или иерархия классов) может одновременно содержать как управляемые, так и неуправляемые ресурсы. Но давайте подумаем, а зачем вообще нам может понадобиться хранить неуправляемые ресурсы напрямую в классах бизнес-логики? А как же пресловутые Принципы Единой Ответственности (SRP – Single Responsibility Principle) и Здравого Смысла? Идиома RAII, описанная ранее, успешно используется десятки лет и предназначена как раз для таких случаев: если у вас есть неуправляемый ресурс, то вместо того, чтобы работать с ним напрямую, оберните его в управляемую оболочку и работайте уже с нею.

Если посмотреть на .NET Framework, то можно заметить, что там используется именно такой подход: для всех ресурсов создается оболочка, которая прячет внутри всю сложность по работе с ресурсами, предоставляя пользователю лишь вызвать метод Dispose для явной очистки ресурсов (ну, и финализатор, на всякий случай). Кроме того, для большей части неуправляемых ресурсов операционной системы такие оболочки уже сделаны, и изобретать велосипед не нужно.

Все это я веду к тому, что не нужно смешивать в вашем коде бизнес-логику и логику по работе с неуправляемыми ресурсами. И то, и другое достаточно сложно само по себе и заслуживает отдельного класса. Вот и получается, что данный паттерн «оптимизирован» на очень редкий случай (что класс может содержать и управляемые и неуправляемые ресурсы), при этом делая наиболее распространенный случай, когда класс содержит только управляемые ресурсы, очень неудобной в реализации и сопровождении.

Упрощенная версия Dispose паттерна

Если мы с вами знаем, что ни один человек не собирается смешивать управляемые и неуправляемые ресурсы в одном месте, так почему бы не реализовать это в коде явным образом? Мы можем оставить метод Dispose и вместо дополнительного метода Dispose с совсем невнятным булевым параметром, добавить виртуальный метод DisposeManagedResources, имя которого будет четко говорить о том, что мы должны освободить именно управляемые ресурсы. Модификатор доступа этого метода должен быть аналогичным нашему методу Dispose(bool), т.е. protected virtual для не-sealed классов или private для sealed классов.

class SomethingWithManagedResources : IDisposable
{
    public void Dispose()
    {
        // Никаких Dispose(true) и никаких вызовов GC.SuppressFinalize()
        DisposeManagedResources();
    }
    
    // Никаких параметров, этот метод должен освобождать только неуправляемые ресурсы
    protected virtual void DisposeManagedResources() {}
}

С первого взгляда такой подход может показаться слишком уж прагматичным, однако посудите сами: в книге Framework Design Guidelines описанию Dispose паттерна посвящено два десятка страниц, при этом ее авторы рекомендуют добавлять финализаторы только в случае острой необходимости. При этом все мы знаем, что смешивать два типа ресурсов в одном классе плохо, но все же следуем паттерну, который это поощряет, а не запрещает.

Заключение

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

Если же вы проектируете классы бизнес-логики или простые библиотеки с ограниченным кругом пользователей, то можно не морочить себе голову с «канонами», а использовать упрощенную версию этого паттерна, которая работает только с управляемыми ресурсами.

------------------------------

(*) В С++, в отличие от C#, память тоже является ресурсом. Поэтому идиома RAII в языке С++ применяется как для освобождения динамически выделенной памяти, так и для освобождения любых других ресурсов, типа дескрипторов ОС или сокетов.

(**) В Java 7 наконец-то появилась конструкция, аналогичная конструкции using языка C#: try-with-resource statement

(***) К сожалению в языке C# для финализаторов выбран тот же самый синтаксис (тильда, за которой идет имя класса), который используется для деструкторов в языке С++. Но семантика деструктора и финализатора очень разная, поскольку деструктор подразумевает детерминированное освобождение ресурсов, а финализатор – нет.

(***) Да, это еще одно отличие в поведении .NET и языка С++. В последнем, деструктор вызывается только для полностью сконструированного объекта, при этом вызываются деструкторы для всех полностью сконструированных его полей.

(****) Здесь я, например, не говорил о том, как можно получить «утечку ресурсов» при появлении исключений или о проблемах с изменяемыми значимыми типами, реализующими интерфейс IDisposable. Об этом я уже писал ранее в заметках «Гарантии безопасности исключений» и «О вреде изменяемых значимых типов» соответственно.

Google+

2011-09-19T21:53:00.001+03:00

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

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

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

Посему такую “нестатейную” нишу я заполняю с помощью гуглоплюса и живой ленты (твиттер как-то мне не удобен для этих целей, хотя им я тоже иногда пользуюсь). Посему, если ты, дорогой мой читатель, интересуешься не только моими статьями, но и не столь полноценно оформленными мыслями, то милости прошу в упомянутые выше гуглоплюс или живую ленту.

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

P.S. Ну, а кто на гуглоплюсе еще не зарегистрирован и нужен инвайт (там, кажется, он все еще нужен) – пишите, вышлю.

Принцип самурая

2011-09-13T22:50:00.001+03:00

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

Еще одной метафорой, или скорее принципом разработки, является «принцип самурая», призванный описать «контракт» между функцией и вызывающим ее кодом и заключается в следующем. Любая функция, реализующая некоторую единицу работы должна следовать тому же кодексу чести «бусидо», по которому живет любой самурай. Так, самурай не будет выполнять никаких заданий, противоречащих его «кодексу чести» и если к нему подойти с «непристойным» предложением, то он снесет вам башку раньше, чем вы успеете глазом моргнуть. Но если уж самурай возьмется за дело, то можно быть уверенным в том, что он доведет его до конца (**).

Тем же принципам должна следовать и любая открытая функция. Если ей «подсунули» неадекватные входные данные, нарушающие ее предусловие (то есть ее кодекс чести), то она должна четко сказать об этом с помощью исключения (это аналог сноса башки, ведь вы сами в этом виноваты). Но если уж аргументы валидны и она вызывается в корректном состоянии, то вызывающий код может быть уверенным в результате: функция либо завершится успешно, либо «упадет». Функция, как и самурай должны следовать принципу «сделай или умри», но если самурай, чтобы избежать позора, делает себе сэппуку, то функция, если она не в состоянии выполнить свою работу, должна «упасть» с исключением.

Этот, казалось бы, нехитрый принцип дает ответы на многие непростые вопросы обработки исключений. Нужно ли проверять аргументы функции и что делать, если они некорректны? Нужно ли глотать исключения, которые происходят во внутренностях этой функции? Нужно ли возвращать null или пустой список, если что-то пошло не так и функция не может выполнить свою работу? (***)

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

Из этого принципа следует, что «глотать» исключения – это плохо, поскольку вы, фактически, скрываете свои проблемы от глаз вызывающего кода и не даете внешнему коду возможности узнать об этом. Не нужно брать на себя слишком многого, пусть голова болит у вашего «клиента», что делать с «вашим телом» (то есть с исключением), когда вы не справились со своей задачей и решили последовать принципам самурая.

Возвращение null object-а в случае возникновения исключений также является опасной практикой, поскольку вызывающий код просто не сможет определить, является ли пустой объект корректным значением, или же при его получении произошла ошибка:

public SomeEntry ReadEntryById(int id)
{
    try
    {
        // Читаем SomeEntry из базы данных
    }
    catch (Exception)
    {
        // Ядрёна кочарыжка! Как же вызывающему коду узнать,
        // была ли ошибка, или записи с таким id нет в базе?
        return null;
    }
}

Бывают случаи, когда функция может перехватывать исключение и не пробрасывать его вызывающему коду; это может быть функция самого высокого уровня и вызывающего кода может не быть. В остальных же случаях, функция может самостоятельно попытаться восстановиться после возникновения ошибки, но, в конечном счете, если эта попытка не увенчается успехом, то у нее не останется другого выхода, кроме как последовать принципу самурая – «сделать свою работу или умереть».

--------------

(*) За подробностями о том, что это за метафоры, обращайтесь к соответствующим заметкам: «Технический долг» и «Эффект второй системы», соответственно.

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

(***) Принцип самурая не является революцией в разработке ПО; этому принципы следуют уже давно, причем некоторые делают это достаточно формальным образом с помощью проектирования по контракту. Если вы хотите познакомиться с понятиями предусловия и постусловия, то можно начать со статьи «Как не надо писать код», или же обратиться к целой серии статей, посвященных теме проектирования по контракту.

Вы, конечно, шутите, мистер Фейнман

2011-09-05T21:35:00.001+03:00

Мое знакомство с мистером Фейнманом началось с перевода статьи Эрика Липперта «Что бы сделал мистер Фейнман». В этой замечательной заметке в виде шуточного рассказа приведены ответы на «нестандартные вопросы», так любимые некоторыми «мелкомягкими» компаниями при отборе кандидатов на работу. А поскольку мистер Фейнман всегда любил «нестандартные вопросы» и давал на них еще менее «стандартные ответы», то интервью получилось веселым и, как я узнал позднее, очень похожим на неопубликованную главу из книги «Вы, конечно, шутите, мистер Фейнман».

Сама же книга представляет собой сборник забавных и трогательных историй о жизни «простого» человека, по имени Ричард Филлипс Фейнман, самым незначительным достижением которого (по его собственному разумению) было получение Нобелевской премии по физике. Это книга о замечательном человеке, умном, талантливом, упрямом; человеке, у которого жажда познаний, экспериментов и решения разных головоломок была практически безграничной.

Цитата: Мне интересно, почему. Мне интересно, почему. Мне интересно, почему мне интересно. Мне интересно, почему мне интересно, почему Мне интересно, почему мне интересно?

Будучи еще двенадцатилетним ребенком, этот парень смастерил в своей «лаборатории» простенькую охранную сигнализацию, он сделал щиток управления для собственного стенда, на котором была лампочка, которая загоралась, в случае неисправностей; он чинил радиоприемники всей округе «думая». Понятно, что в тридцатых годах прошлого века радиоприемники были весьма простыми устройствами, но, тем не менее, сколько ребят в этом возрасте могут сделать свой собственный предохранитель или сделать вольтметр из амперметра?

Цитата: Я плохо представляю, что происходит с людьми: они не учатся путем понимания. Они учатся каким-то другим способом – путем механического запоминания или как-то иначе. Их знания так хрупки!

В этой книге нет четкого сюжета, нет особой темы и идеи, как нет их и в нашей жизни. Мы живем, растем, учимся, любим, увлекаемся чем-то; и эта книга, будучи автобиографической, построена подобным образом. Но есть одна тема, к которой Фейнман возвращается снова и снова: это темы образования, познания, науки. Он постоянно пишет о том, что люди должны учиться путем понимания, а не механического запоминания, и что учебники должны этому способствовать. Поскольку наука направлена на понимание законов природы, то в учебниках должны быть примеры, связывающие научные законы с окружающим миром, чтобы школьник или студент не просто «зазубрил» определение, а понял, что за ним стоит, и смог бы потом проверить это самостоятельно на практике. Будучи еще учеником старших классов, Ричард придумывал интересные задачи по геометрии, поскольку искренне считал, что примеры в существующих учебниках являются унылыми. Все это, в конечном счете, привело к появлению знаменитых «Фейнмановских лекций по физике», которые вот уже более 50 лет считаются одним из лучших курсов по физике.

Цитата: Однажды я начал возиться с вычислительной машинкой и заметил нечто очень своеобразное. Если взять единичку и разделить на 243, то получится 0,004115226337448… Любопытно… Я решил, что это довольно забавно.

Пару лет назад, задолго до прочтения этой книги, я листал замечательную книгу Джона Бентли «Жемчужины программирования» (**). Тогда мое внимание привлекла седьмая глава под названием «Предварительные оценки», в которой автор предлагает проверить свою «интуицию» на некоторых вопросах, а затем показывает пользу «предварительных оценок» для разработчика. После этого, практически в самом конце главы приводится следующая цитата:

"Мне частенько приходилось слышать, что предварительные оценки называли "приближенными оценками Ферми" по имени знаменитого физика. История гласит, что Энрико Ферми, Роберт Оппенгеймер и другие члены Манхэттенского проекта ждали взрыва первой атомной бомбы за низкой стеной в нескольких километрах от эпицентра. Ферми нарвал множество маленьких листочков бумаги, которые он подбросил в воздух, увидев вспышку взрыва. Когда ударная волна миновала их, он измерил расстояние, на которое были отброшены бумажки, и быстро рассчитал мощность взрыва атомной бомбы, которая была позже точно подтверждена дорогостоящим измерительным оборудованием".

Я благополучно забыл, чьим именем называли предварительные оценки, да и вообще я долгое время не мог вспомнить, где я о них прочитал. Читая книгу о «мистере Фейнмане» у меня было постоянное ощущение дежавю, настолько часто и умело Фейнман пользовался своим умением сказать, «как приблизительно будет выглядеть ответ, или, когда ответ получен, - объяснить, почему он именно таков». Да, в указанной выше цитате главным героем не мог быть Фейнман, поскольку он в это время смотрел на ядерный взрыв через ветровое стекло грузовика, ведь он знал, что глаза могут пострадать не от яркой вспышки, а именно от ультрафиолета, который благополучно будет поглощен этим стеклом (***).

Цитата: - А где ты его взял?
                         - У тебя в шкафу.
                         - Но я запер его!
                         - Знаю, что ты его запер. Но замки – барахло!

Эту книгу интересно читать не только потому, что она легко написана, в ней много юмора и интересных историй. Ее интересно читать еще и потому, что из нее можно почерпнуть немало интересного для себя. В книге показан отличный пример того, что зацикливаться на чем-то одном в своей жизни совершенно не обязательно. Помимо того, что «мистер Фейнман» был прекрасным физиком, он профессионально рисовал и играл на барабанах и фригидейре; он изучал португальский и японский; он взламывал сейфы и изучал письмена Майа, оспаривая мнение мировых экспертов в этой области; а его экспериментам с муравьями позавидовал бы Бернард Вербер (****). Одним словом, Ричард Фейнман является отличным примером того, что человек может быть талантливым в самых разных областях. А нужно для этого, всего ничего: страстное желание и «немного» усердия.

------------------------------

(*) Конечно же, вся эта статья является чистейшей воды выдумкой, но вот атмосфера и стиль повествования очень похожи. Не зря, эта заметка Эрика, несмотря на свой нетехнический характер и отсутствие малейшей информации о языке C# и компиляторах, оказалась такой популярной.

(**) Рецензия на книгу Джона Бентли в моем списке рецензий отсутствует, но небольшое мнение о ней можно узнать в статье «Классические книги по программированию».

(***) Если честно, то я сомневаюсь в правдивости цитаты, приведенной Джоном Бентли по одной простой причине: если бы это было действительно так, то Фейнман, также будучи участником Манхэттенского проекта, об этом наверняка бы знал, и обязательно бы упомянул в своих «записках». Но с чем действительно не поспоришь, так это с тем, что Ферми был величайшим мастером предварительным оценок, и даже превосходил в своем мастерстве Фейнмана, о чем последний неоднократно упоминает.

(****) Речь идет о популярном современном писателе, авторе знаменитого трехтомника «Муравьи».

Wanted! Старые хиты Эрика Липперта

2011-08-29T23:05:00.001+03:00

Если вы, вдруг не знали, то помимо всякой ерунды, публикуемой на этом блоге, я еще и занимаюсь переводом блога Эрика Липперта (Eric Lippert) Fabulous Adventures in Coding на русский язык. В русскоязычном варианте этот блог носит название Невероятные приключения в коде.

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

Но сегодня я не об этом. Точнее не совсем об этом. Мы начали публиковать переводы, датированные апрелем 2009-го года, но, как это ни удивительно, до этого Эрик писал не менее часто и не менее интересно. Посему я предлагаю вернуться к его старым хитам и восстановить, так сказать, справедливость и перевести на русский язык и их.

Я сделал небольшой список того, что я думаю перевести, но, вполне возможно, что я что-то упустил (а я точно что-то упустил), поэтому я всецело открыт для предложений (*). Итак, вот сам список:

The Stack Is An Implementation Detail, Part One (2009-04-27)
The Stack Is An Implementation Detail, Part Two (2009-04-05)
Пара весьма интересных и популярных статей, в которых рассматривается разница между значимыми и ссылочными типами с точки зрения расположениях их экземпляров в памяти. Эта тема рассматривается, наверное, в сотне различных статей, да и сам Эрик пишет об этом весьма часто. Тем не менее, это одна из лучших заметок в этой теме.
Events and Races (2009-04-29)
Одним из классических вопросов правильного “зажигания” событий является вопрос многопоточности. В этой заметке речь идет именно об этом.
Representation and Identity (2009-03-19)
Отличная заметка о том, почему при распаковке упакованного байта в int мы получаем исключение InvalidCastException.
Locks and exceptions do not mix (2009-03-06)
В статье рассматриваются изменения, внесенные в реализацию метода Monitor.Enter в .Net 4.0 для предотвращения возможных deadlock-ов, которые были вполне возможны в более ранних версиях .Net Framework.
References are not addresses (2009-02-17)
Рассматривается разница между ссылками и указателями в языке C#, ну и, как говорит название, Эрик показывает, почему ссылки некорректно рассматривать, как адрес в памяти.
Why no var on fields? (2009-01-26)
И правда, почему? На часть этих вопросов я уже ответил совсем недавно в своей заметке, ну а все сложности реализации компилятора лучше почитать у Эрика:)
Vexing exceptions (2008-09-10)
Очень полезная статья, в которой рассматриваются три «семантических» типа исключений. Все это помогает устаканить в голове некоторые вопросы обработки исключений и таки понять, как их обрабатывать.
High maintenance (2008-09-08)
Отличное ревью всего лишь одной функции, в 6-ти строках которой показаны 5 разных code smells. Много интересных мыслей, начиная от контракта функции заканчивая проблемами предварительного обобщения (premature generialization).
Reading Code Over the Telephone (2008-05-16)
Не rocket science, но, тем не менее, очень полезно знать, как читаются различные лямбда-выражение.
Subtleties of C# IL codegen (2007-08-17)
Интересная заметка, в которой показывается почему, например, lock(expression) statement не является потокобезопасными в случае возникновения асинхронных исключений, а также рассмотрена разница между инструкциями call и callvirt.

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

----------------

(*) Я надеюсь на разумную аргументацию предложений. Мы просто не в состоянии перевести и опубликовать все старые посты, да и необходимости в этом, откровенно говоря, нет. Поэтому, если вы предлагаете к переводу некоторую статью, то разумно как минимум привести краткое содержание (парой предложений), ну и если возможно, то рассказать, чем же она такая выдающаяся.

Неявно типизированные поля в C#

2011-08-25T21:41:00.001+03:00

Сегодня на кывте был задан очередной весьма интересный вопрос о том, почему в языке C# существуют неявно типизированные локальные переменные (implicitely-typed local variables) a.k.a. var, но нет неявно типизированных полей?

На самом деле, такое положение дел вовсе не случайно; так что давайте рассмотрим несколько причин, почему компилятор ведет себя именно так, а не иначе.

Во-первых, возможность использовать var, для объявления неявно типизированных локальных переменных, никогда не была самостоятельной возможностью. При разработке языка C# никто не ставил перед собой цели создать полностью неявно типизированный язык программирования, типа F#; неявная типизация была лишь одной составляющей (пусть и немаловажной) более общей концепции, известной сегодня под аббревиатурой LINQ.

Поскольку при разрабоке LINQ-а было принято решение, что завязывать разработчика только на существующие типы является слишком «злым» ограничением, то при ее реализации была предоставлена разработчику возможность возвращать последовательности анонимных классов. А раз так, то без использования неявно типизированных переменных это было бы не возможно:

IEnumerable<Customer> customers = null;
// Упс, а тип переменной result какой? IEnumerable<??>?
var result = from c in customers
                where c.Age > 33
                select new { c.Name, c.Age };

Однако использование ключевого слова var в объявлении типа никак бы не помогло решить более глобальную цель (это я опять про LINQ).

Во-вторых, даже если не залазить слишком глубоко в то, насколько сложно было бы реализовать такую возможность компиляторописателям (*), даже навскидку с ее реализацией и использованием связаны некоторые недостатки. Первый недостаток связан с тем, что неявно типизированные поля будут плохо дружить с анонимными типами.

Давайте представим себе следующий класс:

public class Foo
{
    public var someField = new {Name = "name", Value = 12};

}

Поскольку анонимные типы в .Net реализованы сейчас в виде internal-типов, то «экспортировать» этот тип за пределы текущей сборки просто напросто нельзя. Можно, конечно же, ограничить использование неявно типизированных полей только для интернал классов или приватных полей, или вообще запретить использование неявно типизированных полей с анонимными классами, но это сделает поведение двух семантически схожих конструкций языка C# слишком разным. Одна из причин появление var в C# 3.0 – это использование анонимных типов (с LINQ-ом или без), а тут получается, что неявнотипизированные поля с ними работать не будут.

Еще одним важным ограничением является то, что неявно типизированные поля вводят слишком тесную связь между инициализируемым полем и «инициализатором». Давайте рассмотрим такой пример: предположим, у нас есть класс A, который содержит “var”-поле с именем foo, которое инициализируется путем вызова статического метода Foo класса B:

public class A
{
    public static var foo = B.Foo();
}
 
public class B
{
    public static int Foo()
    {
        return default(int);
    }
}

Это приводит к целому ряду дополнительных вопросов: а что будет, если классы A и B расположены в разных сборках? А что если без перекомпиляции сборки A будет перекомпилирована сборка с классом B и тип возвращаемого значения метода Foo изменится с типа int на string? Или же у нас может быть еще неявно типизированное поле C.foo (т.е. поле foo в классе С), завязанное на тип поля A.foo, поле D.foo, завязанное на поле C.foo и т.д. и тогда изменение типа возвращаемого значения одной функции приведет к изменению типов полей в десятке разных классов (**). Да и вообще, поля являются более важной частью дизайна класса и его реализации по сравнению с локальными переменными, поэтому изменение «на лету» типа этого поля, только из-за того кто-то поменял сигнатуру функции в третьем модуле является не лучшей идеей.

Конечно же, можно было бы ограничить возможность использования неявно типизированных полей лишь в ограниченном наборе случаев, и запрещать использование этой возможности с анонимными типами и классами из других сборок, а оставить, например, только использование методов текущего класса. Но даже в этом случае реализация этой возможности требует слишком больших усилий на реализацию (пруф у Эрика, я тут не причемJ), что делает ее довольно низкоприоритетной в бесконечном списке улучшений, которые есть в головах разработчиков компилятора языка C#.

----------------------

(*) Залазить «в дебри» нет никакого смысла, поскольку это уже сделал Эрик Липперт в своей заметке Why no var on fields?, в которой он как раз и рассказывает о том, что реализация неявно типизированных полей потребовала бы значительно более существенных затрат на реализацию, нежели реализация неявно типизированных локальных переменных.

(**) Конечно, это не показатель, и любую возможность использовать правильно или не правильно. Но с помощью этой штуки можно нагородить такого, что пример, приведенный в заметке Как не надо писать код случай, может еще и цветочками показаться (поскольку мелкие изменения будут приводить к мессу не в одном классе, а еще и в десятке других).

О книге “MS Visual C++ 2010 в среде .NET. Библиотека программиста”

2011-08-23T17:46:00.001+03:00

Если посмотреть на мои обзоры книг (*), то может возникнуть подозрение в предвзятости, поскольку отзывы либо положительные, либо восторженные. Объясняется эта ситуация довольно просто: прежде чем браться за чтение книги разумно совершить «разведку боем» и выяснить, насколько чтение той или иной книги полезно и актуально. Если отзывы на книгу хорошие, автор внушает доверие, а тема интересна, то есть все шансы на то, что и вы не пожалеете о потерянном времени. Если же отзывы сугубо отрицательные и за версту тянет стилем изложения «Для чайников» в самом плохом смысле этого слова, то и время на такую книгу тратить не стоит.

Сегодня же будет исключение из этого правила, связанное, в первую очередь с тем, что это не совсем рецензия, а результаты упомянутой выше «разведки боем», однако ее было более чем достаточно, чтобы сложилось вполне конкретное впечатление об этом творении.

--------------------------------

Периодически я просматриваю новинки, которыми нас балуют наши отечественные издатели и вот на днях я увидел, что издательство Питер выпустило книгу под названием «MS Visual C++ 2010 в среде .NET» из серии «Библиотека программиста» (**) о Visual C++ от некоего Зиборова В.В. Поскольку сам факт выхода книги в такой серии много чего значит, то я не поленился прочитать аннотацию, пролистать содержание и фрагмент одной из глав, и вот, что я об этом думаю.

1. Название и аннотация

Название книги, как и ее обложка является важной составляющей любой книги, поскольку именно с них начинается знакомство с ней потенциального читателя. При этом желательно, чтобы название давало хотя бы минимальное представление о том, что читателя ожидает внутри, а взгляд на обложку не вывихивал глаз. Название этой книги намекает на то, что речь в ней пойдет о C++/CLI (это подтверждает и аннотация), но вот что о чем оно не говорит, так это о том, что книга является сборником рецептов.

Легкое гугление по фамилии автора дает понять, что это далеко не первое творение товарища Зиборова; помимо этой книги у него есть еще две: «Visual Basic 2010 на примерах» и «Visual C# на примерах» и даже беглое чтение аннотаций дает понять, что это три брата-акробата упакованные в разные обличия. Однако, в отличие от двух предыдущих книг, изданных издательством «БХВ-Петербург», товарищи из издательства «Питер» решили не отпугивать потенциальных читателей всякими «примерами», а назвать книгу более обтекаемо, что вполне логично.

Цитата: «Представлено много различных авторских оригинальных решений задач программирования, которых читатель не сможет найти в интернете.»

Создатель аннотации откровенно жжот. Я все понимаю, у каждого из нас есть склонность к преувеличению, но писать о том, что в сборнике советов есть «оригинальные авторские решения», это явный перебор. Да и вообще, как в наш век интернета можно говорить об уникальных решениях, которые нельзя найти в интернете? Ведь если они такие уникальные, то о них будут трубить на всех известных форумах по разработке ПО и они через неделю они перестанут быть уникальными. Хотя, нужно признать, «уникальные» советы в книге правда присутствуют, но об этом позднее.

2. Содержание

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

Даже если книга построена на основе примеров, желательно, чтобы они были сгруппированы таким образом, чтобы максимально упростить восприятие нового материала. Так, например, разумно в один момент времени давать минимум новых концепций, рассматривая темы от простых к более сложным, рассматривая в одной главе максимально связные понятия. Это позволит читателю «погрузиться» в рассматриваемую тему и «абстрагироваться» от ненужных деталей, сосредоточившись на самом главном.

Теперь давайте посмотрим на содержание:

Глава 1. Простейшие программы с экранной формой и элементами управления.
…
Пример 6. Управление стилем шрифта с помощью элемента управления CheckBox
Пример 7. Побитовый оператор «исключающее ИЛИ»
Пример 8. Вкладки TabControl и переключатели RadioButton

Во-первых, накой начинать знакомство с новым языком программирования (а ведь если судить по аннотации, то это одна из целевых аудиторий книги) с пользовательского интерфейса, а не с простого консольного приложения? Я знаю, что есть категория читателей, которые с минимальными усилиями хотят увидеть «готовое приложение», но какое это имеет отношение к языку C++/CLI? Ведь в этом случае, читатель знакомится не только с новым языком программирования, но еще и с библиотекой Win Forms, что значительно усложняет восприятие материала.

Потом, мне вообще не понятна группировка тем. Ну кто потом догадается найти пример с «исключающим ИЛИ» в главе о «простейших программах с экранной формой», да еще и между примерами с CheckBox-ом и TabControl-ом? Да и вообще, раз взялись за битовые операторы, так разумно довести дело до конца и рассмотреть их все.

Глава 2. Программирование консольных приложений ... 47
Пример 12. Ввод и вывод в консольном приложении ... 47
...
Пример 14. Вызов метода MessageBox::Show в консольном приложении. Формат даты и времени ... 51
Пример 15. Вызов функций Visual Basic из программы С++ ... 52
Пример 16. Замечательной структурой данных является словарь Dictionary ... 53

Мне сложно себе представить, какое количество совершенно разнородной информации наваливается на бедного читателя на всего-лишь десятке страниц книги (я специально привел номера страниц). В чем ценность рассмотрения формата даты и времени в примере с MessageBox-ом, да еще и в главе о консольных приложениях? А в чем польза вызова функций Visual Basic из программы С++? Чего-то мне сдается, что это не самая распространенная задача и она нисколько не поможет продвинуться в изучении языка С++. А название примера 16 вообще похоже на неудачно переведенную электронным переводчиком фразу из книги «C# за 15 минут».

Знаете, почему книга Джона Скита “C# In Depth” читается так легко? По одной простой причине: Джон рассматривается одну концепцию за раз (его знаменитая фраза “one step at a time”, которую он использует десяток раз в своей книге). Это позволяет читателю «абстрагироваться» от ненужных в данный момент времени деталей и сосредоточиться на главном: на изучении определенной концепции языка. В программировании мы ведь постоянно поступаем таким же образом для борьбы с неотъемлемой сложностью ПО; ведь мы гарантированно получим «месс», если свалим в одну сущность десяток не связанных друг с другом концепций.

Глава 12. Другие задачи, решаемые с помощью Windows Application
Пример 98. Управление прозрачностью форме
Пример 99. Время по Гринвичу в полупрозрачной форме
Пример 102. Воспроизведение звуков операционной системы

Если в главах, посвященных определенной тематике была чехарда, то что говорить о главе, которая специально посвящена всему и сразу. Когда воспроизведение звуков (кстати, тоже весьма сомнительная тема) рассматривается рядом со временем по Гринвичу, да еще и в полупрозрачной форме то это вызывает, как минимум улыбку. Неужто время по Гринвичу в непрозрачной форме или без формы вообще получить нельзя?

Между главами 2 и 12 автор рассматривает практически все темы, на которые у Троелсена ушло порядка тысячи страниц: начиная от работы с файлами, заканчивая технологией ADO.NET и использованием функций AutoCAD и созданием PDF-файла. Видимо взаимодействие с AutoCAD является действительно киллер-фичей, поскольку об этом говорится в аннотации, но мне почему-то кажется, что это не является такой уж частой задачей, ну да ладно, это дело вкуса. Идем дальше. Точнее, возвращаемся на одну главу назад, которой хочется посвятить отдельный раздел.

3. Глава 11. Использование технологии LINQ.

Этой главе стоит уделить отдельный раздел по двум причинам. Во-первых, в C++/CLI нет никакого синтаксического сахара для создания анонимных делегатов (лямбды C++ 0x не в счет, это совсем другое дело), что делает использование LINQ-а весьма ... скажем так, «многословным» делом. А во-вторых, именно эта глава лежит в открытом доступе на сайте издательства, так что мы можем познакомиться не только с содержанием, но и с содержимым.

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

bool Предикат(String ^ S)
{
  // Если число букв равно шести, то возвращаем true:
  bool A = false;
  if (S->Length == 6) A = true;
  return A;
}
String ^ Предикат2(String ^ S)
{
  // Переводим строку в верхний регистр:
  S = S->ToUpper();
  return S;
}

Итак, в аннотации сказано, что эта книга предназначена «для начинающих программистов, программистов среднего уровня, а также для программистов, имеющих опыт разработки на других языках и желающих ускоренными темпами освоить новый для себя язык MS Visual C++/CLI». Но здесь же в десятке строк кода целый букет «запахов»:

использование русскоязычных имен;
использование неинформативных имен функций и переменных; никогда, никогда, никогда, нет, вы не поняли, вообще никогда не называйте подобным образом имена функций и переменных; это бред сивой кобылы, не имеющий права на существование даже в примерах! Самое смешное, что самый первый раздел этой книги называется так: Что такое «хороший стиль программирования»?, видимо автор взял последние три слова в кавычки преднамеренно. Что за имена Предикат и Предикат2, а чем читателю поможет имя переменной A?
изменение значение параметров; напомню, что изменение значения параметров считается моветоном, поскольку читатель кода должен четко понимать, что исходный объект S в методе Предикат2 не изменился, поскольку сама ссылка передается по значению.
неверный стиль наименования; параметры и локальные переменные в среде .Net принято называть в виде camelCase-а, имена типа S и A этому правилу противоречат.
Предикат2 – это не предикат; мне, например, всегда казалось, что предикат – это такая хрень, возвращающая true или false, и быстрое гугление это мнение подтверждает.

Я вообще не говорю о том, что можно сократить число строк в методе с 3-х до одной:

bool LengthEqualToSix(String^ s)
{
    return s->Length == 6;
}

Дальше идет использование всех этих «предикатов» с помощью статических методов класса Enumerable. Но поскольку в языке C++/CLI нет таких штук как методы расширения и Method Group Conversion, то вглядит это не самым лучшим образом:

// Из массива имен получаем список имен, длина которых - шесть букв:
auto Запрос = Enumerable::Where<String^>(Имена, gcnew
                                  Func<String ^,bool>(Предикат));
// Сортируем полученный список в алфавитном порядке:
Запрос = Enumerable::OrderBy(Запрос, gcnew
                                  Func<String ^,String ^>(Предикат2));

Есть и другие перлы, типа определения поля с именем: bool КуритЛи; в классе Сотрудник, или создание списка сотрудников по массиву сотрудников перед использованием методов класса Enumerable (видимо автор не знает, что к массиву статические методы класса Enumerable применимы точно так же, как и листу); и предикаты следующего вида:

bool Предикат(Сотрудник S)
{
  // Если сотрудник не курит, то заносим его в список некурящих:
  bool A = false;
  if (S.КуритЛи == false) A = true;
  return A;
  // Можно было бы записать короче:
  // return !S.КуритЛи;
  // но более запутанно
}
 
Месяц Предикат2(Месяц t)
{
  return t;
}

Чем автору не понравилась альтернативная запись и почему переменная типа Месяц называется t и почему только в этом случае имя переменной записано в нижнем регистре, я не знаю.

Заключение

Я хочу, чтобы меня поняли правильно: у меня нет ни малейших претензий к автору, который написал одну книгу и растиражировал ее, используя примеры на разных языках программирования. И у меня не было бы никаких вопросов к издательству, если бы обложка этой книги была бы пожелтее и вышла бы она в серии «Для чайников». Но выпускать ТАКОЕ в популярной и известной серии, рядом со знаменитыми работами таких признанных мировых экспертов, как Спольски, Бокс, Хант, Макконнелл и многих других, кажется просто преступлением.

Ребята издатели, существует масса интересных книг по программированию на платформе .Net, в том числе и на языке C++/CLI, которые могут занять достойное место в библиотеке программиста, но эта книга явно не из таких (***).

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

Да, чуть не забыл, чтобы долго не рылись, вот содержание, а вот фрагмент главы.

---------------

(*) Все мои рецензии, а также некоторые обзоры и анонсы книг можно найти здесь.

(**) Нужно сказать, что в этой серии выходят неплохие книги, такие, например, как «Философия Java» Эккеля, «Чистый код» Мартина, «Паттерны проектирования» банды четырех и многие другие. Я имею ввиду, что это не серия типа «Изучи все на свете за 15 минут во сне», это вполне серьезная серия книг.

(***) В качестве отправной точки при поиске книг по программированию на платформе .Net можно отталкиваться от следующего списка: Классические книги по C#/.NET.

Effective Concurrency от Герба Саттера

2011-08-17T00:13:00.001+03:00

Герб Саттер, если вдруг кто не знает, это гуру С++ и многопоточности, автор нескольких весьма популярных книг и сотни известных статей, главный дизайнер языка C++/CLI и всяких там многопоточных расширений, в общем, крут парень, ничего не скажешь.

Но именно в данном случае интересно не это. Сегодня я отправил Гербу мыло с просьбой разрешить перевод и публикацию у себя в блоге его серии статей Effective Concurrency, и получил от него ответ через 40 (!) минут. То что ответ был отрицательным, это уже второе, но сам факт, что такие люди отвечают столь оперативно не может не радовать.

К сожалению, права на статьи серии Effective Concurrency принадлежат издательству Addison-Wesley, поскольку планируется выпуск одноименной книги, и эти ребята не разрешают никаких других публикаций, как минимум до выхода англоязычной книги в свет. А состоится этот выход в свет, по словам Герба, не раньше следующего года, ибо дел сейчас у него по горло (что не удивительно в свете событий, связанных с финальной стадией принятия нового стандарта С++).

Так что у нас, как всегда, две новости: одна хорошая, другая – не очень. Хорошая новость заключается в том, что Герб отличный парень и у нас скоро будет его новая книга, ну а плохая – что это “скоро” наступит не раньше следующего года.

Дополнительные ссылки

Ко всем статьям из серии Effective Concurrency можно достучаться через один из постов блога Герба по этой теме, например, отсюда: Effective Concurrency: Know When to Use an Active Object Instead of a Mutex
Еще рекомендую посмотреть записи с Гербом на Channel9:

Conversation with Herb Sutter: Perspectives on Modern C++(0x/11) – веселое интервью, в основном посвященное вопросам процесса стандартизации и новым фичам С++.
E2E: Herb Sutter and Erik Meijer - Perspectives on C++ – серия с Эриком Мейером Expert To Expert, мне вообще кажется одной из самых интересных; так что, рекомендую
Остальные записи с Гербом на Channel9

Гарантии безопасности исключений

2011-08-15T22:07:00.001+03:00

Ошибки в обработке ошибок являются наиболее распространенным источником ошибок
Бредня, пришедшая в голову при написании этой статьи

Основные баталии по поводу того, что лучше использовать при программировании на C# – исключения или коды возврата для обработки, ушли в далекое прошлое (*), но до сих пор не утихают баталии другого рода: да, хорошо, мы остановились на обработке исключений, но как же нам их обрабатывать «правильно»?

Существует множество точек зрения о том, что же такое «правильно», большая часть из которых сводится к тому, что нужно перехватывать только те исключения, которые ты можешь обработать, а все остальные пробрасывать вызывающему коду. Ну, а в случае, если на верхний уровень пробралось дерзким образом непонятное исключение, то стрелять все приложение целиком, поскольку уже не понятно, находится ли оно, родимое, в согласованном состоянии или нет.

Существует множество «за» и «против» такого способа перехвата и обработки исключений, но сегодня я хочу рассмотреть несколько другую тему. А именно тему обеспечения согласованного состояния приложения в свете возникновения исключения – три уровня безопасности исключений.

Три типа гарантий

В конце 90-х годов Дейв Абрахамс (Dave Abrahams) предложил три уровня безопасности исключений: базовая гарантия, строгая гарантия и гарантия отсутствия исключений. Эта идея была тепло встречена сообществом С++ разработчиков, а после ее популяризации (и некоторой модификации) Гербом Саттером, гарантии безопасности исключений стали широко применяться в boost-е, в стандартной библиотеке С++, а также при разработке прикладных приложений.

Изначально эти гарантии были предложены Дейвом Абрахамсом для реализации библиотеки STLPort на языке С++, но сама идея безопасности исключений не привязана к конкретному языку программирования и может использоваться в других языках, использующих исключения в качестве основного механизма обработки ошибок, таких как Java или C#. Кроме того, в настоящее время существует две версии определений гарантии безопасности исключений: (1) исходная версия, предложенная Дейвом Абрахамсом и (2) модифицированная версия, популяризированная Саттером и Страуструпом, и более подходящая не только для библиотек, но и для прикладных приложений.

Базовая гарантия

Исходное определение: “в случае возникновения исключений не должно быть никаких утечек ресурсов”.

Современное определение: “при возникновении любого исключения в некотором методе, состояние программы должно оставаться согласованным”. Это означает, не только отсутствие утечек ресурсов, но и сохранение инвариантов класса, что является более общим критерием, по сравнению с базовым определением.

Разница между этими двумя формулировками обусловлена тем, что изначально эта гарантия были предложена для реализации библиотеки на языке С++ и не имела никакого отношения к прикладным приложениями. Но если говорить о более общем случае (т.е. о приложении, а не только о библиотеке), то можно сказать, что утечки ресурсов являются лишь одним из источников багов, но далеко не единственным. Сохранение инварианта в любой устойчивый момент времени (**) является залогом того, что никакой внешний код не сможет «увидеть» рассогласованного состояния приложения, что, согласитесь, не менее важно, чем отсутствие утечек ресурсов. Мало какого пользователя банковского приложения будут интересовать утечки памяти, если при переводе денег с одного счета на другой, деньги могут «уйти» с одного счета, но «не дойти» до другого.

Строгая гарантия

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

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

Гарантия отсутствия исключений

Гарантия отсутствия исключений сводится к следующему: “ни при каких обстоятельствах функция не будет генерировать исключения”.

Эта гарантия наиболее простая с точки зрения определения, однако, она не так проста, как кажется. Во-первых, ее практически невозможно обеспечить в общем случае, особенно в среде .Net, когда исключение может произойти практически в любой точке приложения. На практике, лишь единицы операций следуют этой гарантии, и именно на основании таких операций строятся гарантии предыдущих уровней. В языке C#, то одной из немногих операций, обеспечивающих эту гарантию, является присваивание ссылок, а в языке C++ - функция swap, реализующая обмен значений. Именно на основании этих функций зачастую и реализуется строгая гарантия исключений, когда вся «грязная работа» выполняется во временном объекте, который затем присваивается результирующему значению.

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

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

Теперь давайте рассмотрим несколько примеров.

Примеры нарушения базовой гарантии

Главным способом предотвращения утечек памяти и ресурсов в языке C++ является идиома RAII (Resource Acquisition Is Initialization), которая заключается в том, что объект захватывает ресурс в конструкторе и освобождает его в деструкторе. А поскольку вызов деструктора осуществляется автоматически при выходе объекта из области видимости по любой причине, в том числе и при возникновении исключения, то неудивительно, что эта же идиома используется и для обеспечения безопасности исключений.

В язык C# эта идиома перекочевала в виде интерфейса IDisposable и конструкции using, однако, в отличие от С++ она применима для управления временем жизни ресурса в некоторой области видимости, и не подходит для управления множеством ресурсов, захватываемых в конструкторе.

Давайте рассмотрим такой пример:

// Некоторый класс, содержащий управляемые ресурсы
class DisposableA : IDisposable
{
    public void Dispose() {}
}
 
// Еще один класс с управляемыми ресурсами
class DisposableB : IDisposable
{
    public DisposableB()
    {
        disposableA = new DisposableA();
        throw new Exception("OOPS!");
    }
 
    public void Dispose() {}
 
    private DisposableA disposableA;
}
 
// Где-то в приложении
using (var disposable = new DisposableB())
{
    // Упс! Метод Dispose не будет вызван ни для 
    // DisposableB, ни для DisposableA
}

Итак, у нас есть два disposable-класса: DisposableA и DisposableB, каждый из которых захватывает некоторый управляемый ресурс в конструкторе и освобождает его в методе Dispose. Давайте пока не будем рассматривать финализатор, поскольку он никак не поможет нам гарантировать детерминированный порядок освобождения ресурсов, что в некотором случае является жизненно важным.

В данном случае, при генерации исключения конструктором класса DisposableB мы никогда не вызовем метод Dispose, поскольку объект disposable никогда не существовал. В этом плане поведение у большинства mainstream языков программирования более или менее одинаковое, но есть и некоторые отличия. Сходство заключается в том, что если конструктор «упадет», то вызывающий код так и не сможет получить ссылку на еще не сконструированный объект и явно освободить его ресурсы. Однако, в отличие от языка С++, в котором вызов деструктора полностью сконструированных полей осуществляется автоматически, в «управляемом» языке C# этого не происходит (***).Если конструктор класса DisposableB сгенерирует исключение и не освободит уже захваченные ранее ресурсы самостоятельно, мы получим «утечку ресурсов» (или, как минимум, недетерминированное их освобождение).

Эта же проблема может проявляться и более тонким образом. В рассмотренном ранее случае, явно видно, что мы создали экземпляр disposable-объекта, после чего генерируется исключение. Но бывают случаи, когда отсутствие базовой гарантии исключений увидеть немного сложнее.

class Base : IDisposable
{
    public Base()
    {
        // Захватываем некоторый ресурс
    }
    public void Dispose() {}        
}
 
class Derived : Base, IDisposable
{
    public Derived(object data)
    {
        if (data == null)
            throw new ArgumentNullException("data");
        // OOPS!!
    }
}

 
// И снова где-то в приложении
using (var derived = new Derived(null))
{}

Генерация исключения в конструкторе класса Derived нарушает базовую гарантию исключений и приводит к утечке ресурсов, поскольку метод Dispose класса Base не вызывается (****). Опять таки, поскольку компилятор знает об интерфейсе IDisposable только через призму конструкции using, то во всех случаях, когда disposable объект является полем другого класса, за вызов метода Dispose отвечает только программист.

Помимо базового класса, подобную же шутку может сыграть и инициализаторы полей, когда конструктор одного из полей может генерировать исключение:

class ComposedDisposable : IDisposable
{
    public void Dispose() {}
 
    private readonly DisposableA disposableA = new DisposableA();
    // А что, если конструктор DisposableB упадет? OOPS!!
    private readonly DisposableB disposableB = new DisposableB();
}

В данном случае, если конструктор класса DisposableB при инициализации поля disposableB сгенерирует исключение, то перехватить его и освободить уже захваченные ресурсы будет невозможно. В С++ существует такая вещь, как перехват исключений, возникших в списке инициализации (см. Exception and Member Initialization), однако такая возможность в языке C# отсутствует, поэтому выход из этой ситуации один: старайтесь ее не допускать.

Что касается всех предыдущих случаев, то обеспечение базовой гарантии исключений полностью ложится на плечи разработчика, поскольку никакого «сахара» для этих целей язык C# не предоставляет. Все, что нам остается, это либо создавать подобъекты в нужном порядке и disposable поле создавать в самом конце конструктора, либо оборачивать их создание в блок try/catch и очищать все ресурсы, в случае возникновения исключения.

Пример строгой гарантии исключений. Object initializer и collection initializer

Примеры нарушения базовой гарантии исключений, приведенные выше, хоть и не являются надуманными, но встречаются не так и часто. И если в случае создания объектов, содержащих несколько управляемых ресурсов, компилятор языка C# ничем нам помочь не может, то он может помочь в некоторых других случаях, например, при создании объектов и коллекций.

Инициализатор объектов и коллекций (object initializer и collection initializer) обеспечивают атомарность создания и инициализации объекта или заполнения коллекции списком элементов. Давайте рассмотрим следующий пример.

class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }
}
 
var person = new Person
{
    FirstName = "Bill",
    LastName = "Gates",
    Age = 55,
};

С первого взгляда может показаться, что это всего лишь синтаксический сахар для следующего:

var person = new Person();
person.FirstName = "Bill";
person.LastName = "Gates";
person.Age = 55;

Однако на самом деле, при вызове инициализатора объекта создается временная переменная, затем изменяются свойства именно этой переменной, и только потом она присваивается новому объекту:

var tmpPerson = new Person();
tmpPerson.FirstName = "Bill";
tmpPerson.LastName = "Gates";
tmpPerson.Age = 55;
var person = tmpPerson;

Это обеспечивает атомарность процесса создания объекта и невозможность использования частично инициализированного объекта в случае генерации исключения одним из setter-ов. Аналогичный принцип лежит и в инициализаторе коллекций, когда объекты добавляются во временную коллекцию и лишь после ее заполнения временная переменная присваивается новому объекту.

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

Заключение

Корректная обработка исключений дело не простое, и, как показали некоторые примеры, иногда даже базовая гарантия исключений дается с трудом. Однако обеспечение подобных гарантий является жизненно необходимым условием при разработке приложений, поскольку значительно легче всю сложность по работе ресурсами упрятать в одном месте, нежели размазать ее тонким слоем по всему приложению. Золотое правило, сформулированное десяток лет назад Скоттом Мейерсом все еще остается в силе: создавайте классы, которые легко использовать правильно и сложно использовать неправильно, и гарантия исключений в этом играет явно не последнюю роль.

Если говорить о практическом применении данных гарантий, то следует помнить несколько моментов. Во-первых, код, не выполняющий базовую гарантию исключений некорректен; на его основе просто невозможно создать приложение, чье состояние не будет разламываться при его использовании или изменении (*****). Во-вторых, не стоит параноить и добиваться максимальной гарантии. Добиться гарантии отсутствия исключений на 100% вообще практически невозможно из-за наличия асинхронных исключений, но даже реализация строгой гарантии во многих случаях может быть неоправданно дорогой.

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

----------------------

(*) На самом деле, «горячих» дебатов, в общем-то, и не было по одной простой причине: вы не можете программировать на платформе .Net без обработки исключений. Подобные дебаты актуальны, например, в языке C++, особенно, когда речь заходит о низкоуровневом программировании.

(**) В общем случае, никто не требует сохранение инварианта всегда; обычно требуется сохранение инварианта «до» и «после» вызова открытого метода, но совсем необязательно его сохранение после вызова закрытого метода, выполняющего лишь «часть» работы.

(***) Может показаться весьма забавным тот факт, что более «навороченный» язык, такой как C# может не делать чего-то, что делает старина С++, но это действительно так. Давайте в качестве примера, перепишем рассмотренный ранее код с C# на C++:

class Resource1
{
public:
    Resource1()
    {
        // Захватываем некоторый ресурс, будь-то выделяем память
        // в куче или создаем дескриптор ОС
    }
    ~Resource1()
    {
        // Освобождаем захваченный ресурс
    }
};
 
class Resource2
{
public:
    Resource2()
    {
        // В этой точке кода объект resource1_ уже проинициализирован
        throw std::exception("Yahoo!");
    }
private:
    Resource1 resource1_;
};
 

// где-то в приложении создаем экземпляр класса Resource2
Resource2 resource2;

Как уже было сказано ранее в языке С++ (в отличие от языка C#), при генерации исключения в конструкторе класса деструкторы уже сконструированных полей (т.е. подобъектов) будут вызваны автоматически. Это значит, что в данном случае вызов деструктора объекта Resource1 произойдет автоматически и никаких утечек ресурсов не будет.

Такие отличия в поведения языков C# и C++ легко объяснимо. В языке С++ ресурсом является все, включая динамически выделенную память, поэтому и средства управления ресурсами находятся на более высоком уровне. Прикладной же программист, работающий с языком C#, значительно чаще использует ресурсы в блоке using, нежели захватывает ресурсы в конструкторе. И если же он сталкивается с такой задачей, то решить ее придется ему самостоятельно, без помощи компилятора.

Кстати, Герб Саттер уже рассказывал об этом когда-то в своей заметке: “Constructor Exceptions in C++, C#, and Java”.

(****) Может я уже и достал с этими примечаниями, но это достаточно важное и, кажется, предпоследнее. Подобный пример достаточно часто любят задавать на собеседованиях, так что теперь, мои читатели знают на него правильный ответ!

(*****) Все сказанное в этой статье относится только к синхронным исключениям, поскольку гарантировать согласованное возникновении «асинхронных» исключений, таких как OutOfMemoryException или ThreadAbortException практически невозможно. За пруфом сюда: «О вреде метода Thread.Abort».

Programming stuff

Принцип замещения Лисков и контракты

Заключение

Принцип замещения Лисков. Определение

Дополнительные ссылки

Повторное использование знаний

Повторное использование знание на примере WCF

Обобщение знаний на примере автоматического управления памятью

Attached свойства для ограничения текстового ввода

Ну что, приступим?

Решение задачи

Формирование измененной строки

Класс TextBoxDoubleValidator

Альтернативные решения

Заключение

18 фактов о Джоне Ските

Первый workshop по .NET и архитектуре

The Art of Unit Testing

Дополнительные ссылки по теме

Книги

Подкасты

Статьи

Ретроспектива 2011

Стабы и моки

Создания «швов» для тестирования приложения

Проверка состояния vs проверка поведения

А зачем мне знать об этих отличиях?

Кто такой “хороший программист”?

Идеальная архитектура

Отступление от темы. Clean Architecture от Боба Мартина

Заключение

Observable.Generate и перечисление списков

Повторная генерация исключений

Проблемы передачи списка перечислений или Почему абстракции «текут»

Решение проблемы

1. Добавление значения по умолчанию

2. Передача коллекции без «пустых» элементов

3. Использование других типов коллекций в интерфейсе сервисов

Доклады по асинхронному и реактивному программированию

Реактивные расширения

Асинхронное программирование

Dispose pattern

Идиома RAII

Управляемые и неуправляемые ресурсы

Dispose pattern

Прагматичный взгляд на Dispose паттерн

Упрощенная версия Dispose паттерна

Заключение

Google+

Принцип самурая

Вы, конечно, шутите, мистер Фейнман

Wanted! Старые хиты Эрика Липперта

Неявно типизированные поля в C#

О книге “MS Visual C++ 2010 в среде .NET. Библиотека программиста”

1. Название и аннотация

2. Содержание

Заключение

Effective Concurrency от Герба Саттера

Дополнительные ссылки

Гарантии безопасности исключений

Три типа гарантий

Базовая гарантия

Строгая гарантия

Гарантия отсутствия исключений

Примеры нарушения базовой гарантии

Пример строгой гарантии исключений. Object initializer и collection initializer

Заключение