Очікувана поведінка, коли запит на колекцію матиме нульові елементи

Скажімо, вам дано наступне ...

List<Thing> theThings = fubar.Things.All();

Якби нічого не повернути, чого б ти очікував, що повернеться фубар.

Редагувати: Дякую за думки. Я трохи зачекаю і прийму запис із більшою кількістю вікон.

Я погоджуюся з відповідями на даний момент, особливо тими, що пропонують порожню колекцію. Постачальник надав API з кількома дзвінками, подібними до наведеного вище. Продавець, який минулого року отримав 4,6 млн. Доларів доходу через свої API (API), BTW. Вони роблять те, з чим я принципово не згоден - вони викидають виняток.

З двох можливостей (тобто повернення nullабо повернення порожньої колекції) я б обрав повернення порожньої колекції, оскільки це дозволяє абоненту пропустити перевірку повернутого значення. Замість того, щоб писати це

List<Thing> theThings = fubar.Things.All();
if (theThings != null) {
    for (Thing t : theThings) {
        t.doSomething();
    }
}

вони зможуть написати це:

List<Thing> theThings = fubar.Things.All();
for (Thing t : theThings) {
    t.doSomething();
}

Цей другий фрагмент коду коротший і легший для читання, оскільки рівень гніздування нижчий на одиницю.

Я б очікував порожнього списку. theThingsбуде по- , як і раніше бути об'єктом, але theThings.Countі theThings.size()повернеться 0.

Такі проблеми дизайну вирішуються за допомогою моделі Null Object

... Замість використання нульової посилання, щоб передати відсутність об'єкта (наприклад, неіснуючого клієнта), використовується об’єкт, який реалізує очікуваний інтерфейс, але тіло методу якого порожнє. Перевага такого підходу перед робочою реалізацією за замовчуванням полягає в тому, що Null Object дуже передбачуваний і не має побічних ефектів: він нічого не робить.

Наприклад, функція може отримати список файлів у каталозі та виконати певні дії над кожним. У випадку порожнього каталогу однією відповіддю може бути викид виключення або повернення нульової посилання, а не списку. Таким чином, код, який очікує список, повинен переконатися, що він насправді має його, перш ніж продовжувати, що може ускладнити дизайн ...

Пропозиція, особливо застосовна у вашому випадку (повернення, Listколи немає Thing), є:

... Натомість, повертаючи нульовий об'єкт (тобто порожній список ), не потрібно перевіряти, що значення повернення насправді є списком. Функція виклику може просто повторити список як звичайний, фактично нічого не роблячи. Однак все ж можна перевірити, чи є поверненим значенням нульовий об'єкт (наприклад, порожній список) і реагувати по-різному за бажанням.

Вам слід, IMHO, повернути значення EMPTY. Я не знаю про C #, але в Java у нас є це:

  List list = Collections.EMPTY_LIST;
  Set set = Collections.EMPTY_SET;
  Map map = Collections.EMPTY_MAP;

  // For the type-safe 
  List<String> s = Collections.emptyList();
  Set<Long> l = Collections.emptySet();
  Map<Date> d = Collections.emptyMap();

http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Collections.html

Я б повернув порожню колекцію над поверненням нульового значення, тому що таким чином ви можете уникнути запису нульової перевірки в код виклику.

Два рішення вони означають різні речі.

Якщо річ, яку ви повертаєте, є лише нулем, ВИНАГО повертаєте порожню колекцію! Візьміть справу зі списком каталогів. Якщо в каталозі немає файлів, ви повернете порожню колекцію файлів.

З іншого боку, якщо каталог не існує, це не дуже доречно. "Я нічого не можу повернути" означає щось неодмінно інше. У такому випадку вам слід повернути нуль або викинути виняток залежно від ситуації, а не повертати порожню колекцію, як ніщо не було.