Diferencia entre Clases y Modulos
Edwin Rivera
clases y modulos para mi aplicacion en la clase genero la conexion a la base
de datos y en el modulo esta algunas variables y funciones.
pero lo que estube equivocado es solo saber la teoria y no mas la practica,
hasta que un dia me hicieron ver que la teoria es tan importante como la
practica. por eso quisiera saber por favor en que caso usar una clase y un
modulo.
He encontrado en internet muchos conceptos pero deseo algo sencillo y facil
de interpretarlo.
Gracias de antemano por su respuesta
Federico
wrote:
Hola Edwin,
Te cuento la diferencia básica de un a manera sencilla y sin entrar en
mucho detalle, ya que la explicación es mucho más extensa.
Las clases puedes instanciarlas y crear objetos a partir de ellas. Las
clases pueden tienen métodos (son las funciones de una clase),
propiedades (son los datos de una clase que se pueden exponer a otras
y pueden ser de lectura, escritura o lectura/escritura) or ejemplo La
razón Social en una clase Cliente es un dato que podrías exponer a
otras clases, lo que eran antiguamente las variables públicas; los
métodos también se pueden exponer a otras clases, por ejempleo un
método Delete de una clase Clientes; las clases pueden responder a
eventos. Las clases pueden heredar de otras clases, es decir, crear
una nueva clase a partir de otra, como los formularios windows; hay
diferentes tipos de clases, como por ejemplo clases abstractas.
A las clases también se les suele llamar módulos de clase.
Los módulos son lo que hemos utilizado siempre como archivos de
procedimientos y funciones; en ellos tendrás lo que tienes ahora,
funciones y procedimientos que utilizas en tu aplicación de manera
general.
También podrías tener las funciones como métodos privados dentro de
una clase, pero cuando se trata de funciones generales para toda una
solución como puede ser una rutina de mensajes o funciones
repetitivas, como sería el obtener un datarow a partir de un
BindingSource cuaqlquiera, es mejor tener las funciones en un módulo
de manera que puedas utilizarlas en cualquier proyecto de la solución.
Para utilizar las funciones y procedimientos de un módulo en un
proyecto tienes que agregarlo a las referencias del proyecto.
Un Saludo
Federico Luna
Leonardo Azpurua
"Edwin Rivera" <Edwin...@discussions.microsoft.com> escribió en el
mensaje news:ABD7E04E-DD1E-4B22...@microsoft.com...
Hola, Edwin:
No es una pregunta que tenga una respuesta fácil.
Formalmente, en VB, un módulo es una clase cuyos miembros son todos
estaticos (Shared), que se importa implícitamente en todas las otras
unidades del proyecto que lo contiene.
Pero imagino que esa definición no te ayuda.
Las clases son "modelos" para la creación de objetos. Los módulos son
contenedores de funcionalidad de uso general.
Las clases representan objetos del universo de aplicación: Clientes,
Conexiones, Nodos de Red, Productos, Cuentas. Los módulos extienden el
lenguaje básico del modelo.
Normalmente las clases modelan cosas del mundo real. Los módulos simplemente
exportan funcionalidad.
Los módulos son un compromiso en el diseño de VB.Net, y no existen -al menos
no con ese nombre- en ningun otro lenguaje orientado a objetos.
He escrito un sólo proyecto "grande" en .Net: un sistema de control de
reservaciones y operaciones de tráfico para una linea aérea. Tiene 250
"tipos": 233 clases, 6 enumeraciones, 6 interfaces, 4 estructuras y 1
módulo. El módulo se llama "ManejoErrores" y expone dos métodos: DumpErrors
y Advertencia. De las clases, dos son puramente estáticas: idCredito y
Localizador: ambas usan metodos de hashing inverso para generar secuencias
unicas de caracteres para un identificador numerico. La unica diferencia es
que para notificar un error escribo «Advertencia("Nombre inválido, por favor
escriba <Apellidos>/<Nombres> Mr.|Mrs.|Ms.")» y en otro caso debo escribir
«Reserva.Localizador = Localizador.Localizador(Reserva.seqId)».
ManejoErrores se quedó como módulo porque fue importado directamente de mi
librería de VB6 al comienzo del proyecto.
El resto de las clases sí son clases reales. Tal vez alguna que otra tienen
un método estático, pero la mayoría son clases "puras".
¿Cuándo usar una clase? Cuando tienes una conexión "natural" entre los datos
y los procedimientos y necesitas estar seguro de que esa relación va a
mantenerse independientemente de todo lo que pase alrededor. Cuando dices (o
escribes) «elArticulo.RegistrarVariacionExistencia(elDetalle.Unidades)» la
operación afectará a "elArticulo", y no a cualquier variable global; los
efectos de la operación igualmente estarán confinados a "elArticulo", y no
alterarán nada fuera de él. Aun cuando haya otros articulos activos para ese
momento.
Pero ninguma explicación es mejor que la experiencia. Y la experiencia es
mejor si se combina con el estudio. "UML y patrones" de Craig Larman es una
buena aproximación práctica al analisis y diseño orientado a objetos (un
poco burocrática para mi gusto, pero muy ilustrativa). "Analisis y Diseño
Orientado a Objetos" de Grady Booch fue el libro que por fin logró abrirme
la mollera a lo que es la OO.
Salud!