3.3Object-oriented programming (classes) in WLangage
The essentials in 30 seconds
- The class is the model, the object the instance: members carry the data, methods the processing, the constructor initialises.
- Encapsulation protects sensitive data behind methods; inheritance specialises a common base without duplication.
- OOP is not mandatory: Yacine uses it for rich business rules and customer variants, not on principle.
Running mini-case — Yacine models customers and outstanding balance
Yacine manages the customers of the SME trading electrical equipment in Oran: individuals, companies and installers. Until now, he carried scattered variables and conditions everywhere to calculate an outstanding balance and check solvency. He creates a class Client with a constructor, an outstanding-balance member and a method EstSolvable. Then he makes ClientEntreprise inherit from Client to add a negotiated ceiling, without duplicating the base. Sensitive members are no longer modified directly: everything goes through EnregistreFacture and EstSolvable. Yacine nevertheless keeps his simple calculation procedures outside the classes: he notes the reflex: OOP where it clarifies, not systematically.
Self-contained case for this section: it returns in the course, diagram, script and 48h challenge of section 3.3.
1. Class, object, members and methods
Object-oriented programming organises code around objects that group data and the processing associated with it. The class is the model, the blueprint: the class Client describes what a customer is and what can be done with it. The object, or instance, is a concrete copy created from that class. The members are the object's data — name, outstanding balance — and the methods the procedures that act on them. The constructor is called automatically at creation to initialise the object.
2. Encapsulation, inheritance, polymorphism
Encapsulation groups data and processing and protects direct access to the data: you go through methods, which guarantees the rules are respected. Inheritance creates a class from another by taking its characteristics and specialising them: ClientEntreprise inherits from Client and adds its negotiated ceiling without duplicating the base. Polymorphism allows the same method to be called on different objects, each reacting according to its class.
3. OOP useful, not mandatory
OOP shines for complex applications, rich business rules, code meant to be reused and teamwork. But it is not mandatory: a classic management application develops very well in procedural style, with procedures well organised in collections. Pragmatism wins. Yacine uses a class when a concept really carries rules and a consistent state — a customer with their outstanding balance — and keeps simple procedures for isolated calculations.
🔎 Concrete example — 🔎 Concrete example — A class Client that protects its outstanding balance
Yacine encapsulates the outstanding balance and the solvency check in the class:
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")
FINReading: the outstanding balance is modified only by EnregistreFacture, never directly.
Lesson: the solvency rule travels with the data it concerns.
Section vocabulary
- Class
- Model describing the data and processing of a concept, from which objects are created.
Simple example: The class Client describes the code, the name, the outstanding balance and the associated methods.
What it is not: a concrete object such as the customer Dupont.
Reflex: the blueprint of a concept → the class.
- Object (instance)
- Concrete copy created from a class, with its own member values.
Simple example: cClient is an instance of Client for Dupont Matériel Électrique.
What it is not: the Client model that has no values yet.
Reflex: a usable copy → an object.
- Encapsulation
- Protection of an object's data behind methods that guarantee the rules.
Simple example: The outstanding balance changes only via EnregistreFacture.
What it is not: a member modifiable directly from any screen.
Reflex: sensitive data → encapsulation.
- Inheritance
- Creation of a class from another by taking its base and specialising it.
Simple example: ClientEntreprise inherits from Client and adds a negotiated ceiling.
What it is not: copying all the code of Client into a second class.
Reflex: specialise without duplicating → inheritance.
- Constructor
- Method called automatically at the creation of an object to initialise it.
Simple example: The Client constructor sets the code, the name and a zero outstanding balance.
What it is not: an object created with uninitialised members.
Reflex: initialise at creation → constructor.
In practice — In practice — Creating and using a class
- Create a class representing a business concept (Client, Commande) with its members and methods, like Yacine.
- Add a constructor to initialise the object and protect sensitive members through encapsulation.
- Instantiate an object and call its methods: data and processing travel together.
- If several variants share a base, use inheritance (ClientEntreprise) rather than duplicating the code.
Step-by-step script — model a customer like Yacine (5 min)
1) Identify a concept that carries both data and rules (customer, order). 2) List its members and the methods that must protect them. 3) Write the constructor to guarantee correct initialisation. 4) Instantiate an object in a screen and call its methods. 5) If a neighbouring case shares the base, make it inherit instead of copying the code.
Keep this criterion: a class is justified when the behaviour and rules deserve to travel with the data.
Copy-paste template — Yacine's OOP sheet
Class : model (data + methods + constructor)
Object : concrete instance with its values
Encapsulation : protect sensitive members via methods
Inheritance : specialise a common base without duplicating
Pragmatism : OOP if rich rules / variants / components; otherwise proceduralA company customer
Yacine makes ClientEntreprise inherit from Client to add a negotiated ceiling.
An inconsistent outstanding balance
The outstanding balance is now modified only by EnregistreFacture: the rule is centralised.
An isolated calculation
Yacine keeps CalculeMontantTTC as a procedure: no state data to encapsulate.
A forgotten constructor
An object created without initialisation produces an absurd outstanding balance: Yacine adds a constructor.
✓ Best practices
- Model a class when rules accompany the data.
- Protect sensitive members through encapsulation.
- Use inheritance to specialise, not to copy.
✗ Common pitfalls
- Creating a class that only carries data.
- Letting an outstanding balance or a status be modified directly.
- Wanting to objectify everything on principle.
Key takeaways
- Class = model, object = instance, members = data, methods = processing.
- The constructor initialises the object at its creation.
- Encapsulation and inheritance avoid inconsistencies and duplication.
- OOP is useful but not mandatory: pragmatism wins.
48h challenge — apply it tomorrow
Like Yacine, choose in your application a concept that carries rules (customer, order, product) and create a class with its members, a constructor and two methods. Protect a sensitive member through encapsulation, then add a variant through inheritance. Finally write in one sentence why you keep the rest as procedures: OOP must clarify, not complicate.
- I distinguish class, object, members, methods and constructor.
- I understand encapsulation, inheritance and polymorphism.
- I know how to decide when OOP brings clarity.
Frequently asked questions
Should you use OOP in a classic WinDev management project?
Not necessarily: a management application develops very well in structured procedural style, with procedures organised in collections. OOP becomes interesting when a concept carries rich rules, when encapsulation is needed, when several variants share a base or when the code must be reused as a component. It is a tool, not an obligation.
What is the difference between a structure and a class?
A structure groups only data, with no behaviour or protection: perfect for carrying an address or an imported line. A class groups data and processing, with a constructor, encapsulation and inheritance: it is justified when there is behaviour and rules to guarantee. When in doubt, start with the structure if you only need to group information.
What does a class group in WLangage?