5 respuestas en este tema

[Master23]

El problema es el siguiente , al crear un formulario y arrastrar por ejemplo 3 edits en el cual, 1 es nombre, otro es apellido, otro id, etc. Aumáticamente se le crean 3 atributos,entonces estoy algo complicado con el tema, ya que yo creo una clase diferente para administrar las diversas entidades del programa. como cliente, clase sistema, etc y bien por ejemplo como el form1 tiene sus atributos ya que son los edits , no sé si debo volver a crear los atributos en la otra clase osea atributos nombre,apellido y id,pero solo hago métodos no creo que se la forma correcta , yo generalmente solo hago métodos en la clase para manejar los datos pero en esos métodos creo parametros y les paso los edits como atributos por lo tanto en esa clase no uso atributos, no sé estoy usando mal el concepto .¿ debo crear los atributos en la otra clase y pasarle los edits por un constructor ?,o simplemente dejarlo así, gracias de antemano.

[Delphius]

Hola Master23,

Ha decir verdad no te entendí bien del todo. ¿Te molestaría si te pido que nos des un ejemplo de lo que estás haciendo y sobre cual es tu duda al respecto?

Saludos,

[Master23]

Hola Master23,

Ha decir verdad no te entendí bien del todo. ¿Te molestaría si te pido que nos des un ejemplo de lo que estás haciendo y sobre cual es tu duda al respecto?

Saludos,

Por supuesto amigo delphius, aquí un ejemplo claro.

delphi

unit Unit1;
interface
uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs;
type
  TForm1 = class(TForm)
    Nombre: TEdit;
    Apellido: TEdit;
    Id: TEdit;
  private
    { Private declarations }
  public
    { Public declarations }
  end;
var
  Form1: TForm1;
implementation
{$R *.dfm}
end.

Este es el primero , como se puede ver en esa clase ya están hechos 3 atributos de tipo edit , que van a capturar los datos correspondientes, Nombre,Apellido,Id . Yo creo otra clase para manipular las entidades diferentes, como clase cliente y bueno, lo que quiero saber es, ¿Debo volver a crearle los atributos en la nueva clase ?, como la clase form tiene ya sus atributos entonces yo simplemente hago una clase como esta sin atributos y solo métodos,pero está mal según veo , aquí pueden ver un ejemplo:

delphi

unit Unit2;
interface
uses
 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs;
  type
    TCliente = class(TObject)
      private
      {}
      public
        procedure InsertarDatos(Nombre:string;Apellido:string;id:integer);
  end;
implementation
 
 procedure TCliente.InsertarDatos(Nombre: string; Apellido: string; id: Integer);
  begin
   //Digamos que aquí uso las variables nombre , apellido y Id para insertar a
   //La base datos algunos de estos datos.
  end;
end.

Por lo tanto en la unidad principal hago lo siguiente y no uso atributos en la nueva clase si no que atravez de sus métodos les envio los parametros capturados en los atributos edits. Aquí veremos la forma de implementar en la clase form es que hago esto.

delphi

procedure TForm1.Button1Click(Sender: TObject);
var
Cliente:TCliente;
begin
Cliente.Create;
Cliente.InsertarDatos(Nombre.Text,Apellido.Text,StrToint(id.Text));
Cliente.Free;
end;

En conclusión , quiero saber si estoy aplicando mal el concepto al hacer esto, ya que una clase sin atributos, creo que no es correcto hacerlo , sin embargo no tiene sentido que le haga atributos nombre, apellido,id si en la clase form ya estan , simplemente hago métodos y se los paso como parametros para la inserción , espero que me puedan ayudar, gracias de antemano.

[Sergio]

Vaya por delante que yo no suelo crear objetos dentro de mis forms para tratar con las entidades que alli se editan, en parte porque mis fichas siempre editan un record sin mas, por lo que el propio dataset es, para mi, el sitio correcto donde tener los datos accesible a cualquier parte del form.

Aparte de eso, si lo quieres hacer bien, yo crearia en tu objeto cliente una propiedad "nombre" con un par de funciones GetNombre y SetNombre que lean y escriban sobre el field del dataset, asi "aislas" al objeto de depender de unos datos externos en su funcionamiento interno.

Si un dia lo necesitas, puedes cambiar esas dos funciones y hacer que tu objeto opere sobre una lista de objetos TCliente en memoria en lugar de un dataset, por decirte algo. Creo que eso es lo correcto, minimizar la dependencia de los datos a un solo punto concreto del objeto.

[Delphius]

Hola Master23,
Disculpa si no he respondido antes. Estoy bastante ocupado últimamente y no puedo darme demasiado tiempo.

Creo que como tu estás iniciandote en el tema POO para una primera aproximación va bastante bien.
Haces bien en preguntarte si te es útil o no esos atributos en la clase TCliente.
La respuesta puede ser un SI como un NO... todo depende del uso y diseño, de lo que se espera de la clase TCliente. ¿La usarás para algo más? ¿O en otro lado? ¿Quienes más invocan y/o crean objetos de cicha Clase? ¿Es posible o de esperarse que la clase TCliente deba regresar algún dato? Si, la respuesta fue si, entonces respóndete ¿Desde donde proviene o quien es (o debería) ser el dueño de dicho dato?
Esos tipos de preguntas te van a ir guiando para diseñar tus clases y la forma en como se van a ir comunicando y relacionando.

No puedo decir que SI, ni tampoco que NO. Es muy importante conocer bien el diseño, y contar con una mirada más global.

En principio, una clase que no tiene atributos podría ser catalogada como inútil, inservible, que no tiene sentido pero en realidad no necesariamente debe ser así. Justamente ahora se me ocurre un caso de una clase sin atributos: Una clase que realiza cálculos matemáticos varios:

delphi

TCalculadora = class
public
   function Suma(X, Y: Double): Double;
   function Sgn(X: Double): Double;
   Function Transpose(A: TMatrix; var At: TMatrix): TResultMatrixOperation;
   // ....
end;

Para esta clase no se le han imaginado atributos, (aunque también se podría darle algunos) ya que todo los datos que necesita los recibe como parámetros. La idea, aparentemente, es centralizar todos los cálculos en una clase. A como está diseñada la clase, posee visibilidad por parámetros.

¿Es legal esto? Pues si, no viola en ningún momento el Análisis OO.

Volviendo a tu caso, ¿entonces? ¿Está bien? Si te resulta de utilidad pues si, ahora si únicamente esta clase hace de intermediario entre el Form y un DataModule (talvez) o incluso en forma directa hacia algún DataSet (Tables, Querys, etc) debes preguntarte ¿Y en el caso inverso, que sucede? Es decir: tu form se apoya en TCliente para pasar los datos hacia la DB, pero... cuando es desde la DB hacia el Form, ¿Cómo le encaras? ¿Hay alguna vinculación directa y ésta se trata de un camino alternativo o que evita al TCliente? Por dar un un caso típico a modo de ejemplo: el form tiene un DataSource para alimentar un DBGrid y justo éste está ligado a un TQuery (que está en un DataModule). ¿De que sirve el TCliente aquí?

¿Me explico? Si en un sentido pasas por la clase, y en el otro sentido (o en el mismo, incluso) hay una (y otra) manera de esquivarla ¿No crees que está más molestando que ayudando?
Esto es justamente lo que dice Sergio.

No quiero que te mortifiques demasiado. Sigue practicando los conceptos, a medida que los vas entendiendo tu visión del análisis y el diseño OO se te hará más rica y podrás encontrar nuevas cosas.
Entender el paradigma OO no es algo que se hace en días, es en meses (incluso de años  )... No desesperes. Por mi parte puedo sugerirte la lectura del libro Introducción a la Programación Orientada a Objetos de Timothy Budd, pero debes primar las fuentes que haya recomendado y citado tu profesor en el programa.

Cuando ya tengas más cancha y estés metiéndote en UML te altamente aconsejo la lectura de UML y Patrones de Craig Larman. Ese libro te abre la cabeza de una manera no vista por lo general en la forma en como se dan las cátedras... logras entender muchísimo mejor el tema del Análisis y Diseño OO. Pero primero lo primero: aprende bien los conceptos OO, practica y practica.

Seguramente tu profesor en no mucho tiempo les enseñe una técnica en la que apoyarse: las tarjetas CRC (Clase, Responsabilidad, Colaboración). La idea de esta "tarjeta" es conseguir listar las responsabilidades de la clase como a sus colaboradores, de ese modo uno puede darse una idea si la clase es más una controladora que no sabe delegar, o si por el contrario ha delegado demasiado.

Saludos,

[Master23]

Muchas gracias delphius, excelente estoy revisando los libros que me recomendaste muchas gracias por tomar de tu preciado tiempo , para responderme esta inquietud, y muchas gracias Sergio igualmente por tu ayuda.