¿Por qué estoy viendo tantas clases instanciables sin estado?

Veo muchas clases instanciables en el mundo de C ++ y Java que no tienen ningún estado.

Realmente no puedo entender por qué las personas hacen eso, simplemente podrían usar un espacio de nombres con funciones libres en C ++, o una clase con un constructor privado y solo métodos estáticos en Java.

El único beneficio que se me ocurre es que no tiene que cambiar la mayor parte de su código si luego decide que desea una implementación diferente en ciertas situaciones. ¿Pero no es ese un caso de diseño prematuro? Podría convertirse en una clase más tarde, cuando sea apropiado.

¿Me estoy equivocando? ¿No es OOP si no pongo todo en objetos (es decir, clases instanciadas)? Entonces, ¿por qué hay tantos espacios de nombres y clases de utilidades en las bibliotecas estándar de C ++ y Java?

Actualización: Ciertamente he visto muchos ejemplos de esto en mis trabajos anteriores, pero estoy luchando por encontrar ejemplos de código abierto, así que quizás no sea tan común después de todo. Aún así, me pregunto por qué la gente lo hace y qué tan común es.

Veo muchas clases instanciables en el mundo de C ++ y Java que no tienen ningún estado.

Algunas razones posibles para crear clases sin ivars propios:

• El estado está o podría estar contenido en una superclase.

• La clase implementa alguna interfaz y necesita ser instanciable para que las instancias puedan pasarse a otros objetos.

• La clase está destinada a ser subclaseada.

• Manera práctica de agrupar funciones relacionadas. (Sí, puede haber formas mejores o diferentes de hacer lo mismo).

¿Me estoy equivocando? ¿No es OOP si no pongo todo en objetos (es decir, clases instanciadas)?

OOP es un paradigma, no una ley de la naturaleza. Hay algunos lenguajes donde todo es un objeto, por lo que realmente no tienes otra opción. Otros lenguajes (p. Ej., C) no proporcionan ningún soporte para OOP, pero aún puede programar en un estilo orientado a objetos. Yo diría que puedes tener OOP si no haces todo en las clases ... podrías decir que solo tienes menos OOP en ese caso.

Caleb y Robert Harvey ya han señalado qué son las clases de utilidad y algunas razones legítimas para tener clases "sin datos". Esas descripciones son acertadas, pero abordan los aspectos positivos.

Me gustaría mencionar que el abuso de las clases de utilidad definitivamente puede ser un anti-patrón OO (ver la descripción de c2wiki ). Esta cita lo resume muy bien:

Un gran número de tales clases (particularmente aquellas con un solo método) indica que los diseñadores están pensando al revés, es decir. pensando en lo que puede hacerse a un objeto en lugar de lo que puede hacer el objeto.

Si afirma que está practicando el diseño orientado a objetos, pero su base de código se compone casi por completo de clases de utilidad, diría que definitivamente está haciendo algo mal. Dicho esto, un enfoque funcional tiene tantos méritos y puede ser excelente para trabajar con él también. Simplemente no pretendas seguir el uno, mientras implementas el otro sin entusiasmo.

Las clases de utilidad en Java y C ++ se utilizan para mantener una biblioteca de métodos que toman uno o más parámetros de entrada y devuelven un resultado. No tienen necesidad de mantener el estado, si simplemente devuelven un valor. En ese sentido, estos métodos pueden considerarse como una forma cruda de programación funcional, con todas las ventajas de la misma (sin problemas de concurrencia, por un lado).

En cualquier caso, estas clases solo sirven para agrupar métodos relacionados en un solo contenedor, métodos que no requieren la instanciación de un objeto para funcionar correctamente. Un ejemplo de tal clase es una clase de matemáticas que contiene funciones SINE y COSINE (y otras funciones matemáticas).

Muchas de esas clases interactúan con los datos, incluso si no los contienen explícitamente, y necesitan hacerlo de manera que requieran múltiples instancias simultáneas para estar activas. Por ejemplo, un bean de sesión sin estado que interactúa con un procedimiento almacenado en la base de datos, pasando datos entrantes a algún paquete PL / SQL y devolviendo los resultados a la aplicación que realiza la llamada. Esa cosa debe existir en varias instancias, pero no contiene ningún campo de datos.

En lenguajes orientados a objetos donde las clases no son objetos, puedes hacer mucho más con un objeto que con una clase.

Puede pasar un objeto como parámetro, puede sustituir un objeto compatible con el tipo, puede implementar una interfaz (imagino que hay lenguajes en los que las clases son objetos, pero puede hacer algunas de estas cosas, pero en cualquier caso ...) . Todas estas cosas son bastante importantes, por lo que la decisión predeterminada generalmente es hacer que una clase sea instanciable.

Para algunas clases, las capacidades otorgadas por instanciación parecen poco probables de ser necesarias. Probablemente no necesite cambiar una implementación de Cosine por otra, por ejemplo. Resulta que son principalmente funciones de utilidad que no necesitan estas capacidades, por lo que son principalmente funciones de utilidad que tienen clases que no son instanciables.