¿Deberían las funciones privadas cumplir los mismos estándares que las funciones públicas?

7

Si estoy creando funciones privadas de servicios públicos, ¿se deben mantener los mismos estándares rigurosos en términos de manejo de datos no válidos como funciones públicas?

Ejemplo: si estoy escribiendo un código para calcular la longitud de una lista enlazada, y la lista que se está pasando es una creada por mi propio código, en caso de que se verifique la existencia de bucles si mi código no crea listas vinculadas con bucles en el 1er lugar?

    
pregunta user87166 14.02.2015 - 16:08

5 respuestas

9

Naturalmente, los métodos privados tienen tanto que ganar como los métodos públicos, desde verificar para asegurarse de que cada bit de su entrada sea correcto. En general, ningún programador se estaría preguntando si más cheques son mejores que menos cheques (¡duh!) Si no fuera por problemas de rendimiento.

Ahora, cuando se trata de verificar si hay cosas no válidas, hay dos tipos de comprobaciones que puedes realizar:

  • Controles de tiempo de producción, (en resumen, controles de tiempo de ejecución ) que ocurren tanto en el desarrollo como en los entornos de producción. (Por ahí en el campo.)

  • Afirmaciones de solo tiempo de desarrollo, (en resumen, assertions ) que ocurren solo en entornos de desarrollo y se omiten en entornos de producción.

Las afirmaciones tienen la característica alucinante útil de no incurrir en ninguna penalización de rendimiento en los entornos de producción, por lo que se pueden utilizar de manera muy liberal. Continúa y afirma todo lo que puedas, no afecta el rendimiento. Por el contrario, afirmar que todo es bueno para la robustez, es bueno para la depuración, es bueno para la documentación, es bueno para mantener baja la complejidad del estado de su programa; En definitiva, es lo mejor desde el pan rebanado. Entonces:

  

La pregunta que siempre deberías estar haciendo

     

no es "¿debería afirmar esto?"

     

pero "¿hay algo que haya olvidado afirmar?"

Entonces, en un sistema bien diseñado, tanto los métodos privados como los públicos comprueban todo lo que hay para verificar, y la única diferencia es la siguiente:

  • Todos (bueno, casi todos) de las verificaciones realizadas por métodos privados son aseveraciones.

  • Muchas de las verificaciones realizadas por métodos públicos son verificaciones en tiempo de ejecución, ( no aseveraciones), si la interfaz pública del objeto así lo exige. En general, estas comprobaciones son para cosas que posiblemente ocurran en el uso normal y no son necesariamente errores.

Por ejemplo, si está codificando una clase File , el error de abrir el archivo generalmente no es un error, por lo que se debe verificar y generar una excepción incluso en producción. Por otro lado, si alguien pasa su método de apertura de archivo público a null filename, es un error en el código de la persona que llama, por lo que la comprobación de un nombre de archivo nulo puede ser una aserción.

Y, por lo general, cada cosa que se verifica con un chequeo de tiempo de ejecución en un método público también puede ser verificada nuevamente con un método privado, pero esta vez con una aserción, ya que todas las entradas deben tener ya ha sido validado por los métodos públicos, por lo que cualquier cosa mala que llegue a un método privado significa que tienes un error en el código tu .

Por lo tanto, en general:

  • Nada debería ir sin marcar, ya sea en forma pública o privada.

  • Las aserciones son gratuitas, así que úselas generosamente.

RENUNCIA DE RESPONSABILIDAD: ya que esta es una pregunta de la entrevista, tenga en cuenta que lo anterior puede y no ser lo que el entrevistador quisiera escuchar de usted. En tales casos, es mejor prefijar su respuesta con un descargo de responsabilidad como "Bueno, por supuesto, seguiría cualquier disciplina que se use generalmente en la casa, pero si dependiera completamente de mí, entonces ..."

    
respondido por el Mike Nakis 14.02.2015 - 17:15
4

SI. Los métodos privados deben mantenerse con los mismos estándares que los públicos.

Recuerde que hay una curva de campana.

Recuerde que aproximadamente el 50% de los programadores están por debajo del promedio. Por definición.

Suponga que NO será la única persona que haya trabajado en su código.

Suponga que al menos una de las personas que trabajan en su código será alguien a quien no se le debe permitir el acceso incluso a Dartmouth BASIC en una minicomputadora independiente.

Ahora, ¿estás STILL seguro de que nunca habrá ningún bucle en tus listas?

No lo creía.

    
respondido por el John R. Strohm 14.02.2015 - 17:16
3

No estaré de acuerdo con las otras respuestas y diré no . La verificación de los comentarios es mucho más importante en los métodos públicos que en los privados.

Especialmente si escribe un componente para reutilizarlo, no puede hacer ninguna suposiciones acerca de qué valores se pasan a los métodos públicos, excepto lo que garantiza el sistema de tipos.

Para los métodos privados es una cuestión diferente, ya que puede ver fácilmente en cualquier lugar que se llame el método y con qué argumentos, al menos si su clase tiene un tamaño razonable. Si nunca asigna nulo a una referencia de objeto, por ejemplo, no necesita verificar el nulo en un método privado. En un método público no puedes hacer tales suposiciones. Su ejemplo donde sabe que nunca crea ciclos en una lista vinculada es el mismo.

Por supuesto, siempre existe el riesgo de que alguien modifique otro método en la misma clase para romper las suposiciones, pero nuevamente, si tienes monos locos que cambian el código al azar, también corres el riesgo de que eliminen los controles de verificación de todos modos. Las pruebas unitarias son el enfoque correcto para verificar la integridad de una clase y protegerse contra los cambios que introducen errores.

En teoría, sería bueno si todos los métodos verificaran todas las entradas. Pero la introducción de la verificación también tiene costo. Por ejemplo, una simple refactorización del método de extracción requerirá que copie la verificación de entrada de pegado del método host, introduciendo el peso del código sin ningún beneficio claro.

    
respondido por el JacquesB 11.06.2015 - 16:32
2

Sí.

Una función interna privada es llamada por alguna otra función (o es código muerto ).

Si bien una función privada no forma parte de una interfaz pública para una clase, espacio de nombres o módulo, aún puede producir trabajo útil para funciones que son parte de la interfaz pública. Si bien no se expone directamente, contribuye a la interfaz pública de forma transitiva.

Las funciones privadas deben probarse, documentarse y codificarse con los mismos estándares que las funciones públicas. El único estándar en el que estaría laxa es la documentación: debería haber una nota rápida sobre lo que hace la función, antes y después de las condiciones, pero no es necesario entrar en tantos detalles como con la documentación pública, ya que una función privada / interna sí lo hace. No es necesario que lo entiendan los desarrolladores que están fuera de tu equipo.

    
respondido por el user22815 14.02.2015 - 18:25
1

Escriba la cantidad mínima de código para hacer el trabajo correctamente. En su ejemplo, diría que no se moleste, si no hay forma (sin modificaciones de código) de que haga bucles, entonces no se moleste en explicarlo. Terminará escribiendo menos código que puede ampliar más adelante, en lugar de demasiado código que podría llegar a confundir más adelante.

    
respondido por el Elliot Blackburn 14.02.2015 - 16:31

Lea otras preguntas en las etiquetas