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

[mamcx]

Otra cosa:

La POO cuando es algo que debe venir de forma natural. Siempre me ha parecido que es un atentado a la educacion cuando a la gente en su curso introductorio le dan el tema del polimorfismo o de patrones y todo eso. Es como uno estar en un curso de cocina y que empiezen por explicarle las diversas famialias de frutas, verduras, carnes, condimentos y todo eso.

Lo unico que hay que saber para ser un "duro" con la programacion es esto:

* Los sustantivos son los nombres de las clases (ej: Ventana, Cliente)
* Los adjetivos, sus propiedades (Alto, Ancho)
* Los verbos son las acciones que:
- Si son verbos directos, metodos (Close)
- Sin son verbos preguntones, funciones (CanClose())
- Sin son verbos de "momentos" son eventos (WhenClose())

Usar nombres claros y directos. Si pones:

EsActivo

y lo documentarias como:

Funcion que determina si el cliente es valido

entonces dejate de bobadas y cambialo por

EsValido

y te ahorraste la documentacion

- Haz pedazos de codigo que sean concisos y se dedican a una sola cosa.

- Haz clases que se encargen de mover las acciones de un lado a otro. Clases de control (ej: Para mover un inventario). No mezcles clases que controlan con clases que informan o que definen una entidad simple a menos que haya muy poco que controlar.

- Haz codigo testeable. Metete en el asunto de TTD (Test Driven Desing). El resultado de un codigo testeable es casi sin equivocacion una excelente POO.

- Cuando creas que algo esta mal hecho, esta mal hecho.

- No uses ejemplos de Java o C* para aprender OO. Por regla general son muy complicados. Lee pascal, o python. Son los lenguajes que por regla general tienen las soluciones mas sencillas posibles

Leete y aprendete el Zen de python, y aplicalo en Delphi:

* Bello es mejor que feo.
* Explícito es mejor que implícito.
* Simple es mejor que complejo.
* Complejo es mejor que complicado.
* Plano es mejor que anidado.
* Disperso es mejor que denso.
* La legibilidad cuenta.
* Los casos especiales no son tan especiales como para quebrar las reglas.
* Aunque la practicidad le gana a la pureza.
* Los errores nunca deberían dejarse pasar silenciosamente.
* A menos que hayan sido silenciados explícitamente.
* Frente a la ambigüedad, rechazar la tentación de adivinar.
* Debería haber una -y preferiblemente sólo una- manera obvia de hacerlo.
* Aunque esa manera puede no ser obvia al principio a menos que usted sea Holandés.
* Ahora es mejor que nunca.
* Aunque nunca es a menudo mejor que ya.
* Si la implementación es dificil de explicar, es una mala idea.
* Si la implementacion es fácil de explicar, puede que sea una buena idea.

[[Delphius]]

Mario, ¡excelente resumen!
¡Bellísimamente simple! Más directo y preciso de decir, no hay!

Saludos,

[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

[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,