usar - Métodos de ayuda privada frente a los métodos públicos de utilidad estática en Java
static final java (4)
La calidad del código no se puede medir por el número de líneas. Si encuentra que el archivo de clase crece día a día, asegúrese de que su clase siga el Principio de Responsabilidad Individual.
Cuando su clase no sigue el principio, sepárelos en clases individuales y convierta las clases en un paquete.
De lo contrario, podría hacer que su clase base sea una clase abstracta y hacer que sus métodos de utilidad sean abstract . Tenga una clase infantil que amplíe la clase base que proporciona la implementación de métodos abstractos en la clase base.
Aquí hay una buena respuesta SO sobre cuándo podría hacer sus métodos como estáticos
Como dijo @Zack Jannsen,
"estático" suele ser valioso cuando sabes que algo no va a cambiar en cada instancia. Si este es el caso, realmente consideraría el "Principio de Responsabilidad Individual", que implica que una clase debería tener una responsabilidad y, por lo tanto, solo una razón para cambiar. Siento que uno debería considerar mover la función "ConvertMpgToKpl (doble mpg)", y métodos similares, a su propia clase. El objetivo de un objeto de automóvil es permitir la creación de instancias de los automóviles, no proporcionar una comparación entre ellos. Esos deben ser externos a la clase.
Aunque estático le permite acceder al método sin creación de objetos, recuerde siempre lo siguiente cuando intente hacer que el método sea estático.
- El método produce resultados consistentes basados en los argumentos de entrada
- Siempre necesita que el método esté en la memoria (es decir, necesita el método con bastante frecuencia). Podría ser mejor acceder a un método enorme al que se accedería solo unas pocas veces con la ayuda de la creación de objetos en lugar de acceder a él a través de
static - Los métodos de utilidad que se usan con bastante frecuencia se pueden hacer como
static
Tengo una clase de Java que se está volviendo larga. Cuando lo ejecuto a través de herramientas de calidad de código, me marcan por el número de líneas en la clase.
Esta es una clase de capa inferior, utilizada por capas superiores con @Autowired Spring''s . La clase tiene muchos métodos de instancia privados que no son estáticos. No usan ningún campo de instancia, trabajando solo en los parámetros del método.
¿Puedo mover estos métodos de forma segura como public static en alguna clase de utilidad separada? ¿Cuáles son los inconvenientes?
La división de métodos debe ser por propósito / aplicación / lógica (lo que usted quiera), no por propiedades técnicas.
Un código fuente largo probablemente se puede separar en varias clases de tamaño pequeño, cada una con su propio propósito / responsabilidad.
Pensamiento "equivocado" aquí.
No vuelves a trabajar tus clases porque las herramientas se quejan sobre esto o aquello.
Desea mejorar la calidad de su código fuente; y tales herramientas pueden ayudar a identificar "temas en los que vale la pena pensar". Tomas sus comentarios como una pista ; no como "orden".
Por lo tanto, no te preocupes por las "líneas de códigos" dentro de una clase. En cambio, te preocupan las responsabilidades que tiene esta clase. Significado: el recuento del número de línea no es un problema en sí mismo, pero sí lo son las violaciones del Principio de Responsabilidad Individual .
Por lo tanto: das un paso atrás y compruebas qué está haciendo exactamente tu clase. Y cuando claramente está haciendo más de una cosa, ¡extraes esos aspectos en otras clases!
Significado: si realmente encuentras que todo este código "pertenece" a la responsabilidad de esa clase; luego mantenlo allí. No empieces a poner detalles de implementación interna en clases de ayuda no relacionadas; solo porque alguna herramienta te advierte sobre el número de líneas.
Por otro lado, convertir los métodos privados en algo que sea estático / protegido de paquetes le permitiría probar esos métodos unitarios. Lo cual podría ser una ventaja. Pero como se dijo: mientras hablamos de los detalles de la implementación , deben mantenerse en privado; y no deberían ser probados en unidades de todos modos.
Código de historia larga: conozca y comprenda de qué se trata el "código limpio"; y tratar de seguir las ideas que se describen allí.
Utilizo constantemente clases de utilidad que contienen métodos estáticos y me resulta muy conveniente. Si los métodos son realmente para una sola clase, puede colocar su clase de utilidad como clase privada estática dentro de su clase original. Pero descubrí que en muchos casos los métodos generales de utilidad estática pueden ser utilizados por varias clases, por lo que en este caso crearía una clase de utilidad separada con un conjunto de métodos estáticos que podrían ser utilizados por varias clases.
Además, estoy totalmente de acuerdo con la respuesta de GhostCat en términos de una manera general de pensar. En cuanto al tamaño de una clase, podría ser una preocupación, pero por lo general no me preocupo tanto. Lo que realmente busco es el tamaño de tus métodos. Me gusta que los métodos sean cortos y autoexplicativos, comenzando con su nombre y los nombres y el orden de los parámetros, y con la lógica. Si hay una gran parte de la lógica interna, extráigala en un método diferente. Eso hace que el código sea mucho mejor legible y mantenible.