Cómo/cuándo escribir métodos reutilizables en OOP

Question

A menudo me encuentro en una situación en la que estoy repitiendo dos o tres líneas de código en un método varias veces y luego pienso si debería poner eso en un método separado para evitar la duplicación de código . Pero luego, cuando muevo esas líneas fuera del método, encuentro que el método recién creado no es reutilizable, se usó solo una vez o requiere una sobrecarga para ser útil para otro método.

Mi pregunta es qué tipo de patrones deberíamos estar buscando que indiquen que debemos crear un nuevo método. Agradezco su respuesta.

Answer 1

Como regla general, siempre piense en esas situaciones como entidades funcionales. Si un fragmento de código realiza una tarea funcionalmente (conversión de cadena compleja, análisis sintáctico, etc.), debe escribir un método reutilizable. Si esa función es específica para un tipo determinado, escriba extension method.

Answer 2

Puede crear una variable local dentro de su función de tipo Action<> o Func<> y asignarle el fragmento de código. Luego puede usarlo en todas partes dentro de su función sin contaminar su clase con demasiadas pequeñas funciones auxiliares.

Answer 3

Si las líneas de código que pretende mover a otro método realizan un conjunto específico de acciones (como leer un archivo, calcular un valor, etc.), entonces lo mejor es refactorizar a otro método de ayuda. De nuevo, haga esto solo si se llama al método de ayuda en varios lugares de su código o si el método de la persona que llama es demasiado largo (la definición de too long depende del desarrollador).

preguntas similares

• How do programmers practice code reuse
• What techniques do you use to maximise code reuse?
• Code Reusability: Is it worth it?
• Coding Priorities: Performance, Maintainability, Reusability?

Answer 4

Me gustaría empezar por leer sobre el principio DRY (NO Repetir Suyo elfo) con suerte le dará una buena respuesta para su pregunta, que es una pregunta que todos los desarrolladores deberían hacerse por sí mismos, ¡gran pregunta!

Ver Don't repeat yourself

yo quería dejarlo en seco, ya que es un concepto tan simple pero potente que necesitará un poco de lectura y mucha práctica para conseguir un buen complemento. Pero permítame tratar de responder directamente a su pregunta (IMHO),

Si no puede darle a su método un nombre que refleje exactamente lo que está haciendo su método, divídalo en pedazos que tengan significado.

Te encontrarás Secando el código con facilidad, aparecerán piezas reutilizables, y probablemente nunca te encuentres repitiendo el código.

Haría esto incluso si eso significara tener métodos con solo un par de líneas de código.

Siguiendo esta práctica dará sentido a su código, que sea legible y predecible, y sin duda más reutilizable

Answer 5

No ponga demasiada funcionalidad en un método/clase. Intenta seguir el single responsibility principle. Tomará algún tiempo familiarizarse con ese enfoque. Pero una vez que alcanzas ese nivel, notarás que todo está hecho solo. Antes de codificar, intente preguntarse qué unidades funcionales incluye su concepto.

Por ejemplo, desea desarrollar una aplicación que pueda indexar el contenido de los archivos pdf. Es sólo ficticia, pero a primera vista, podría identificar al menos tres componentes:

1. PdfParser - esto le proporciona el contenido de un PDF
2. paso a paso - obtiene el aporte de analizador y el recuento de palabras significativas
3. Repositorio: es para la persistencia; esto podría hacerse genérico; tan solo diga repository.Get<IndexData>(filename) o algo

También debe intentar codificar contra las interfaces. Especialmente cuando se trata de algún tipo de UI. Por ejemplo, está desarrollando un cliente de chat con WinForms. Si sigue el patrón MVC/MVVM, puede fácilmente (es decir, más fácil que codificar en un objeto Form) usar su lógica original con una versión WPF del cliente.

Answer 6

Si construye un método para la reutilización, pero no lo usa en más de un lugar, entonces la reutilización de su método no está realmente verificada. Extraiga los métodos cuando tenga sentido, y rediseñe esos métodos para volver a utilizarlos cuando realmente tenga la oportunidad de volver a utilizar el código.