estilo de codificación de parámetros del método privado OOP

7

Después de codificar durante muchos años como programador en solitario, he llegado a la conclusión de que la mayoría de las veces hay muchos beneficios para escribir funciones miembro privadas con todas las variables miembro utilizadas en la lista de parámetros, especialmente en la etapa de desarrollo.

Esto me permite verificar de un vistazo qué variables miembro se utilizan y también me permite proporcionar otros valores para las pruebas y la depuración. Además, un cambio en el código al eliminar una variable miembro en particular puede romper muchas funciones. Sin embargo, en este caso, la función privada permanece aislada, aún puedo llamarlo usando otros valores sin arreglar la función.

¿Es una mala idea después de todo, especialmente en un entorno de equipo? ¿Es como redundante o confuso, o hay mejores maneras?

    
pregunta Jake 29.11.2011 - 18:49

5 respuestas

8

allow me to check at one look what member variables are used

El uso de la firma de un método únicamente para identificar a los miembros de una clase es un estilo de programación básico que no es OO. OOP se trata de relaciones y abstracciones de nivel superior. Si tiene problemas para rastrear a un número ridículo de miembros, debe revisar sus clases de inmediato para asegurarse de que tengan un propósito único y fácilmente identificable. Esto parece que estás construyendo objetos de dios .

Also, a change in code by removing a particular member variable can break **many** functions.

Un gran indicador de acoplamiento apretado. Desacoplar sus clases. Mire la inyección de dependencia .

allow me to supply other values for tests and debugging.

No está claro el significado aquí. Sobre todo porque sigues diciendo

In this case however, the private function remains isolated am I can still call it using other values without fixing the function.

En general, las funciones privadas hacen que el código sea más difícil de probar (unidad) y no es más fácil. ¿Está familiarizado con Mocking ? ¿Está realizando pruebas con pruebas unitarias , algún tipo de cerveza casera u otra?

    
respondido por el P.Brian.Mackey 29.11.2011 - 19:35
3
  

¿Es una mala idea después de todo, especialmente en un entorno de equipo?

Yo diría que es al menos una práctica cuestionable que podría causar problemas, particularmente en un entorno de equipo. Habiendo trabajado de esta manera durante algún tiempo, es posible que haya desarrollado hábitos y comprensión que eviten los posibles problemas, pero es probable que los miembros del equipo no entiendan sus reglas no escritas.

En particular, parece que esencialmente estás practicando la programación de procedimientos en un entorno orientado a objetos. El punto de los objetos es que contienen tanto los datos como las operaciones en esos datos. Si le dice a una vista que dibuje (), por ejemplo, no necesita decirle a qué dibujar, debe dibujarse a sí mismo. Si tiene que decirle qué dibujar, no está aprovechando el poder de la POO.

Un peligro de su enfoque es que sus métodos no operan en los miembros del objeto, sino en los parámetros. Si pasa esos parámetros por valor, cualquier cambio en ellos no se reflejará en las variables miembro correspondientes. Puede resolver ese problema pasando por referencia, pero en ese caso su código podría cambiar las variables de miembro si eso es lo que pasa, pero no es obvio que eso es lo que está sucediendo. Peor aún, existe la posibilidad muy real de que la persona que llama pase algo distinto a una variable miembro, lo que realmente cambia el significado de lo que hace el método.

  

Es como redundante o confuso

  • Redundante: definitivamente.
  • Confuso: aparentemente no para ti, pero seguramente para otros.
  

¿hay mejores maneras?

Use variables o propiedades de miembro en lugar de parámetros en métodos que están destinados a operar con datos almacenados dentro del objeto. Use parámetros para información que es externa al objeto.

Si tiene problemas para discernir qué miembros usa un método determinado, intente lo siguiente:

  • Coloque un comentario cerca del principio del método que explica lo que hace el método, enumera los miembros afectados y tal vez describa cualquier resultado.

  • Simplifica tus métodos. Estoy a favor de los comentarios apropiados, pero el código es mucho mejor cuando puede escanear el código rápidamente y tener una idea bastante clara de lo que está pasando.

  • Deja de preocuparte por eso. Un método debe usar cualquier información interna que necesite para hacer su trabajo. El código fuera del método debería estar más preocupado por qué hace el método, no cómo lo hace.

respondido por el Caleb 29.11.2011 - 19:48
2

Si desea tener la función en clase (privada o no, no importa), use miembros como miembros, para que sea una operación de la clase. De lo contrario, en principio, no pertenece a la clase. Sácalo de la clase y llámalo con muchos parámetros. Si cree que es un ayudante que "debe funcionar sin importar cómo se refactorice la clase".

    
respondido por el herby 29.11.2011 - 19:04
1

En general, no es una buena idea otorgar a los métodos (o cualquier otra cosa) acceso a la información que no necesita. Tener una gran lista de parámetros significa analizar más de ellos cuando usted u otra persona necesita encontrar algo. Si están definitivamente relacionados y son necesarios, tal vez deberías considerar crear un objeto para pasar, o pasar el objeto del que provienen.

En cuanto a las pruebas, debes tratar de mantener las pruebas separadas de tu lógica real.

    
respondido por el MaxWell 29.11.2011 - 19:05
0

Como otros han señalado, lo que usted describe parece ir en contra de la idea de los objetos, para una explicación detallada de esto recomendaría el libro "Código limpio" de Robert C. Martins, especialmente el capítulo sobre métodos.

Es relevante porque es una descripción completa y práctica de cómo escribir código limpio orientado a objetos. El capítulo al que se hace referencia, en particular, analiza las listas de parámetros de los métodos con respecto a:

  • su longitud,
  • la responsabilidad del método,
  • la responsabilidad de la clase,
  • y las variables de instancia.

Ese capítulo contiene una respuesta larga a la pregunta. La respuesta corta es tener pocos parámetros, favorecer las variables de instancia y mantener las clases bien enfocadas, es decir, de acuerdo con el Principio de Responsabilidad Única .

    
respondido por el Christian Horsdal 29.11.2011 - 19:45

Lea otras preguntas en las etiquetas