Discussion :

[Liezon]

Bonjour,

Je ne savais pas trop où poster ma réflexion, donc j'ai choisi le forum général de débats sur le langage Java. Le concept que je vais vous présenter s'est appuyé sur le développement Java.

Le problème soulevé, à l'origine de cette réflexion sur la Programmation par contexte, est que le langage Objet ne fait pas apparaître les états et les relations entre les objets.

Ainsi une brouette reste une brouette, qu'elle soit remplie ou vide. Une brouette peut soit être remplie, soit être vidée. Une brouette remplie peut-elle être remplie ? Une brouette vide peut-elle être vidée ? Le concept objet ne fait pas la différence entre les états.

Actuellement, la programmation, quelle qu'elle soit, est "à plat". Tous les états dans lesquels passent les objets sont décrits dans le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class Brouette {
    private boolean estRemplie = false;
    private Contenu contenu = null;
 
    public void remplir(Contenu contenu) {
        if(!this.estRemplie) {
            this.contenu = contenu;
            this.estRemplie = true;
        }
    }
 
    public void vider() {
        if(this.estRemplie) {
            this.contenu = null;
            this.estRemplie = false;
        }
    }
 
}

Cette programmation nécessite de gérer les exceptions dans le cas où l'on remplit une brouette déjà remplie. Mais dans un projet conséquent, cette erreur ne peut se voir qu'à l'exécution, dans, justement, un contexte d'exécution bien particulier.

L'idée de la programmation par contexte est de pouvoir définir des variables de contexte, et programmer suivant un contexte bien particulier.

Ma brouette reste une brouette, je crée donc un objet Brouette :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public class Brouette {
 
}

Via un plug-in de mon EDI, je définis que la classe "Brouette" peut prendre 2 états "Vide" et "Remplie". Lorsque je sélectionne l'état "Vide", j'écris donc le code relatif à cet état :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public class Brouette {
    public void remplir(Contenu contenu);
}

Et c'est tout, car "remplir" est la seule méthode accessible dans l'état "Vide". La méthode "remplir" permet de changer l'état de la Brouette en "Remplie".

Une fois que ma classe est définie pour l'état "Vide", je change cet état dans mon contexte EDI, et je le passe à "Remplie". Ma classe devrait ressembler alors à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public class Brouette {
 
}

Aucune méthode n'a été définie pour l'état "Remplie". Je crée donc ce qu'il me faut :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public class Brouette {
    private Contenu contenu;
 
    public void vider();
}

Certaines méthodes peuvent être partagées, comme la méthode "pousser()" de la brouette, qui peut être réalisée dans l'état "Vide" et/ou "Remplie".



Cette programmation par contexte est donc une sur-couche à la programmation actuelle, qui permet de distinguer les relations entre les objets.

J'aimerais avoir votre avis sur ce concept, s'il possède un autre nom, s'il a été discuté, quels sont les avantages, les inconvénients.

Je vous remercie,

Stéphane.

[william44290]

je n'ai pas d'info particulière a ce sujet.
peut-être : http://www.abrillant.com/doc/design/index.htm#state

Mais je trouve cette réflexion pertinente.

j'essaye de préfixer le nom de mes méthodes afin de faire apparaitre ce concept.

je rapprocherais cela du cycle de vie des objets.

A suivre ....

[CyaNnOrangehead]

Je croie qu'il faut distinguer deux chose dans un programme, la partie compilée et la partie runtime.
Les états, étants dynamiques sont par définition des entités appartenants au runtime. Ce que tu propose c'est de créer des états à cheval entre le compilé et le runtime.ce qui me parlait impossible. À moins que le code ne s'auto-génère, ce qui donne les problèmes que l'on connais avec les langages de scripts (effets de bord ect...)

De toute façon, dans le cas ou ta brouette est vide, que ce passe t'il si ton client essaie de la vidée à nouveau?
Ça créer une exception.

[Logan Mauzaize]

Tu t'es pris d'amour pour les vieux sujets ?

Le problème n'est pas la programmation "par contexte" (?) mais la programmation "par contrat" qui fait pleinement parti de l'objet mais pas de Java ...

L'opération remplir d'une brouette à l'état rempli peut ne rien faire, ou bien renvoyer une erreur, ou bien renvoyé un booléen (ex: l'API des Collections).

Si une opération est valable en fonction d'un ou plusieurs états et sans que l'objet lui-même n'est conscience de tous les états possibles dans ce cas il faut utiliser le(s) pattern(s) Mediator & State. Une page dédiée à ce sujet : http://c2.com/cgi/wiki?DynamicClassification.

[CyaNnOrangehead]

Oui c'est un peu comme appeller un méthode qui n'existe pas avec de l'introspection, ça fait un truc dégeulasse.

Pour les vieux postes, j'ai pris des sujet au hazard qui m'interessait pour faire connaissance.... Vrai que je suis fâché avec le calendrier. Je ne me souviens plus de ma date de naissance, c'est dire.