Наследование и инкапсуляция классов набора в Java

Я бы создал специальный объект для хранения этой информации. Вы создаете объект менеджер , а не простую коллекцию.

Я не стал бы наследовать его от Map или другого хорошо известного класса коллекции, поскольку семантика того, как вы храните эту информацию, может измениться в будущем.

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

Ваш Класс клиент / диспетчер соединений - это больше, чем просто контейнер. Он может хранить метаданные (например, когда была установлена ​​эта связь). Он может выполнять поиск соединений по информации о клиенте (при необходимости). Он может обрабатывать дубликаты так, как вам нужно, а не как их обрабатывает базовый класс коллекции и т. Д. И т. Д. Вы можете легко включить отладку / ведение журнала / мониторинг производительности, чтобы легко понять, что происходит.

Почему бы не использовать custId + "#" + srvurl в качестве ключа в простой Map ?

Или использовать Tuple или класс Pair в качестве ключа, который содержит два идентификатора и реализует hashCode () и equals () - «самое чистое» объектно-ориентированное решение.

Почему вы поддерживаете отношения между объектами за пределами этих объектов.

Я бы предложил примерно следующее:

public class Customer 
{
  public List<LastConnection> getConnectionHistory() 
  {
    ... 
  }

  public List<LastConnection> getConnectionHistory(Service service) 
  {
    ...
  }

  public List<LastConnection> getConnectionHistory(Date since) 
  {
    ...
  }
}

public class LastConnection
{
  public Date getConnectionTime() 
  {
    ...
  }

  public Service getService()
  {
    ...
  }
}

Затем вы передаете List методам, использующим эту информацию.

Вы можете создать класс, который реализует Map , и внутренне делегировать его карте контейнера:

class CustomerConnections implements Map<String,LastConnection> {
    private Map<String, LastConnection> customerConnections;

    @Override
    public LastConnection get(Object srvUrl) { 
        return customerConnections.get(srvUrl);
    }
    // all other needed operations;
}

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

РЕДАКТИРОВАТЬ : Как указано ниже, у этого есть обратная сторона, требующая реализации множества методов, которые не делают ничего, кроме делегирования базовой коллекции

Я думаю, вам также следует подумать о том, как будут использоваться коллекции и как получаются данные:

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

Как получить и сохранить данные? Если он хранится в базе данных, то, возможно, вы можете использовать SQL для выбора LastConnections по клиенту и / или услуге и / или месяцу, вместо того, чтобы самостоятельно поддерживать структуры данных (и просто возвращать простые списки или карты подключений или количество подключений. ). Или, может быть, вы не хотите запускать запрос для каждого запроса, поэтому вам нужно хранить всю структуру данных в памяти.

Инкапсуляция, как правило, хорошая вещь, особенно потому, что она может помочь вам придерживаться Закон Деметры - возможно, вы сможете передать некоторые операции, которые вы будете выполнять с коллекциями, обратно в класс AllConnections (который фактически является DAO). Это часто может помочь в модульном тестировании.

Кроме того, почему расширение HashMap считается здесь злом, учитывая, что вы хотите добавить только тривиальный вспомогательный метод? В вашем коде для AllConnections AllConnections всегда будет вести себя так же, как HashMap - он полиморфно заменяем. Конечно, вы потенциально можете использовать HashMap (а не TreeMap и т. Д.), Но это, вероятно, не имеет значения, поскольку он имеет те же общедоступные методы, что и Map. Однако, действительно ли вы действительно захотите это сделать, зависит от того, как вы собираетесь использовать коллекции - я просто не думаю, что вам следует автоматически сбрасывать со счетов наследование реализации, поскольку всегда плохо (это обычно так! )

class AllConnections extends HashMap<String, CustomerConnections> {
    public LastConnection get(String custId, String srvUrl) {
        return get(custId).get(srvUrl);
    }
}