Я не думаю, что это особенно не-объектно-ориентированный.Если ваш домен таков, что Person
может иметь ноль или более EmailAddress
es, то вы почти точно описали ситуацию с использованием списка.
Единственный альтернативный подход, о котором я могу подумать, этоиметь такие поля, как
WorkEmail
PersonalEmail
OtherEmail1
OtherEmail2
OtherEmail3
, но, на мой взгляд, это хуже, потому что:
- Вы просто не можете поддерживать более пяти адресов электронной почты (ну, вы можете добавить больше полей,но это усиливает боль в последних точках и все еще накладывает некоторый конечный предел.)
- Вы подразумеваете некоторую дополнительную семантику, которая может присутствовать (что, если один и тот же адрес используется для работы и для личного использования? Что, если ниприменяется, можете ли вы просто заполнить поля
Other
? Что, если вы не знаете цель?) - Теперь вам нужно вручную проверить каждое поле, чтобы определить, какое из них пустое, а какоетривиальное количество дублирования в Java.Вы не можете использовать приятные функции, такие как расширенный цикл for, для применения одного и того же блока к каждому адресу электронной почты, и вы не можете просто подсчитать, сколько существует адресов
- Список свойств, которые
Person
теперь намного менее чист.Я полагаю, вы могли бы упаковать эти свойства в класс EmailContactDetails
или что-то в этом роде, но теперь у вас есть дополнительный уровень косвенности (более концептуальная сложность) без реальной выгоды.
Итак, если у человека есть возможно пустой, неограниченный список адресов электронной почты, что плохого в том, чтобы представлять его как список?