Descomposición en java, ¿cuándo es suficiente?

Question

Soy un estudiante de informática de primer año. Actualmente estamos programando en Java y a menudo trato de descomponer mi programa en métodos bien nombrados para que mi lógica de método principal pueda leer lo más parecido posible al pseudocódigo.

El problema que encuentro es que a menudo termino escribiendo tantos pequeños métodos privados que siento que podría estar exagerando. ¿Hay alguna buena regla empírica o consideraciones estilísticas que se tengan en cuenta a la hora de decidir si se debe descomponer un problema aún más?

Answer 1

La mayoría de los nuevos desarrolladores hacen lo contrario: grandes funciones que tienen muchas responsabilidades. ¡Tu situación es infinitamente preferible a esto!

¡Hay muy poco inconveniente en la creación de muchos métodos pequeños y muchos aspectos positivos!

métodos cortas son:

• más fáciles de reutilizar
• fácil poner a prueba
• más fácil de leer y entender
• más fácil de depurar

Teniendo en cuenta esto, sugeriría que reestructura sin piedad la duplicación en pequeños métodos. Su IDE le dará un método de extracción de refactorización para hacerlo más rápido.

También creo que su objetivo de aspring a un tipo de pseudo código legible es, en general, uno bueno. Gran parte del código que ve no se escribirá así, pero realmente puede ayudar a la legibilidad y la noción de que "el código es documentación".

Algunas personas hablarán sobre la sobrecarga de rendimiento de las llamadas a métodos, pero solo en casos muy raros sería una preocupación para usted.

Edición - Otros carteles han mencionado Principio de Responsabilidad Individual. Aunque esta es una buena guía, personalmente creo que va más allá de esto. Incluso algún fragmento de código que tenga una responsabilidad bien definida podría descomponerse para su reutilización y legibilidad.

Answer 2

Mi filosofía es dividir el código en unidades de trabajo únicas atómicas y lógicas. Algo a lo que normalmente puedo dar un nombre, y luego pongo ese trabajo en un método y le doy ese nombre.

Answer 3

Creo que la parte más importante del código de ruptura es Single Responsibility Principle (SRP). Cada objeto debe tener una responsabilidad única, y esa responsabilidad debe estar completamente encapsulada por la clase

Answer 4

La regla de oro es Single Responsibility Principle. Cada unidad de código debe ser responsable de exactamente una cosa. Eso se aplica tanto a los métodos como a las clases. Si puede poner un nombre simple y conciso para cada uno de sus muchos métodos privados es para, entonces está bien. Si solo puede describirlo como "parte de" una operación más grande, entonces probablemente no sea un método diferente.

Pero por su pregunta, parece que ya lo está haciendo bien.

Answer 5

Mi regla general es que si una función no cabe en una sola pantalla (piense en una antigua terminal de 24 líneas por 80 columnas), es mejor que haya una buena razón. Algunas veces hayDebes tener en cuenta que, en general, cualquiera que lea tu función debe comprender todo. Cuando es largo, eso es más difícil de hacer.

Dicho esto, dos o tres funciones de línea no agregan mucho. A menudo son DEMASIADOS fáciles de entender por sí solos, y el nombre que les dé no transmitirá tanta información como el código en sí cuando está integrado en una función más larga.

Siempre hay excepciones. No hay ningún camino CORRECTO. Tu trabajo mejorará con la experiencia.