Какой самый объектно-ориентированный способ создания адресной книги? - PullRequest
2 голосов
/ 22 марта 2011

Я спрашиваю себя, как спроектировать объектно-ориентированную адресную книгу на Java.

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

Один из способов реализовать это - дать каждому контакту ArrayList для каждого типа. Но должно быть лучшее и более объектно-ориентированное решение. Что это?

Ответы [ 4 ]

2 голосов
/ 22 марта 2011

Самое большое предложение ООП, которое я могу вам дать, - это создать класс для каждого элемента / части информации.Например:

public abstract class ContactInfo { /* ... */ }

public class Address extends ContactInfo { /* ... */ }

public class PhoneNumber extends ContactInfo { /* ... */ }

public class EmailAddress extends ContactInfo { /* ... */ }

public class Contact {
    private String name;
    private Set<ContactInfo> info;
    // ...
}

и, наконец,

public class AddressBook {
    List<Contact> contacts;
    // ...
}

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

2 голосов
/ 22 марта 2011

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

1 голос
/ 22 марта 2011

Я не думаю, что это особенно не-объектно-ориентированный.Если ваш домен таков, что Person может иметь ноль или более EmailAddress es, то вы почти точно описали ситуацию с использованием списка.

Единственный альтернативный подход, о котором я могу подумать, этоиметь такие поля, как

WorkEmail
PersonalEmail
OtherEmail1
OtherEmail2
OtherEmail3

, но, на мой взгляд, это хуже, потому что:

  • Вы просто не можете поддерживать более пяти адресов электронной почты (ну, вы можете добавить больше полей,но это усиливает боль в последних точках и все еще накладывает некоторый конечный предел.)
  • Вы подразумеваете некоторую дополнительную семантику, которая может присутствовать (что, если один и тот же адрес используется для работы и для личного использования? Что, если ниприменяется, можете ли вы просто заполнить поля Other? Что, если вы не знаете цель?)
  • Теперь вам нужно вручную проверить каждое поле, чтобы определить, какое из них пустое, а какоетривиальное количество дублирования в Java.Вы не можете использовать приятные функции, такие как расширенный цикл for, для применения одного и того же блока к каждому адресу электронной почты, и вы не можете просто подсчитать, сколько существует адресов
  • Список свойств, которые Personтеперь намного менее чист.Я полагаю, вы могли бы упаковать эти свойства в класс EmailContactDetails или что-то в этом роде, но теперь у вас есть дополнительный уровень косвенности (более концептуальная сложность) без реальной выгоды.

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

0 голосов
/ 22 марта 2011

Вы также можете использовать Карта , а затем получать конкретные значения, например, с помощью myMap.get("emailAdress1") или выполнять итерацию по всей карте, как вы бы сделали со списком с помощью myMap.entrySet().

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...