Soutenez-nous
Publicité
+ Répondre à la discussion
Page 2 sur 2 PremièrePremière 12
Affichage des résultats 21 à 23 sur 23
  1. #21
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 661
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 661
    Points : 15 582
    Points
    15 582

    Par défaut

    Cela ne suffit peut etre pas, mais, si doSomething réagit différemment en fonction de l'état dans lequel est l'objet tout en fournissant un résultat final similaire, c'est que les deux états peuvent être considérés comme cohérents.

    Le problème avec init, c'est que, a priori, l'objet est dans un état incohérent avant d'avoir été initialisé : une personne qui n'aurait pas de nom, ou un objet qui ne dispose pas des "caractéristiques minimales" qui permettent de le considérer comme tel.

    Or, a priori, ce n'est pas à l'utilisateur de veiller à ce que l'objet reçu soit dans un état cohérent, mais bien à la classe, qui doit s'assurer que l'objet créé sera dans un état cohérent dés le moment où l'objet est créé
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  2. #22
    r0d
    r0d est déconnecté
    Expert Confirmé Sénior

    Profil pro
    Inscrit en
    août 2004
    Messages
    4 005
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : août 2004
    Messages : 4 005
    Points : 4 937
    Points
    4 937

    Par défaut

    Ok alors, concrètement, qu'est-ce qu'un état cohérent?

    C'est ce que j'essaie de montrer: ce n'est pas aussi simple de déterminer ces notions de "utilisable", "cohérent", etc.

    Par exemple, il ne me semble pas absurde d'imaginer qu'une instance de classe puisse être utile même si tous ces champs (variables membres) ne sont pas remplis. Si récupère le champ nom (via l'accesseur getName) et que c'est une chaine vide, ce n'est pas forcément un problème et on peut peut-être continuer nos traitements, dans le cas où l'information n'est pas indispensable. Si maintenant getName() accède a des ressources externes susceptibles de lever une exception, on peut, de la même manière, imaginer récupérer cette exception et continuer nos traitements.

    Avant de continuer, y a-t-il une hérésie dans la situation que je décris dans ce paragraphe?

  3. #23
    Membre Expert Avatar de Flob90
    Homme Profil pro Florian Blanchet
    Etudiant en Optique
    Inscrit en
    août 2004
    Messages
    1 189
    Détails du profil
    Informations personnelles :
    Nom : Homme Florian Blanchet
    Âge : 23
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Etudiant en Optique

    Informations forums :
    Inscription : août 2004
    Messages : 1 189
    Points : 2 449
    Points
    2 449

    Par défaut

    @r0d: Je ne vois pas en quoi ma définition est insuffisante.

    Si ta fonction fait des choses différentes selon l'état, alors c'est qu'elle ne travaille pas seulement selon des invariants, rien de plus.

    Je ne suis pas chercheur en informatique théorique (même pas chercheur tout court), mais je suis convaincu que tu dois avoir des gens qui ont déjà définies tout ça de manière très rigoureuse (sans trop réfléchir, je dirais théorie des graphes et théorie des ensembles).

    Pour ton dernier message, un champs vide peut-être un état valide, c'est à toi, développeur, de choisir l'ensemble de tes états valides. Pas exemple, les pointeurs intelligents et les conteneurs, ont un état valide où ils ne référencent/contiennent rien.

    Par contre se retrouver avec un objet dont l'état n'est valide que pour une fonction (init) et ne sera valide qu'après un appel à cette fonction pour les autres fonctions, ca doit inciter à se demander si il n'y a pas une mauvaise répartition invariant/pré-conditions. Typiquement, est-ce que l'introduction d'un type supplémentaire ne permettrait pas de résoudre le problème ?
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
     
    //Avec init
    struct A
    {
      //Invariant A
      void init(/*needed params C*/)
      { /*Post-Condition B*/ }
     
      void foo()
      { /*Pre-Condition B*/ }
    }
     
    //Avec intérmédiaire
    struct BeforeA
    {
      //Invariant A
    }
     
    struct A
    {
      //Invariant A+B
      A(BeforeA, /*needed params C*/)
      { }
     
      void foo()
      { }
    }
    Après l'idéal serait que BeforeA ai une réalité sémantique, ça reste envisageable selon la situation selon moi.
    "We can solve any problem by introducing an extra level of indirection" Butler Lampson

    "N'importe quel problème peut être résolu en introduisant un niveau d'indirection supplémentaire" Butler Lampson (traduction libre)

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •