Todo iba bien hasta getAll()?
Aparte de lo que dice @jonni09lo, hay unas cuantas cosas de OOP pura que hay que tener en cuenta, y que busco cuando reviso codigo de objetos con persistencia en DB.
- Todos los metodos de instancia, deben ser de instancia?
El metodo getAll() es un metodo de instancia.Es necesaria una instancia para poder llamarlo.Y aqui ya salen 2 problemas.El primero, que ese metodo no es de una instancia.Un metodo de instancia devuelve cosas relacionadas con la instancia (un equipo en concreto).Y getAll no lo cumple.Devuelve otros equipos.Es un metodo de creacion de instancias.Similar problema ocurrira cuando crees getEquipoByEmpleado, etc, etc.
Para poder crear un equipo dadas unas condiciones, necesitas otro equipo.Y (este es el segundo problema), muy posiblemente, para crear el primer equipo, necesites un id (suele ocurrir).
La solución "barata", aunque discutible desde el punto de vista de la OOP es convertir el metodo de instancia, en metodo de clase (estático).La solución más laboriosa es crear una clase Factoría asociada.
- Qué son las relaciones?
Ya que es un objeto mapeado a una BD, es posible que tenga relaciones como variables miembro de la clase.Qué son esas variables miembro? Almacenan el valor del campo relación, o una instancia del objeto relacionado? Si yo hago getEmpleado, que recibo? un id, o una instancia de empleado? Si yo hago setEmpleado, qué espera? Un id, o una instancia de la clase Empleado?
En tu código, mezclas las dos cosas.
En el método getAll(), se llama a setEmpleado pasando un id. Lo interesante es que setEmpleado no hace nada con ese id(que jonny09lo, en cuanto vió lo de la BD, fue a morder ahí, y se le pasó
), por lo que el método está mal.Pero lo que parece es que la variable miembro privada _empleado, debe almacenar una instancia.Por lo quet getEmpleado retorna una instancia.
Así tenemos setEmpleado que recibe un id, y getEmpleado, que retorna una instancia.
- Cómo se gestiona si un objeto ya ha sido cargado de la BD?
En el caso de que el id sea requerido en el constructor, se supone que el objeto se va a obtener de la BD inmediatamente.Hay que tener en cuenta que un constructor no devuelve errores.Si el objeto no existiese, habría que gestionarlo usando excepciones o métodos de tipo "isLoaded()".
Pero, si el id no es requerido en el constructor, están todos los métodos protegidos por posibles accesos *antes* de que el objeto se cargue?
Tiene sentido crear un objeto equipo, y, sin cargarlo, pedirle el empleado? Cómo reacciona la clase en ese caso?
- En caso de que los métodos get... y set... de relaciones, usen instancias, cuándo son creadas? (lazy-loading)
Si inmediatamente, cuando creas una instancia y cargas datos de la BD, inicializas las variables miembro que modelan relaciones, en instancias de esas clases..Es lógico que éstas hagan lo mismo a su vez...Y generen otras instancias, las cuales generan otras..
Y, posiblemente, todas cargandose de base de datos...
- Qué devuelven los métodos que retornan múltiples datos?
Devuelven *siempre* instancias, o *siempre* filas? Es una versión del problema del Get y Set.Cuidado con devolver siempre instancias.Y es el mismo problema que el anterior, multiplicado por el número de filas que obtengas.
Aparte hay otras consideraciones, sobre todo de rendimiento.
Pero, dejo una coña más, que siempre me ha llamado la atención:
- Teóricamente, un objeto de una clase *nunca* debería poder obtener datos de otra.Es decir, cualquier clase construida como un mapeo de una tabla, jamás podría hacer una query con un JOIN.Eso significaría que esa clase conoce lo que son variables miembro de otra clase, podría cambiar valores,etc.Y eso está prohibido en OOP.
Es uno de los problemas de la OOP con respecto a lo *relacional*.No son lo mismo, por mucho ORM y mapeos que hagamos.