Каков идеальный способ определения единственного и множественного числа в API хранилища? - PullRequest
Новая
       30

Каков идеальный способ определения единственного и множественного числа в API хранилища?

6 голосов
/ 18 октября 2011

В моем приложении есть слой внутренней памяти, который обрабатывает Foo объекты. Во время операций Get уровень данных имеет существенные преимущества для кластеризации, но я только на самом деле делаю множественные получения примерно в 10% случаев. Вот несколько подходов, которые я рассмотрел:

Подход A: 

interface FooStorage {
  Foo getFoo(String name);
  List<Foo> getFoos(List<String> names);
}

Подход B: 

interface FooStorage {
  List<Foo> getFoos(List<String> names);
}
class StorageUtility {
  public static <T> T firstOrNull(List<T> data) { ... }
}

Подход C: 

interface FooStorage {
  List<Foo> getFoos(String... names);
}
class StorageUtility {
  public static <T> T firstOrNull(List<T> data) { ... }
}

Недостатком подхода А является большая поверхность, которую мне нужно поддерживать.
Недостаток подхода B заключается в том, что потребитель строит список, когда 90% времени он мне не нужен. Недостатком подхода C является издержка копирования списка в массив в 10% случаев.

Есть ли канонический правильный способ сделать это?

1 Ответ

1 голос
/ 19 октября 2011

В такой ситуации я бы предпочел использовать следующую конструкцию: 

Foo getFoo(String name) {
    return firstOrNull(getFoos(name));
}
List<Foo> getFoos(String ... names) {
    return getFoos(Arrays.asList(names));
}
List<Foo> getFoos(List<String> names) {
    ....
}

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

Я бы сказал, что более важно сохранить читабельный код потребителя (избегайте создания списков просто для того, чтобы защитить API), чем сохранить несколько строк кода в интерфейсе / реализации системы хранения.

...