Así que tengo una lista de objetos que quiero parte o entero para ser procesados, y me gustaría registrar esos objetos que se han procesado.
considerar un ejemplo ficticio:
List<ClassInSchool> classes;
classes
.stream()
.filter(verifyClassInSixthGrade())
.filter(classHasNoClassRoom())
.peek(classInSchool -> log.debug("Processing classroom {} in sixth grade without classroom.", classInSchool)
.forEach(findMatchingClassRoomIfAvailable());
Sería el uso de .peek () en este caso ser considerado como uso no intencionado de la API?
Para explicar con más detalle, en esta cuestión la conclusión clave es: "No utilice la API de una manera no intencionada, incluso si logra su objetivo inmediato." Mi pregunta es si o no todos los usos de corto PEEK de depuración de la corriente hasta que haya verificado el funcionamiento de la cadena enteros como diseñado y eliminado el .peek () de nuevo, es el uso accidental. Por lo tanto si se utiliza como un medio para registrar todos los objetos realmente transformada por la corriente se considera un uso no previsto.
La documentación de laspeek describe como el intento
Este método existe principalmente para la depuración de apoyo, en la que desea ver los elementos a medida que fluyen más allá de un cierto punto en una tubería.
Una expresión de la forma .peek(classInSchool -> log.debug("Processing classroom {} in sixth grade without classroom.", classInSchool)cumple esta intención, ya que se trata de informes el procesamiento de un elemento. No importa si se utiliza el marco de registro o simplemente imprimir declaraciones, al igual que en el ejemplo de la documentación, .peek(e -> System.out.println("Filtered value: " + e)). En cualquiera de los casos, los asuntos intención, no el enfoque técnico. Si alguien utiliza peekcon la intención de imprimir todos los elementos , que sería un error, incluso si se utiliza el mismo enfoque técnico como el ejemplo de la documentación ( System.out.println).
La documentación no obliga a que hay que distinguir entre el entorno de producción o entorno de depuración, para eliminar el peekuso de la primera. En realidad, su uso podría incluso cumplir con ese, como el marco de registro le permite silenciar que la acción a través del nivel de registro configurable.
Me gustaría volver a sugerir que tener en cuenta que para algunas tuberías, la inserción de una peekoperación puede insertar más sobrecarga que la operación real (o dificultar optimizaciones de ciclo de la JVM a tal grado). Pero si usted no experimenta problemas de rendimiento, es posible seguir el viejo consejo de no tratar de optimizar menos que tenga una razón real ...