3.3Programación orientada a objetos (clases) en WLangage
Lo esencial en 30 segundos
- La clase es el modelo, el objeto el ejemplar: los miembros llevan los datos, los métodos los tratamientos, el constructor inicializa.
- La encapsulación protege los datos sensibles detrás de métodos; la herencia especializa una base común sin duplicación.
- La POO no es obligatoria: Yacine la usa para las reglas de negocio ricas y las variantes de clientes, no por principio.
Mini-caso hilado — Yacine modela clientes y saldos pendientes
Yacine gestiona los clientes de la pyme de venta de material eléctrico en Orán: particulares, empresas e instaladores. Hasta ahora arrastraba variables dispersas y condiciones por todas partes para calcular un saldo pendiente y verificar la solvencia. Crea una clase Client con un constructor, un miembro de saldo pendiente y un método EstSolvable. Después hace que ClientEntreprise herede de Client para añadir un límite negociado, sin duplicar la base. Los miembros sensibles ya no se modifican directamente: todo pasa por EnregistreFacture y EstSolvable. Sin embargo, Yacine mantiene sus procedimientos de cálculo simples fuera de las clases: anota el reflejo: POO donde aporta claridad, no de forma sistemática.
Caso autónomo de esta sección: reaparece en el curso, el esquema, el guion y el reto de 48 h de la sección 3.3.
1. Clase, objeto, miembros y métodos
La programación orientada a objetos organiza el código en torno a objetos que agrupan datos y los tratamientos asociados. La clase es el modelo, el plano de construcción: la clase Client describe qué es un cliente y qué se puede hacer con él. El objeto, o instancia, es un ejemplar concreto creado a partir de esa clase. Los miembros son los datos del objeto —nombre, saldo pendiente— y los métodos los procedimientos que actúan sobre ellos. El constructor se llama automáticamente en la creación para inicializar el objeto.
2. Encapsulación, herencia, polimorfismo
La encapsulación agrupa datos y tratamientos y protege el acceso directo a los datos: se pasa por métodos, lo que garantiza el respeto de las reglas. La herencia crea una clase a partir de otra recuperando sus características y especializándolas: ClientEntreprise hereda de Client y añade su límite negociado sin duplicar la base. El polimorfismo permite llamar al mismo método sobre objetos diferentes, y cada uno responde según su clase.
3. POO útil, no obligatoria
La POO destaca en las aplicaciones complejas, las reglas de negocio ricas, el código destinado a reutilizarse y el trabajo en equipo. Pero no es obligatoria: una aplicación de gestión clásica se desarrolla muy bien en procedural, con procedimientos bien organizados en colecciones. El pragmatismo manda. Yacine usa una clase cuando un concepto lleva realmente reglas y un estado coherente —un cliente con su saldo pendiente— y mantiene procedimientos simples para los cálculos aislados.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Una clase Client que protege su saldo pendiente
Yacine encapsula el saldo pendiente y el control de solvencia en la clase:
Client est une classe
m_sCode est une chaine
m_sNom est une chaine
m_nEncours est un monetaire
PROCEDURE Constructeur(sCode est une chaine, sNom est une chaine)
m_sCode = sCode
m_sNom = sNom
m_nEncours = 0
FIN
PROCEDURE EnregistreFacture(nMontant est un monetaire)
m_nEncours = m_nEncours + nMontant
FIN
PROCEDURE EstSolvable(nPlafond est un monetaire) : booleen
RENVOIE m_nEncours <= nPlafond
FIN
FIN
cClient est un Client("CLI042", "Dupont Materiel Electrique")
cClient.EnregistreFacture(12500)
SI PAS cClient.EstSolvable(20000) ALORS
Info("Encours depasse : relance commerciale")
FINLectura: el saldo pendiente solo se modifica por EnregistreFacture, nunca directamente.
Lección: la regla de solvencia viaja con el dato al que se refiere.
Vocabulario de la sección
- Clase
- Modelo que describe los datos y los tratamientos de un concepto, a partir del cual se crean objetos.
Ejemplo sencillo: La clase Client describe el código, el nombre, el saldo pendiente y los métodos asociados.
Lo que no es: un objeto concreto como el cliente Dupont.
Reflejo: el plano de un concepto → la clase.
- Objeto (instancia)
- Ejemplar concreto creado a partir de una clase, con sus propios valores de miembros.
Ejemplo sencillo: cClient es una instancia de Client para Dupont Matériel Électrique.
Lo que no es: el modelo Client que todavía no tiene valores.
Reflejo: un ejemplar utilizable → un objeto.
- Encapsulación
- Protección de los datos de un objeto detrás de métodos que garantizan las reglas.
Ejemplo sencillo: El saldo pendiente solo cambia mediante EnregistreFacture.
Lo que no es: un miembro modificable directamente desde cualquier pantalla.
Reflejo: dato sensible → encapsulación.
- Herencia
- Creación de una clase a partir de otra recuperando su base y especializándola.
Ejemplo sencillo: ClientEntreprise hereda de Client y añade un límite negociado.
Lo que no es: recopiar todo el código de Client en una segunda clase.
Reflejo: especializar sin duplicar → herencia.
- Constructor
- Método llamado automáticamente en la creación de un objeto para inicializarlo.
Ejemplo sencillo: El constructor de Client fija el código, el nombre y un saldo pendiente a cero.
Lo que no es: un objeto creado con miembros sin inicializar.
Reflejo: inicializar en la creación → constructor.
En la práctica — En la práctica — Crear y usar una clase
- Cree una clase que represente un concepto de negocio (Client, Commande) con sus miembros y sus métodos, como Yacine.
- Añada un constructor para inicializar el objeto y proteja los miembros sensibles mediante encapsulación.
- Instancie un objeto y llame a sus métodos: datos y tratamientos viajan juntos.
- Si varias variantes comparten una base, utilice la herencia (ClientEntreprise) en lugar de duplicar el código.
Guion paso a paso — modelar un cliente como Yacine (5 min)
1) Identifique un concepto que lleva a la vez datos y reglas (cliente, pedido). 2) Enumere sus miembros y los métodos que deben protegerlos. 3) Escriba el constructor para garantizar una inicialización correcta. 4) Instancie un objeto en una pantalla y llame a sus métodos. 5) Si un caso vecino comparte la base, hágalo heredar en lugar de copiar el código.
Mantenga este criterio: una clase se justifica cuando el comportamiento y las reglas merecen viajar con los datos.
Modelo para copiar y pegar — la ficha de POO de Yacine
Classe : modele (donnees + methodes + constructeur)
Objet : instance concrete avec ses valeurs
Encapsulation : proteger les membres sensibles via des methodes
Heritage : specialiser un socle commun sans dupliquer
Pragmatisme : POO si regles riches / variantes / composants ; sinon proceduralUn cliente empresa
Yacine hace que ClientEntreprise herede de Client para añadir un límite negociado.
Un saldo pendiente incoherente
El saldo pendiente ya solo se modifica mediante EnregistreFacture: la regla está centralizada.
Un cálculo aislado
Yacine mantiene CalculeMontantTTC como procedimiento: no hay ningún dato de estado que encapsular.
Un constructor olvidado
Un objeto creado sin inicialización produce un saldo pendiente absurdo: Yacine añade un constructor.
✓ Buenas prácticas
- Modelar una clase cuando unas reglas acompañan a los datos.
- Proteger los miembros sensibles con la encapsulación.
- Usar la herencia para especializar, no para recopiar.
✗ Errores frecuentes
- Crear una clase que solo lleva datos.
- Dejar modificar un saldo pendiente o un estado directamente.
- Querer objetivarlo todo por principio.
Puntos clave
- Clase = modelo, objeto = instancia, miembros = datos, métodos = tratamientos.
- El constructor inicializa el objeto en su creación.
- Encapsulación y herencia evitan incoherencias y duplicación.
- La POO es útil pero no obligatoria: el pragmatismo manda.
Reto 48 h — aplícalo mañana
Como Yacine, elija en su aplicación un concepto que lleve reglas (cliente, pedido, producto) y cree una clase con sus miembros, un constructor y dos métodos. Proteja un miembro sensible mediante encapsulación y después añada una variante por herencia. Escriba por último en una frase por qué mantiene el resto en procedimientos: la POO debe clarificar, no complicar.
- Distingo clase, objeto, miembros, métodos y constructor.
- Comprendo encapsulación, herencia y polimorfismo.
- Sé decidir cuándo la POO aporta claridad.
Preguntas frecuentes
¿Hay que usar la POO en un proyecto WinDev de gestión clásica?
No necesariamente: una aplicación de gestión se desarrolla muy bien en procedural estructurado, con procedimientos organizados en colecciones. La POO resulta interesante cuando un concepto lleva reglas ricas, cuando la encapsulación es necesaria, cuando varias variantes comparten una base o cuando el código debe reutilizarse como componente. Es una herramienta, no una obligación.
¿Qué diferencia hay entre una estructura y una clase?
La estructura solo agrupa datos, sin comportamiento ni protección: perfecta para transportar una dirección o una línea importada. La clase agrupa datos y tratamientos, con constructor, encapsulación y herencia: se justifica cuando hay comportamiento y reglas que garantizar. En caso de duda, empiece por la estructura si solo necesita agrupar informaciones.
¿Qué agrupa una clase en WLangage?