Programacion orientada a Objetos...duda total....

[mamcx]

Donde parezca mejor.

Cuando se trata de modelar un proceso de negocio, probablemente el mismo proceso dice como se hace.

Quien hace la inscripcion? El alumno? El profesor?. (Ok, no es pa' poner una clase llamada TJulianitaLaSecre!). En tal caso seguramente hay un proceso de inscripcion.

Pero si lo UNICO que hace ese proceso es inscribir, pues que bobada hacer otra clase. En tal caso, si no hay un workflow lo mas simple es entender que la inscripcion de un alumno es una forma glorificada de decir: Alumno.... Nuevo.
-------
Yo tambien hice un software para escuelas, que a la fecha ha sido el de mas uso (que yo sepa mas de 3000 escuelas!). Ahora, en esa epoca era mas bien novato, pero en fin....

[[Delphius]]

Empezado por roman

A ver, un ejemplo-pregunta, porque así como lo dice Mario suena muy fácil, pero..

Tengo un sistema que gestiona las inscripciones de alumnos a distintos cursos. Una inscripción no puede hacerse así como así, debe cumplir ciertas reglas. Puedo tener mis clases Alumno y Curso (mis sustantivos).

¿Dónde hago la inscripción?

Código Delphi [-]Alumno.Inscribir(Grupo);


o

Código Delphi [-]Grupo.Inscribir(Alumno);


o bien una clase aparte:

Código Delphi [-]Reglamento.Inscribir(Alumno, Grupo);


// Saludos

Empezado por mamcx

Donde parezca mejor.

Cuando se trata de modelar un proceso de negocio, probablemente el mismo proceso dice como se hace.

Quien hace la inscripcion? El alumno? El profesor?. (Ok, no es pa' poner una clase llamada TJulianitaLaSecre!). En tal caso seguramente hay un proceso de inscripcion.

Pero si lo UNICO que hace ese proceso es inscribir, pues que bobada hacer otra clase. En tal caso, si no hay un workflow lo mas simple es entender que la inscripcion de un alumno es una forma glorificada de decir: Alumno.... Nuevo.
-------
Yo tambien hice un software para escuelas, que a la fecha ha sido el de mas uso (que yo sepa mas de 3000 escuelas!). Ahora, en esa epoca era mas bien novato, pero en fin....

Hola,
Pues no se si lo interpreto adecuadamente... pero por lo que entiendo... si no existe o no se tiene conocimiento de que exista un motivo en particular para decir que el proceso de incripción aporta valor al negocio, entonces tener esa tercera clase no aporta nada. No tiene sentido.
Ahora con respecto a cual de las otras dos opciones es válida, yo deduzco ,por la breve descripción de roman, que es preferible la primera opción que a la segunda.
Me parece más apropiado semanticamente hablando decir:

Código Delphi [-]
Alumno.Inscribir(Grupo);

que decir

Código Delphi [-]
Grupo.Inscribir(Alumno);

Ahora bien, si existe una buena razón para justificar que la presencia de este proceso tiene cierto valor de negocio, y si obedece a ciertas reglas, entonces a mi modo de ver es preferible tener una clase TReglaIncripcion.
Y el modo que emplearía para saber si se cumple dicha regla sería algo asi:

Código Delphi [-]
procedure TAlumno.Inscribir(Grupo: TGrupo);
begin
...
if ReglaInscripcion.IncripcionValida(Self, Grupo)
  then Inscribir(Grupo)
  else ....
...
end;

Es decir, dejo a la clase TReglaInscripcion que determine si es válido el proceso. Ya como está implementada esta clase no viene al caso. Tal vez, tenga clases TReglasNegocio, TReglasNegocioIncripcion, etc... que le asisten en el proceso. No está todo dicho.

En fin creo que se entiende la idea. Yo tendría que saber un poco mejor del dominio para opinar.

Saludos,

[roman]

Más que nada era un ejemplo pues a mi al menos. me parece justamente que no siempre queda claro qué camino tomar.

En este ejemplo, desde luego hay reglas que seguir, por eso dije que no se hace así como así; no todos los alumnos se pueden inscribir a cualquier curso, se debe tener en cuenta qué tipo de alumno es, cuál es su historia académica, cuántos cursos más lleva, etc.

Ahora, en algunos casos el alumno puede inscribirse él mismo, pero en otros es un personal calificado quien debe hacerlo y en otros más es un proceso automático (algunas reinscripciones), pero en todas las modalidades se deben cumplir una serie de reglas.

No sé qué se entendería porque el proceso en sí tenga un valor de negocio, en mi ingenuidad considero que lo tiene en tanto que existe. Una inscripción es un ente en sí mismo con determinados atributos como la calificación, la fecha en que se realiza, la fecha en que se paga, etc.

Luego entonces ¿sería descabellado poner:

Código Delphi [-]
Inscripcion := TInscripcion.Create;

Inscripcion.Alumno:= Alumno;
Inscripción.Curso := Curso;

if Inscripcion.Validar then
  Inscripcion.Guardar;

de manera que es el mismo objeto Inscripcion el que valida las reglas?

// Saludos

[[Delphius]]

Empezado por roman

Más que nada era un ejemplo pues a mi al menos. me parece justamente que no siempre queda claro qué camino tomar.

En este ejemplo, desde luego hay reglas que seguir, por eso dije que no se hace así como así; no todos los alumnos se pueden inscribir a cualquier curso, se debe tener en cuenta qué tipo de alumno es, cuál es su historia académica, cuántos cursos más lleva, etc.

Ahora, en algunos casos el alumno puede inscribirse él mismo, pero en otros es un personal calificado quien debe hacerlo y en otros más es un proceso automático (algunas reinscripciones), pero en todas las modalidades se deben cumplir una serie de reglas.

No sé qué se entendería porque el proceso en sí tenga un valor de negocio, en mi ingenuidad considero que lo tiene en tanto que existe. Una inscripción es un ente en sí mismo con determinados atributos como la calificación, la fecha en que se realiza, la fecha en que se paga, etc.

Luego entonces ¿sería descabellado poner:

Código Delphi [-]Inscripcion := TInscripcion.Create; Inscripcion.Alumno:= Alumno; Inscripción.Curso := Curso; if Inscripcion.Validar then Inscripcion.Guardar;


de manera que es el mismo objeto Inscripcion el que valida las reglas?

// Saludos

Que el proceso tenga valor de negocio significa que para el ambiente o dominio le es útil y representa un elemento más que forma parte de su trabajo, es parte de la organización y/o le da valor agregado.

Una inscripción tiene, al menos yo creo que si, que tiene valor de negocio. Es una actividad central y afecta en otras áreas. Por tanto, es de importancia dos cosas aqui: el proceso y el documento. Es necesario contar con un método que permite dar soporte a esta actividad. Por ejemplo, el nombre InscribirAlumno. Ahora, como valor de negocio, el documento o formulario que se llena es la FichaInscripcion. Puede que realizar una clase que represente a dicho documento les sea de utilidad en un futuro... por ahora no estaría mal añadirla al repertorio.

Entonces, si lo veo asi, yo diría que tenemos las siguientes clases: Alumno, Grupo, FichaInscripcion.

Se estuvo debatiendo la idea de que exista una clase que determine las reglas de inscripción.
Tu enfoque, amigo roman, no es descabellado. Es entendible y si te es una representación viable del dominio, pues sigue.

Si me lo permites, yo lo veo un tanto distinto. Si bien se puede entender que el alumno es el interesado en llevar el método de incribirse (es posiblemente el experto en información), si realmente existe un conjunto de reglas que afectan a esto, yo sugeriría que no posee toda la información necesaria para llevar a cabo dicho propósito. Que sea un experto parcial no es un gran problema, pero a vista de la presencia de la volatilidad de este proceso, es mejor ubicar el grueso del problema de la regla en otro lado.

Es entendible que el interesado sea el alumno, más termina no siendo el quien decide y lleva a cabo el proceso. Puede entenderse, si se le desea verlo (y buscarle una quinta pata al problema), que entre el alumno y el proceso medie algún interesado. Este intermediario muy posiblemente sea el candidato potencial para asumir el proceso estudiado: es el quien tiene más conocimiento e información de como tratar el tema. Ando pensando en un nombre que sea más representativo... si es que en ocasiones es otra persona quien llena la ficha, en otras el estudiante, y en otras una máquina (buscarle la octava)... yo diría que conviene llamarlo ProcesadorInscripcion (ya me diran si el estudio del dominio sugiere otro nombre. Al menos yo lo veo que tantos actores humanos y no humanos hacen uso del ProcesadorInscripcion)

Es este ProcesadorInscripcion quien en definitiva realiza la inscripción. En resumidas cuentas, el algoritmo para mi puede venir así:

Código Delphi [-]
procedure TProcesadorInscripcion.InscribirAlumno(Alumno: TAlumno, Grupo: TGrupo);
var Ficha: TFichaInscripcion;
begin
   if MotorReglaInscripcion.EsValidaInscripcion(Alumno, Grupo)
     then begin
               // Creamos la ficha de inscripción
               Ficha := TFichaInscripcion.Create;
               
               // Llenamos la ficha
               Ficha.Alumno := Alumno;
               Ficha.Grupo := Grupo;
               ...
               Archivar(Ficha);
            end
     else ...
end;

Como puede verse, he añadido una clase MotorReglaInscripcion. Esto está sujeto a debate. Si es posible que las reglas cambien, y que sean un tanto complejas o arbitrarias... me parece adecuado delegar en un motor de reglas que asuma esa responsabilidad y que el Procesador delegue parte del trabajo. Si esta etapa del trabajo (determinar si es válida) no cambia, pues que el método EsValidaInscripcion pertenezca a ProcesadorInscripcion y no exista el motor.

Muy posiblemente ProcesadorInscripcion tenga visibilidad de atributo del motor (si esta motivado su uso). Cabe la posibilidad de que este ProcesadorInscripcion haga poco trabajo, (¿sólo inscribe?) pero al menos deja clara la intención de que nos abstraemos de quien lleva a cabo formalmente la inscripción.

Se ha añadido el objeto FichaInscripcion. Este objeto a mi modo de ver, es quien en realidad termina siendo guardado o archivado (el que mejor convenga), leído y (¿actualizado?). Formalmente decimos que se llena una ficha o acta de inscripción y esto motiva la aparación de esta clase. Y si esta clase representa a dicho documento, es una buena candidata a ser quien termina conservando la información de que el estudiante a sido inscripto.

Puede que mi diseño sea un tanto, liviano... que hay muchas clases que hacen poco. Sólo hemos analizado una pequeña punta de un iceberg.

Podríamos seguir toda la semana con esto... a lo que quiero llegar es a una "simple" pregunta ¿Quién de nosotros tiene razón?

No hay, ni habrá, una única manera de representar un mismo problema. Disculpen nuevamente el rollo.

Saludos,

[[felipe88]]

Corrijanme si me equivoco; estan muy interezante los ejemplos con los que se desarrolla este tema lo que considero ya un "debate"... para este tipo de situaciones en las que va mas la duda que la razon, no fueron diseñados los diagramas de clase y de mas. Creo que actualmente existen las herramientas suficientes que nos permiten a quienes aprendendemos o repasamos este tema, tener cierto control de lo que realizamos y como lo realizamos; dados los ejemplos nos damos cuenta que tan importante es esa parte llamada analisis (Que considero preámbulo para el trabajo OO) la cual mejoramos con cada experiencia.