No hay ninguna solución que funcione en todos los casos, muéstrenos el código.
El problema es que cuando pones el código en una función y cambias una pequeña parte del comportamiento en algún lugar dentro, aumentas la complejidad del código, y a veces es mejor mantener un código duplicado que eso.
Casi el mismo argumento funciona para la herencia. Puede rellenar fácilmente el código común en una clase ancestral común, pero si comienza a utilizar de forma rutinaria la herencia como una herramienta de reutilización de código, su diseño puede caer en un mundo de dolor. La herencia significa que el código en una pieza de código puede afectar el comportamiento en otras partes del código y, antes de que te des cuenta, tendrás una bola de código entrelazada que es casi imposible de cambiar sin romper.
Por lo general, es mejor cuando puede extraer o abstraer un significativo parte común del código de esas tres funciones. Algo que tiene sentido, como un patrón de alto nivel, en lugar de solo unas pocas líneas comunes que no hacen un trabajo coherente. Una regla simple que puede ayudarlo es nombrar el código extraído: ¿existe una forma natural y obvia de nombrar el fragmento? ¿Obviamente encaja en una de tus clases? Si lo hace, podría ser una buena solución. Si tiene dificultades para nombrarlo y podría ir a cualquier lugar, es posible que desee pensar un poco más.
(I sustituido "reutilización" => "duplicación", ya que parecía adaptarse a su significado más claramente) –
"¿Debo colocarlo todo en un método y usar un interruptor y una enumeración para las diferentes funciones al final?" Por favor no hagas esto! – SingleNegationElimination
No obtendrá una respuesta útil a esta pregunta, intente publicar una consulta que contenga el código de los 3 métodos, y es posible que las personas puedan ayudarlo. No hay una solución para el código de refactorización. –