Pull to refresh

Fluent Generics in C#

Reading time8 min
Views18K

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

Несмотря на то, что дженерики давно в C#, мне всё же удаётся найти новые интересные способы их применения. Например, в одной из моих предыдущих статей я написал об уловке, позволяющей добиться return type inference, что может облегчить работу с контейнерными union types.

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

После нескольких экспериментов, я нашёл способ решить проблему элегантно, используя подход схожий с паттерном проектирования fluent interface, который был применён не к объектам, а к типам. Мой подход предлагает domain-specific language, который позволяет разработчику построить нужный тип за несколько логических шагов, последовательно его "конфигурируя".

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

Читать далее
Total votes 32: ↑32 and ↓0+32
Comments43

Assert DSL на примере .Net

Reading time8 min
Views3.6K
Никто уже не отрицает полезность тестов в любой сколько-нибудь сложной системе. Без тестов очень быстро можно скатиться в хаос и проводить большую часть времени в отладчике, занимаясь поиском и отловом косвенных эффектов от изменений той или иной части приложения. Тесты важны, нужны и так далее по тексту.

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

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

В общем, все должно быть направлено на максимальную ясность и четкость тестов, чтобы явно было видно все взаимосвязи. Чтобы можно было восстановить логику программы по одним лишь тестам. В дело читабельности пойдет не только Assert DSL (Domain Specific Language), но и именование файлов, подход Arrange Act Assert. Все это не новые подходы как оказывается, но широкой известности пока не получившие, судя по тому, что я вижу в окружающих меня проектах. Да и сам я натолкнулся на новые темы случайно, изучая исходные коды StructureMap.

Чтобы не томить, сразу расскажу какие основные шаги предлагаются для улучшения тестов:
  • Именовать тестовые файлы по основному методу, который тестируется.
  • Использовать DSL  для создания объектов, чтобы методы делать максимально лаконичными.
  • Стараться писать тесты в стиле «один тестовый метод – один assert».
  • Структурировать внутренности теста.
  • Создать и использовать Assert DSL.

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

Раскрытие темы с примерами и в картинках
Total votes 23: ↑20 and ↓3+17
Comments11

Юнит-тесты, BDD и сила текучих утверждений (fluent assertions) в 1С

Reading time5 min
Views18K

Немного истории


Благодаря классному дядьке Кенту Беку (Kent Beck) родилась замечательная методология test-driven development. Не смотря на необычность подхода, переворачивающего привычный процесс написания кода с ног на голову (тест на функционал создается до реализации), сейчас уже можно сказать, что разработка через тестирование стала стандартом де-факто. Практически в любых вакансиях фигурирует требование к знанию и опыту использования методики TDD и соответствующих инструментов. Почему, казалось бы, ломающая привычную парадигму мышления методология прижилась и стандартизировалась? Потому что “Жизнь слишком коротка для ручного тестирования”, а писать авто-тесты на существующий код иногда просто не возможно, ведь код, написанный в обычной парадигме, как правило совершенно тесто-не-пригодный.

Стоит отметить, что за время своего существования методология успела обзавестись ответвлением (fork) в виде BDD. Дэн Норт (Dan North) в своей статье (Introducing BDD) указал на сложности внедрения TDD среди разработчиков и для решения обозначенных проблем предложил практику, которая называется behaviour-driven development. Основной фишкой BDD можно назвать микс из TDD и DDD, которая в начале выражалась в правильном именовании тестовых методов (названия тестовых методов должны быть предложениями). Апогеем BDD, на текущий момент, можно считать рождение языка Gherkin и инструментария, который его использует (Cucumber, RSpec и т.п.).
Читать дальше →
Total votes 17: ↑15 and ↓2+13
Comments48

Организация текучих (fluent) интерфейсов в Python

Reading time4 min
Views5.5K
Вдохновлённый недавним постом про текучие интерфейсы на PHP, я сразу задумался как можно реализовать подобное на питоне проще и красивее (на питоне всегда всё проще и красивее). Предлагаю несколько способов в порядке поступления мыслей.



Читать дальше →
Total votes 63: ↑61 and ↓2+59
Comments34

Рефакторинг последовательных проверок в Mockito с помощью fluent-интерфейсов

Reading time10 min
Views7.5K

У статических методов есть одна мощная, но и в то же время весьма нежелательная особенность: их можно вызвать из любого места в коде, не особо имея возможность регламентировать порядок их вызова. Зачастую такой контроль очень важен, но иногда порядок не имеет очень большого смысла. Например, осуществлять проверки в юнит-тестах часто можно не в очень строгом порядке. И чтобы гарантировать, что в тестируемом юните выполенены все проверки, в Mockito существует всё тот же статический метод verifyNoMoreInteractions(...). Иногда можно по ошибке вызвать такой метод ещё до последнего verify(...) и потом с огорчением наблюдать "красный" тест. Но что если переложить заботу о порядке выполнения проверок на сам компилятор?


Читать дальше →
Total votes 15: ↑14 and ↓1+13
Comments8

Элегантные строки

Reading time4 min
Views16K
Представим, что нам нужно что-нибудь сделать со строками в .net. Что-то не очень сложное, но и не совсем простое. Например, для правильного форматирования, расставить пробелы после запятых в тексте. Что же предлагает .net из коробки?
Что-то такое:

string str = "...";
str.Replace(",", ", ");


Постойте, но мы же хотели расставлять пробелы, а не заменять запятые!..
Хорошо, пойдем дальше.
Total votes 49: ↑28 and ↓21+7
Comments41

Шаблон программирования «Текучий интерфейс» в PHP. Свежий взгляд

Reading time5 min
Views37K

При разработке программного обеспечения одной из важных составляющих является высокая читабельность исходного кода программы. Существуют специальные методики и рекомендации, которые позволяют добиться улучшения читабельности исходного кода. Одной из методик улучшения читабельности исходного кода является применение «текучих интерфейсов» (англ. Fluent Interface). О нем мы и поговорим в данной статье.
Читать дальше →
Total votes 67: ↑48 and ↓19+29
Comments67

Fluent interface и Delphi

Reading time2 min
Views9.2K
Текучий интерфейс (Fluent interface) — совсем молодая методика, даже скорее паттерн проектирования, получивший популярность и широкое распространение среди кодеров Java, C#, PHP.
В большинстве методик «хорошего кода» лежит разряжение текста кода (висячие строки, пробелы, отступы, etc) и это очень здорово, но иногда это превращается в сущий ад. Пробежка скролом по коду, запоминание цепочки вызова метода, вечная дилемма между длинным методом и читабельностью, etc.
Но решение есть — Текучий интерфейс! Теперь и на Delphi!
Читать дальше →
Total votes 19: ↑11 and ↓8+3
Comments17

Автоматический «текучий интерфейс» и ArrayIterator в PHP-моделях

Reading time7 min
Views10K
Данный способ не претендует на оригинальность, но, как мне кажется, может быть полезен в понимании принципов работы подобных систем (см. например Varien_Object, написанный разработчиками Magento, идея была взята в первую очередь оттуда) и, возможно, будет полезен в проектах, куда не очень хочется подключать тяжелые фреймворки, но уже нужно как-то систематизировать код.

Сложно представить достаточно крупный проект, в котором не было бы работы с моделями данных. Скажу больше: по моему опыту около трех четвертых всего кода — это создание, загрузка, изменение, сохранение или удаление записей. Будь то регистрация пользователя, вывод десятка последних статей или работа с админкой — все это мелкая работа с базовыми операциями моделей. И, соответственно, такой код должен писаться и читаться быстро и не должен забивать голову программиста техническими деталями: он (программист) должен думать о логике работы приложения, а не об очередном UPDATE-запросе.
Подробнее - под катом
Total votes 19: ↑12 and ↓7+5
Comments45

Возвращаем дочерний класс из родительского. Факультатив

Reading time3 min
Views22K
С какой целью это может понадобиться? Например, если хочется использовать "текучий интерфейс". Правда, если часть методов разместить в родительском классе, то для них не получится сделать полноценный «текучий интерфейс» — эти методы требуется приводить (кастовать) к дочернему.

Казалось бы, печаль да и только, но если очень хочется, то ведь можется. Поэтому, давайте слегка нарушим правило и «известим» родительский класс о его наследниках.
Читать дальше →
Total votes 18: ↑13 and ↓5+8
Comments21

ReactiveValidation: валидация данных в WPF

Reading time9 min
Views11K
Здравствуй, Хабр!

Мне хотелось бы рассказать об Open Source библиотеке для WPF — ReactiveValidation, в процессе написания которой я пытался ориентироваться на FluentValidation и Reactive UI. Её задача — это валидация формы каждый раз, когда пользователь изменил данные внутри неё.


Пример работы с библиотекой. Хорошая новость — шаблон можно использовать свой

Основные фичи библиотеки:

  • Правила создаются через fluent-интерфейс
  • Полный внутренний контроль над изменением свойств
  • Поддержка локализации (в том числе «на лету»)
  • Отображение сообщений в GUI
Читать дальше →
Total votes 15: ↑15 and ↓0+15
Comments4

Код живой и мёртвый. Часть первая. Объекты

Reading time7 min
Views14K

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


И вместе с этим мы видим повсеместную эпидемию менеджеров, хелперов, сервисов, контроллеров, селекторов, адаптеров, геттеров, сеттеров и другой нечисти: всё это мёртвый код. Он сковывает и загромождает.


Бороться предлагаю вот как: нужно представлять программы как текст на естественном языке и оценивать их соответственно. Как это и что получается — в статье.

Читать дальше →
Total votes 34: ↑28 and ↓6+22
Comments55

Код живой и мёртвый. Часть вторая. Действия и свойства

Reading time6 min
Views5.8K

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


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


Об этом — в статье.

Читать дальше →
Total votes 18: ↑17 and ↓1+16
Comments62

Код живой и мёртвый. Часть третья. Код как текст

Reading time9 min
Views5.9K

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


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


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

Читать дальше →
Total votes 12: ↑10 and ↓2+8
Comments102