«Запах» проектирования: одержимость примитивами

Это второй пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

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

Это проблема обсуждалась уже много раз. Годами ранее, Джимми Богард ^[1] предоставил отличную трактовку проблемы, впрочем как и руководство по её решению ^[2]. В связи с разработкой AutoFixture ^[3], я также был затронут этой проблемой некоторое время назад ^[4]. Фактически, этот пост является «заполнителем».
Следует заметить, что и мой пост и пост Jimmy показывают то, что строки и целочисленные типы недостаточно инкапсулируют такие концепции, как почтовый индекс или телефонный номер.

• Если почтовый индекс представлен строкой, то ему возможно присвоить null, string.Empty, “foo”, очень длинную строку и т.д. Класс ZipCode, написанный Джимми, инкапсулирует концепцию, гарантируя, что экземпляр может быть создан только с корректным значением.
• Если датский телефонный номер представлен целым числом, то ему возможно присвоить 98, 0, int.MaxValue и т.д. Класс DanishPhoneNumber из предыдуущего примера инкапсулирует концепцию, гарантируя, что экземпляр может быть создан только с корректным значением.

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

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

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

Автор: EngineerSpock

Источник ^[5]