Atributos de Clase

"Cristian" escribió en el mensaje
news:%

Estimados,

Estoy en el desarrollo de una aplicación y para ello estoy utilizando una
capa de conexión (App Block), una capa de negocio y la interfaz de
usuario (Aplicación). Debo aclarar que es primera vez que utilizo el
modelado UML.
Durante el modelo de clases (después de analizar mis casos de usos y
modelo de clase de primer nivel) me surgió una duda que me tiene algo
confundido.
Tengo una clase "Impresoras" de la siguiente manera:

Impresora
CodImpr: String
PathImpr: String
Description: String
Manager: String
GetPrinter() : Dataset
AddPrinter(): Void
...
...

Mi confusión pasa cuando quiero agregar una impresora, o sea utilizar el
método AddPrinter(), según yo tengo 2 formas de poder hacerlo.
1.- En la aplicación, al agregar la impresora, setear cada atributo de la
clase con su respectivo valor y al final llamar al método AddPrinter() que
tomará cada valor (entro de la clase) y lo insertará en la BD, o sea en mi
aplicación tendría algo asi

oImpresora.CodImpr = "001"
oImpresora.PathImpr = "\\serverprint\P5XCONTA"
oImpresora.Description = "Sector contable."
oImpresora.Manager = "Juan Gómez."
oImpresora.AddPrinter

2.- En la aplicación, al agregar la impresora, pasar cada atributo como
parte de la función AddPrinter(), o sea en mi aplicación tendría algo
así..
...
oImpresora.AddPrinter("001", "\\serverprint\P5XCONTA", "Sector Contable",
"Juan Gomez")

(Acá obviamente el método de mi clase debe tener definido cada atributo:
AddPrinter(CodImpr as string, etc..))
Utilizando esa forma, no me hace mucho sentido tener los atributos
definidos dentro de la clase, o sea, a primera vista, no haría uso de
ellos ya que el método siempre pasará dichos valores.

La tabla en la BD esta con los mismos atributos de la clase (CodImpr,
PathImpr, Description, Manager)

Según lo que he leído, al modelar se deben definir las "caracteristicas"
de cada clase y las acciones que ella realiza, pero si en esas acciones
(métodos), se pasan los valores o "Caracterísitcas" para realizar la
operación. ¿cuál es la idea de tener esas "caracteristicas" definidas
en la clase si no se hacen uso de ellas?,
¿Cuál es la forma correcta de modelar y utilizar las clases?,

Si tienen links o ejemplos les estaría muy agradecido.

Desde ya agradezco sus comentarios.

Hola, Cristian:

La vara para medir la corrección de un diseño es el sentido común.

Las clases pueden tener o no tener atributos, y esos atributos pueden ser o
no ser visibles para los "clientes" de esa clase.

La norma general es la economía: si una clase debe tener un determinado
atributo, no te queda mas remedio que agregarlo.

Una extensión del principio de la economía material es la economía de las
interfaces: un atributo no debería ser visible a menos que esa visibilidad
sea necesaria para los clientes de la clase. Y si es visible, los accesos
permitidos deberían ser estrictamente los necesarios: si no es necesario
modificarlo desde afuera, debe ser de solo lectura. Igualmente, si sólo va a
asignarsele un valor destinado a ser "consumido" internamente, entonces
debería ser de solo escritura.

Al menos eso es lo que dice la teoría, y ese tipo de diseño tiene una gran
belleza formal: en lo personal muestro todo lo que no resulta incompresnible
desde fuera, y permito accesos lo mas amplios posibles, a menos que haya una
buena razón para lo contrario: mi objetivo es producir sistemas tan
extensibles y flexibles como sea posible. Pero eso es otra cuestión.

Ahora, volviendo a tu tema: VB permite la implementación de métodos
sobrecargados, por ejemplo:

Dim oImpresora As tuClaseImpresora = New tuClaseImpresora
With oImpresora
.CodImpr = "001"
.PathImpr = "\\serverprint\P5XCONTA"
.Description = "Sector contable."
.Manager = "Juan Gómez."
.AddPrinter
End With

(semánticamente, AddPrinter pareciera mas un metodo de una clase que
presente una colección de impresoras que de una impresora individual: por lo
general es mala idea responsabilizar a una clase de mantener las propiedades
y ofrecer los servicios de un objeto, a la vez que de mantener las
diferentes instancias de esa clase que existan: hay una especie de
anidamiento infinito que en el mejor de los casos rsulta confuso, y
catastrófico en el peor: tal vez oImpresora.Guardar(...), y esconder detrás
de este metodo la complejidad de la administración, delegada a una clase
especializada en esta actividad)

Pero lo mismo puedes escribir:

oImpresora.AddPrinter("001", "\\serverprint\P5XCONTA", "Sector
contable.", "Juan Gomez")

El tener propiedades te puede permitir, por ejemplo, cambiar la descripcion
de una impresora sin tener que eliminarla y crear una nueva:

oImpresora.Description = "Marketing"

conservando iguales el resto de las propiedades (claro que esto puede tener
o no tener logica en función de tu diseño, del cual solo veo una parte
minima).

Es decir, la diferencia entre un buen diseño y un mal diseño no reside en el
apego a determinadas reglas, sino en la adecuación de cada clase a los fines
para los que fue concebida.

Otro punto de vista es el metodológico: en su columna "Joel on Software",
Joel Spolsky publicó un artículo titulado "Disparar y Avanzar", cuya lectura
te recomiendo: si te pones a juzgar la calidad formal de tus diseños, nunca
estarás satisfecho, y nunca avanzarás. Lo mejor es diseñar
"superficialmente" cada clase e inmediatamente implementarla y ponerla en
uso. El 99% de los cambios a una clase surge durante sus primeros usos. El
proceso de desarrollo de software hace mucho tiempo que dejó de ser aquello
de definir hasta el último detalle para luego construir "según el plano" de
manera casi automática. La definición de los detalles se realiza mediante
código, y las pruebas se hacen con componentes reales. Si despues de
construir una clase descubres que le sobra o que le falta algo, se lo quitas
o se lo agregas: mientras respetes las interfaces definidas, podras hacer
con tu clase todo lo que quieras.

De modo que no te preocupes por "lo correcto": si tu clase debe proveer
algun elemento de información, agregale una propiedad.

Y ya en concreto: es mejor un metodo que tome cuatro argumentos de tipos
definidos (el compilador podrá determinar si la llamada es o no correcta,
previniendo los errores) que tener que asegurarte de haber asignado valores
correctos a cuatro propiedades para luego llamar a un metodo sin parámetros.
Es mas economico en terminos de escritura tambien (como puedes ver al
comparar cinco lineas contra una); mas aun cuando en la llamada con
parametros tienes la ayuda de Intellisense mientras que de lo contrario
tienes que hacerlo todo "a pelo".


Salud!