Comportamiento esperado cuando una solicitud de una colección tendrá cero elementos

Digamos que te dan lo siguiente ...

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

Si no hubiera nada que devolver, ¿qué esperarías que volviera fubar.Things.All ()?

Editar: Gracias por las opiniones. Esperaré un poco y aceptaré la entrada con más ups.

Estoy de acuerdo con las respuestas hasta ahora, particularmente aquellas que sugieren una colección vacía. Un proveedor proporcionó una API con varias llamadas similares al ejemplo anterior. Un proveedor que hizo $ 4.6 millones en ingresos a través de sus API el año pasado, por cierto. Hacen algo con lo que estoy básicamente en desacuerdo: lanzan una excepción.

De las dos posibilidades (es decir, devolver una nullo una colección vacía) elegiría devolver una colección vacía, ya que permite que la persona que llama omita una comprobación del valor devuelto. En lugar de escribir esto

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

ellos podrían escribir esto:

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

Este segundo fragmento de código es más corto y más fácil de leer, porque el nivel de anidación es más bajo en uno.

Esperaría una lista vacía. theThingsseguiría siendo un objeto, pero theThings.Counto theThings.size()volvería 0.

Problemas de diseño como ese son abordados por el patrón de objeto nulo

... En lugar de usar una referencia nula para transmitir la ausencia de un objeto (por ejemplo, un cliente inexistente), uno usa un objeto que implementa la interfaz esperada, pero cuyo cuerpo de método está vacío. La ventaja de este enfoque sobre una implementación predeterminada que funciona es que un objeto nulo es muy predecible y no tiene efectos secundarios: no hace nada.

Por ejemplo, una función puede recuperar una lista de archivos en un directorio y realizar alguna acción en cada uno. En el caso de un directorio vacío, una respuesta puede ser lanzar una excepción o devolver una referencia nula en lugar de una lista. Por lo tanto, el código que espera una lista debe verificar que de hecho tenga una antes de continuar, lo que puede complicar el diseño ...

La sugerencia particularmente aplicable en su caso (regresar Listcuando no hay Things) es:

... Al devolver un objeto nulo (es decir, una lista vacía ) en su lugar, no hay necesidad de verificar que el valor devuelto sea de hecho una lista. La función de llamada puede simplemente iterar la lista como normal, sin hacer nada. Sin embargo, todavía es posible verificar si el valor de retorno es un objeto nulo (por ejemplo, una lista vacía) y reaccionar de manera diferente si se desea.

En mi humilde opinión, debe devolver un valor VACÍO. No sé acerca de C #, pero en Java tenemos esto:

  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

Devolvería una colección vacía sobre la devolución de un valor nulo porque de esa manera puede evitar escribir una verificación nula en el código de llamada.

Las dos soluciones significan cosas diferentes.

Si solo hay cero de lo que está devolviendo, ¡SIEMPRE devuelve una colección vacía! Tome el caso de una lista de directorio. Si no hay archivos en el directorio, devuelve una colección de archivos vacía.

Por otro lado, si el directorio no existe, eso no es realmente apropiado. "No puedo devolver nada" significa algo completamente diferente. En ese caso, debe devolver nulo o lanzar una excepción según la situación, no solo devuelva una colección vacía como si nada estuviera mal.