Является ли "Класс данных" действительно запахом кода?

Книга Фаулера Refactoring перечисляет "Класс данных" как запах кода. Однако при модульном тестировании метода, передавая объекты значений, например, объекты передачи данных, сделать тестирование намного проще, чем пытаться настроить или изучить состояние внутри класса.

Мне кажется, что методология Test Driven Development основана на идее, что легко написать тесты - это признак того, что интерфейс чист, а метод является сплоченным. Чисто идемпотентные методы легче всего тестировать и проще всего использовать повторно. Так почему же класс данных плохой? Рекомендуемое исправление заключается в перемещении поведения в класс данных, но зачем нужно, чтобы объект значения нуждался в поведении?

Ответ 1

Я не думаю, что классы данных такие же, как объекты значений. Объекты Value обычно неизменяемы - например, Length или Money. "Классы данных", которые относится к Фаулеру, выглядят как модели анемичных доменов, т.е. Мешки геттеров и сеттеров.

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

Случай с немодифицируемыми классами данных:

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