Cuando utilizar metodos estaticos ???

[jkintero]

Hola a todos estoy realizando una clase que contiene todos los querys que utilizare en un proyecto, pero mi duda es saber si conviene que esta clase contenga todos los metodos estaticos o que se tenga que instanciar cada vez que se utilice la clase???

Quisiera saber cuando es conveniente utilizar las clases con funciones estaticas, considerando el perfomance, la reusabilidad, etc..

Les agradeceria su ayuda gracias....

[chuidiang]

Por eficiencia, si no necesitas en tu programa que haya varias instancias de esa clase, es mejor hacer los métodos estáticos.

Por reusabilidad, es mejor no hacer los métodos estáticos, sino normales. La clase debería además implementar una interface con los métodos públicos y el que use esa clase debería hacerlo a través de la interface. De esta forma es más fácil en futuros proyectos cambiar esa clase por otra sin tener que tocar todo el código por donde se use.

Se bueno.

[FiruzzZ]

Iniciado por chuidiang

La clase debería además implementar una interface con los métodos públicos y el que use esa clase debería hacerlo a través de la interface.

Cual es el sentido de implementar una interface?, si hay q redefinir TODOS los methods. (y por lo que dice kintero "el ya tiene todas las query que va utilizar").

y ..
.. con los métodos públicos.. (como si se pudiera de otra forma)
..en Java estás forzado a declarar de alcance (modificador de acceso) public los methods de una interface

jKintero, si las query de tu proyecto son así de estáticas que ya las tenés todas definidas, definitivamente deberías usar una public static Class

[mrrobot]

El sentido es que si te llevas una clase a otro proyecto, puedes coger las interfaces de las que depende para implementarlas de nuevo en las clases de este sin tener que modificar tu clase, por eso se dice que es reutilizable y que está desacoplada.
Las interfaces deben tener todos sus métodos públicos, pero chidiliang se refiere a los métodos públicos de la clase, que son los únicos que se verán en la interfaz.

saludos

[Kritik]

Un método estático es aquel que no se puede instanciar.

Cuando se instancia un objeto, se hace una copia de todos los atributos y métodos que tiene. Hace una copia porque distintos objetos de la misma clase pueden tener diferentes valores para sus atributos.

Ejemplo.
Objeto persona.
Atributo String colorDeOjos.
Un objeto persona llamado Sara tiene el atributo colorDeOjos en valor "verde".
Otro objeto persona llamado Lucia tiene el atributo colorDeOjos en valor "azules".

Como se necesita que ambos objetos tengan distintos valores para sus atributos se necesita que se hayan copiado los objetos.

Una vez dicho esto, hay ocasiones en las que un objeto, un atributo o un método no puede ser copiado. Por su propia naturaleza sería incoherente tener una copia de un mismo objeto. Y por eso se declara como estático. No hay normas en cuanto a la elección de cuando se ha de declarar el objeto como estático, porque es algo que depende de como se quiera resolver el problema para el cual se desarrolla el programa.

Ejemplo:

Se hace un programa para controlar distintas cosas de un hospital. Una de las cosas que se quieren controlar es lo relacionado con las habitaciones. Para ello se crea una clase habitación. Se sabe que las habitaciones tienen 2 camas, así pues habrá 2 atributos llamados cama1 y cama2.

Las habitaciones pueden tener un paciente en la cama1, otro en la cama2, o pueden no tener ningún paciente en la cama1, o ninguno en la cama2, o ninguno en ninguna cama. Además, cada habitación tendrá distintos valores para cama1 y cama2 con los nombres de los pacientes.

Por eso es necesario hacer una instanciación para cada 1 de las habitaciones, porque cada habitación tiene un número de habitación que la distingue del resto de instanciaciones de las habitaciones. Y además, sus atributos pueden ir cambiando según los nombres de los pacientes y sus necesidades.

Sin embargo, otra de las cosas que se quieren controlar es el aire acondicionado. El aire acondicionado en un hospital no puede ser controlado desde las habitaciones. Todas las habitaciones deben de hacer uso si o si de él. Y además ninguna de las habitaciones, ni de los pasillos, ni de los quirófanos, etc puede hacer el más mínimo cambio en él.

Por eso se puede decidir que el objeto aire acondicionado sea un objeto a parte. Desde el objeto aire acondicionado puede tener los atributos de quierofanoX, o quirófanos o habitaciones para controlar, desde la clase de aire acondicionado sus atributos si se quieren. Pero no al revés. Y por lo tanto sería ilógico hacer copias de este objeto. Porque única y exclusivamente hay 1 único aire acondicionado en todo el hospital.

Como ves, es una cuestión de abstracción del problema, de la manera en la que uno enfoque la manera de arreglar el problema.

[Kritik]

Iniciado por FiruzzZ

Cual es el sentido de implementar una interface?, si hay q redefinir TODOS los methods. (y por lo que dice kintero "el ya tiene todas las query que va utilizar").

Efectivamente, hay que definir todos los métodos. Pero ya te da una serie de métodos que rellenar. Es como el esqueleto sobre el que poner el resto de cosas. Sabes que vas a tener 2 ojos, pero no sabes de que color. Sin embargo sabes exactamente donde y qué forma tendrán. Así pues, haces 2 agujeros en el cráneo para ellos. El que vaya a hacer a la persona ya los pondrá, pero ya tiene los agujeros adaptados.

Iniciado por FiruzzZ

.. con los métodos públicos.. (como si se pudiera de otra forma)
..en Java estás forzado a declarar de alcance (modificador de acceso) public los methods de una interface

Si fuese obligatorio poner el modificador a public no existirían los modificadores. No se pondría nada y sería public siempre.

Los modificadores de acceso existen para modificar su visibilidad según las necesidades.

Si, es cierto... ponle a todo el modificador de public y así podrás acceder a ello desde cualquier parte del código del programa. Al igual que algunos administradores de redes comparten carpetas con control total al grupo todos, y así se quitan de problemas. Luego llega uno, borra un archivo y problemón al canto.

Iniciado por FiruzzZ

jKintero, si las query de tu proyecto son así de estáticas que ya las tenés todas definidas, definitivamente deberías usar una public static Class

Eso no tiene que ver. Depende de como se quiera resolver el problema. Es posible que si deba hacerlas estáticas. Pero también es posible que no.

[mrrobot]

Iniciado por Kritik

Si fuese obligatorio poner el modificador a public no existirían los modificadores. No se pondría nada y sería public siempre.

Los modificadores de acceso existen para modificar su visibilidad según las necesidades.

Pero una interfaz a de llevar todos sus métodos public, no?

[Profesor_Falken]

Estais respondiendo a un post que tiene 5 anios y a gente que lleva meses sin conectarse a FDW.

[Kritik]

Iniciado por mrrobot

Pero una interfaz a de llevar todos sus métodos public, no?

Eso si es recomendable pero no obligatorio. Depende de si la interfaz la vas a poner en el mismo paquete o en otro. Si haces proyectos grandes es muy posible que te organices por medio de los paquetes, y tengas varios. Entonces si es recomendable ponerlos como public.

Si vas a utilizar proyectos pequeños y con 1 solo paquete vas a funcionar, entonces mejor en friendly (sin modificador).

Iniciado por Profesor_Falken

Estais respondiendo a un post que tiene 5 anios y a gente que lleva meses sin conectarse a FDW.

Ouch!! Es verdad

[Profesor_Falken]

Código Java:

Eso si es recomendable pero no obligatorio.
 

Si es obligatorio.

En Java, los metodos de una interfaz son siempre implicitamente publicos, incluso aunque no los declares como public.
https://docs.oracle.com/javase/tutor...erfaceDef.html

All abstract, default, and static methods in an interface are implicitly public, so you can omit the public modifier.
[...]
All constant values defined in an interface are implicitly public, static, and final. Once again, you can omit these modifiers.

Un saludo