Si la relación entre TipoProblema y Problema es 1 a 1, lo primero a preguntarse es qué diferencia a TipoProblema de Problema.
Código PHP:
Ver originalLa entidad TipoProblema es una entidad con información básico del tipo de problema (nombre, descripción) (pero estos tipos son diferentes para cada problema1..N)
Qué frase describe mejor lo que estás modelando?:
- La entidad Problema tiene una entidad TipoProblema que contiene información básica del tipo de problema (nombre,descripcion)
o
- La entidad Problema tiene un nombre, descripción, y un tipo.
Cuando se gestiona un "tipodealgo", estamos hablando de "algo" que tiene un valor acotado por un cierto conjunto.En cualquier caso, un "tipodealgo" *no* es una entidad aparte.Lo normal es que defina la naturaleza de una clase.Puesto de otra forma:Si hicieras un árbol de clases de animales, no harías una clase "Animal", que "tiene" un tipo "Mamífero" o "Insecto".El animal *es* un Mamífero o un Insecto.
El asunto ahora es cómo modelar esa serie de valores acotados:
- Si el comportamiento de una clase depende casi absolutamente de su "tipo", la clase base no es más que un interfaz, y las clases derivadas implícitamente definen el tipo de problema que son.La información de tipo está en la clase.Así tendrias un interfaz "Problema", y un "ProblemaTipo1","ProblemaTipo2","ProblemaTipo3 ", etc.No es necesaria una variable miembro "tipo".La acotación de los posibles valores se hace a través de la existencia o no de clases para dichos tipos.
- Si el comportamiento de la clase depende de su tipo sólo en parte, la información de tipo, en vez de estar en la clase, puede ser simplemente una variable miembro.Pero la acotación de los posibles valores, ya queda en manos del código.En lenguajes que soporten tipos de datos ENUM , es muy sencillo crear este "set" de valores.En PHP, un array puede valer.En este caso, y ya que el comportamiento de la clase depende de su tipo sólo hasta un cierto punto, la clase base puede ser tanto una clase concreta como abstracta.
- Una mezcla de los dos anteriores casos, sobre todo si existen "familias" de tipos.En este caso, existen clases derivadas que especializan la clase base (añadiendo tipos implicitos por clase), que dan valores a la variable miembro "tipo".Pero este tipo ya no es global.Es particular a esta clase derivada, por lo que lo que la lista de tipos es una lista de tuplas (clase,tipo-local).
Pero, en general, las clases con nombre "Tipodealgo" a mi no me gustan nada.Es simplemente mover el problema de la clase que lo tiene, a otra clase, sin aportar mucho a la resolución del problema, y eliminando contenido semántico de la clase que lo debe tener."Tipo de algo" suena a "tipo de dato".Y esa información es, precisamente, lo que da una clase.Qué "tipo de dato" es una cierta instancia.
En resumen.Yo no veo "TipoProblema" como una clase aparte.Veo la clase "Problema".Posiblemente, varias subclases, que definen tipos de forma implícita (por clase).
Por ejemplo, ProblemaEnSistema , ProblemaEnDatos,ProblemaHumano.Cada uno de ellos, tiene varias variales miembro propias, que no existen en Problema.Pero, a la vez, cada una de ellas tiene sus propios subtipos.Por lo tanto, los tipos de problemas es una lista de tuplas ("ProblemaEnSistema","1"),("ProblemaEnSistema","2" )......("ProblemaEnDatos","1").