Лучшая практика в отношении частного архиралиста и других подобных конструкций - PullRequest
Новая
       42

Лучшая практика в отношении частного архиралиста и других подобных конструкций

4 голосов
/ 23 августа 2010

У меня есть следующий класс, который я борюсь за то, как реализовать.Вопрос заключается в том, имеет ли смысл иметь частную коллекцию, в данном случае это член архива.Мне хорошо известно, что рекомендуется иметь методы получения и установки для любых членов класса, но в этом случае наличие метода получения и установки потребует повторной реализации (или, скорее, дублирования) большого количества функций ArrayList.

Пример класса: 

public class Email
{
    private ArrayList<String> To;
    private ArrayList<String> Cc;
    private ArrayList<String> Bcc;

    ...
}

Я предполагаю, что ответ на этот вопрос заключается в том, действительно ли я должен реализовывать методы получения и установки для этих массивов?Есть ли какой-то подход, о котором я не задумывался в отношении такого рода ситуаций?Простое решение для управления этими списками состоит в том, чтобы установить приватные модификаторы в public и проверить, что данные массива действительны при вызове методов, но так ли это?Может ли кто-нибудь указать мне направление других SO вопросов, шаблонов проектирования и т. Д., Которые я должен рассмотреть?

Ответы [ 3 ]

6 голосов
/ 23 августа 2010

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

Я не согласен. Выставляйте только то, что вам нужно! Попробуйте мыслить с точки зрения ADT (абстрактные типы данных). Другими словами, создайте слой абстракции из внутреннего ArrayLists. Любой, кто использует ваш класс, не должен знать, что вы внутренне используете ArrayLists. Если это не является абсолютно необходимым, вы не должны предоставлять получатель для вашего ArrayLists. Если вам кажется, что вам это нужно, подумайте о возврате List и использовании Collections.unmodifiableList() для предотвращения модификации через геттер.

5 голосов
/ 23 августа 2010

На самом деле в этом случае я думаю, что было бы лучше не предоставлять прямую комбинацию геттер / сеттер.

Я бы предпочел подойти к ней следующим образом:

  1. Изменить типна List<String> (рекомендуется использовать интерфейсы на полях.)
  2. Инициализировать пустые ArrayList s в конструкторе.
  3. Предоставить делегаты для add, remove, hasTo/Cc/Bcc*

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

2 голосов
/ 23 августа 2010

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

Это неверно.

Соответствующий совет «передового опыта» НЕ должен представлять состояние классов как поля.

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

  • Является ли состояние, в котором я раскрываю внутреннюю деталь реализации ADT, или ссылкой на отдельный объект данных?

  • Если я раскрываю детали внутренней реализации, как я могу предотвратить что-то зависящее от этого или (что еще хуже) изменить его потенциально разрушительными способами?

Хорошо реализованные методы получения и установки могут решить эти проблемы; например возвращая копии коллекций или неизменяемые оболочки и / или копируя аргументы коллекции. Но методы-оболочки могут делать то же самое, часто с меньшими накладными расходами времени выполнения.

Еще одна вещь, которую следует учитывать, - это наличие требований к производительности, которые заставляют отказаться от принципов «наилучшей практики» проектирования и намеренно сделать ADT «негерметичным».

...