Discussion :

[Francis Walter]

Bonjour,

Je vous pr�sente un tutoriel sur les pr�conditions en C++ de Andrzej Krzemieński : https://akrzemi1.developpez.com/tuto...remiere-partie
Il s'agit de la premi�re partie d'une s�rie de quatre �pisodes que nous allons faire l'effort de traduire et publier dans les jours � venir. Cette premi�re partie a �t� traduite par kurtcpp que l'�quipe de la r�daction tient � remercier sans oublier les autres contributeurs qui ont aid� � la correction.

N'h�sitez pas � commenter le contenu de ce premier article en r�pondant � cette discussion.

P.-S. Si vous d�sirez contribuer aux traductions de ressources C++, vous pouvez me contacter par MP.



Les meilleurs cours et tutoriels pour apprendre la programmation C++

[RPGamer]

Excellente id�e que cette traduction. Inspir� par un autre article sur le sujet, j'avais r�dig� mes propres macros pour la validation de pr�dicats par le compilateur dans un simple fichier .hpp et c'est plutot efficace.

contract.hpp

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
#ifndef __CONTRACT_HPP
#define __CONTRACT_HPP
 
#include <Uncopyable.hpp>
#include <type_traits>
#include <cassert>
 
/*!
 * \macro   require
 * \brief   Vérifie la validité d'une précondition.
 */
#if defined(CONTRACT_NO_PRECONDITION) || defined(CONTRACT_NO_CHECK)
    #define require(contract, text)
#else
    #define require(contract, text) assert(contract && text)
#endif
 
/*!
 * \macro   ensure
 * \brief   Vérifie la validité d'une postcondition.
 */
#if defined(CONTRACT_NO_POSTCONDITION) || defined(CONTRACT_NO_CHECK)
    #define ensure(contract, text)
#else
    #define ensure(contract, text) assert(contract && text)
#endif
 
/*!
 * \macro   invariant
 * \brief   Vérifie la validité d'un invariant.
 */
#if defined(CONTRACT_NO_INVARIANT) || defined(CONTRACT_NO_CHECK)
    #define invariant(contract, text)
#else
    #define invariant(contract, text) assert(contract && text)
#endif
 
/*!
 * \macro   invariants
 * \brief   Débute un bloc d'invariants de classe.
 */
#define invariants(classname) friend class InvariantsChecker<classname>; void _contract_check_invariants() const
 
/*!
 * \macro   check_invariants
 * \brief   Vérifie la validité des invariants de classe.
 */
#if defined(CONTRACT_NO_INVARIANT) || defined(CONTRACT_NO_CHECK)
    #define check_invariants()
#else
    #define check_invariants() _contract_check_invariants()
#endif
 
/*!
 * \macro   static_invariants
 * \brief   Débute un bloc d'invariants statiques de classe.
 */
#define static_invariants(classname) static void _contract_check_static_invariants() const
 
/*!
 * \macro   check_static_invariants
 * \brief   Vérifie la validité des invariants statiques de classe.
 */
#if defined(CONTRACT_NO_INVARIANT) || defined(CONTRACT_NO_CHECK)
    #define check_static_invariants()
#else
    #define check_static_invariants() _contract_check_static_invariants()
#endif
 
/*!
 * \class   InvariantsChecker
 * \brief   Vérifie la validité des invariants en début et en fin de scope.
 */
template <typename T>
class InvariantsChecker : private Uncopyable
{
    private:
 
        T *instance;
 
    public:
 
        InvariantsChecker(T *instance) :
            instance(instance)
        {
#if !defined(CONTRACT_NO_INVARIANT) && !defined(CONTRACT_NO_CHECK)
            instance->_contract_check_invariants();
#endif
        }
 
        ~InvariantsChecker()
        {
#if !defined(CONTRACT_NO_INVARIANT) && !defined(CONTRACT_NO_CHECK)
            instance->_contract_check_invariants();
#endif
        }
};
 
#endif // __CONTRACT_HPP

On peut alors facilement l'utiliser :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
int divide(int dividend, int divisor)
{
    require(divisor != 0, "Division par zéro indéfinie.");
    return dividend / divisor;
}

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
class Square
{
    private:
 
        size_t width;
        size_t height;
 
        invariants(Square)
        {
            invariant(width == height, "Un carré a 4 côtés égaux.");
        }
 
    public:
 
        Square(size_t width, size_t height) : 
            width(width), height(height)
        {
            check_invariants();
        }
        void resize(size_t width, size_t height)
        {
            InvariantsChecker<Square> check(this);
            this->width = width;
            this->height = height;
        }
        size_t getWidth() const
        {
            InvariantsChecker<Square> check(this);
            return width;
        }
        size_t getHeight() const
        {
            InvariantsChecker<Square> check(this);
            return height;
        }
};

[Francis Walter]

Bonjour,

Je vous annonce la deuxi�me partie de la s�rie de tutoriels sur les pr�conditions en C++ �crits par Andrzej Krzemieński. Elle a �t� traduite par kurtcpp.

Lire le tutoriel : Pr�conditions en C++ - Partie 2

Dans ce billet, je continuerai � partager mes r�flexions sur les pr�conditions. Il traitera un peu de la philosophie qui est derri�re le concept des pr�conditions (et des bugs), et �tudiera la possibilit� de mettre � profit le compilateur pour v�rifier certaines pr�conditions. Plusieurs lecteurs ont fourni des retours utiles dans mon pr�c�dent billet, j'essaierai de les incorporer � celui-ci.

Autres ressources du m�me auteur : Blog de Andrzej Krzemieński.

[RPGamer]

En r�utilisant les macros pr�c�dentes, faciles � mettre en oeuvre, on peut r�aliser des "classes contractuelles" permettant d'imposer un contrat-type � une s�rie de classes filles mais aussi de g�rer les cas probl�matiques d'appels r�cursifs ou de retours multiples. Exemple :

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
class ContractualClass
{
    private:
 
        virtual int doFunc(int n) // cette fonction est un exemple de retour multiple sans contrat
        {
            if (n > 0)
            {
                return 1/n;
            }
            else
            {
                return 2/n;
            }
        }
 
    public:
 
        int func(int n)
        {
            require(n != 0, "n différent de 0.");
            int ret = doFunc(n);
            ensure(ret >= -2 && ret <= 1, "Valeur de retour dans l'intervalle [-2, 1].");
            return ret;
        }
};
 
class InheritedContractClass : public ContractualClass
{
    private:
 
        virtual int doFunc(int n)
        {
            return 10*n; // violation du contrat de la classe mère !
        }
};

On peut m�me imaginer red�finir un nouveau contrat qui entre dans le domaine du contrat h�rit� :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
class InheritedContractClass : public ContractualClass
{
    public:
 
        int func(int n)
        {
            int ret = ContractualClass::func(n);
            ensure(ret >= -2 && ret <= 0, "Valeur de retour dans l'intervalle [-2, 0].");
            return ret;
        }
};

Ici la valeur de retour ne doit plus �tre comprise dans l'interval [-2, 1] mais dans un nouvel intervalle [-2, 0].

[Luc Hermitte]

Cela s'appelle le pattern NVI, pour Non-Virtual-Interface.
Par contre, cela se corse en cas d'h�ritage de multiple "interface/contrats" pour traiter les invariants.

-> http://luchermitte.github.io/blog/20...e-c-plus-plus/

[RPGamer]

Par contre, cela se corse en cas d'h�ritage de multiple "interface/contrats" pour traiter les invariants.

Avec l'approche que je donne, chaque impl�mentation (doFunc()) poss�de une fonction d'appel public (func()) v�rifiant les invariants. Il n'y a donc aucune confusion sur le contrat. En revanche, un d�veloppeur imprudent pourrait all�ger le contrat en red�finissant la fonction d'appel public de fa�on erron�e mais �a entre aussi dans le cadre du changement de port�e permis par l'h�ritage C++ par exemple. En principe on ne le fait pas, � moins d'avoir une tr�s bonne raison.

[Luc Hermitte]

Ta v�rification d'invariant n'est pas factoris�e : � chaque fonction, tu dois v�rifier les invariants courants et enfants, plus les pr�conditions, et � la sortie: les invariants (courant et enfants) plus les post-conditions. Ca c'est sur un seul contrat.

Arrive le second contrat, l'invariant porte maintenant sur les deux contrats et sur la classe concr�te. Cela veut dire que les fonctions du contrat 1 doivent v�rifier les contrats venant du contrat 2 et de la classe concr�te qu'il ne connait pas.

Ce n'est pas si simple quand on doit tout faire � la main. Ce qui me fait penser que j'avais �t� d��u par P0287R0, il ne respecte pas le LSP, voire cela fait tout le contraire. J'esp�re qu'ils corrigeront le tir.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
// OK, we can not relax preconditions as we have already seen
double g(double);
double (*pg)(double x) [[expects: x != 0]] = &g; // ERROR.
 
 // but we can strengthen them ...
double f(double x) [[expects: x >= 0]];
double (*pf)(double) = &f; // OK.

[RPGamer]

Oui effectivement, c'est ce que j'ai en t�te en appellant la fonction de la classe m�re lors de sa red�finition. Il est n�cessaire de le faire manuellement mais �a n'est pas une limitation uniquement li�e � la programmation par contrat. Il est possible de red�finir une fonction dans une classe fille sans appeler la fonction de la classe m�re, ce qui est assez casse-gueule.

Si je prend un exemple bidon de 2 h�ritages :

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
class ContractualClass1
{
    private:
 
        virtual int doFunc(int n) = 0;
 
    public:
 
        int func(int n)
        {
            require(n != 0, "n différent de 0");
            int ret = doFunc(n);
            ensure(ret >= -2 && ret <= 1, "Valeur de retour dans l'intervalle [-2, 1].");
            return ret;
        }
};
 
class ContractualClass2 : public ContractualClass1
{
    private:
 
        virtual int doFunc(int n)
        {
            if (n > 0)
            {
                return 5/n;
            }
            else
            {
                return 6/n;
            }
        }
};
 
class ContractualClass3 : public ContractualClass2
{
    public:
 
        int func(int n)
        {
            int ret = ContractualClass2::func(n);
            ensure(ret >= -2 && ret <= -1, "Valeur de retour dans l'intervalle [-2, -1].");
            return ret;
        }
};
 
int main()
{
    ContractualClass2 instance2;
    instance2.func(-7);
 
    ContractualClass3 instance3;
    instance3.func(-7);
 
    return 0;
}

Le contrat de la classe 1 reste v�rifi�.

[Luc Hermitte]

Tes contrats ne sont pas orthogonaux.
As-tu regard� l'exemple que je donne dans mon lien ?

[RPGamer]

Tes contrats ne sont pas orthogonaux.

A mon sens �a n'a pas lieu d'�tre. L'h�ritage multiple est utile pour l'impl�mentation d'interfaces et les interfaces �tant d�pourvues de donn�es membres, elles sont d�pourvues d'invariants.
De plus, la seule chose qu'on peut esp�rer d'un contrat, c'est qu'il soit appliqu� tel quel ou qu'il soit durci. Un mix de contrats, possiblement antagonistes, n'a pas de sens, ne correspond � aucune logique.

As-tu regard� l'exemple que je donne dans mon lien ?

Ton blog o� le ton post sur reddit?

[Luc Hermitte]

Tout l'int�r�t des interfaces et d'isoler les responsabilit�s pour les avoir les plus atomiques possibles -> c'est l'ISP.
Les objets concret peuvent alors impl�menter plusieurs interfaces en toute qui�tude dans la mesure o� elles seront orthogonales. C'est le cas d'h�ritage multiple qui marche sans trop de soucis. C'est bien bien pour �a qu'il est celui gard� en Java.
Je ne dis pas que chaque utilisation d'h�ritage multiple est pertinente, etc. Juste que parmi les pertinentes, on a justement des interfaces orthogonales, et que l� o� �a devient int�ressant, c'est quand ces interfaces sont en fait des contrats.

Pour le lien, je parlai du billet de blog, exemple avec l'h�ritage multiple de contrats.

[koala01]

Salut,

A mon sens �a n'a pas lieu d'�tre. L'h�ritage multiple est utile pour l'impl�mentation d'interfaces et les interfaces �tant d�pourvues de donn�es membres, elles sont d�pourvues d'invariants.

Ca, c'est une vision tr�s... java de ce que sont les interfaces! Elle est impos�e en java pour �viter les probl�mes li�s � l'h�ritage en losange (ou en diamant, comme tu veux) pour l'unique raison que toute classe h�rite forc�ment -- de mani�re directe ou indirecte -- d'une classe Object.

Mais, si tu y porte un tout petit peu d'attention, tu te rendras compte que la notion d'interface en java (et le mot cl� implements qui y est rattach�) r�agit exactement de la m�me mani�re que la notion de classe ou de structure dans un contexte d'h�ritage, en respectant scrupuleusement le LSP.

D�s lors, si l'on remet les pendules � l'heure pour ce qui concerne la notion d'interface, et que l'on consid�re que c'est "un ensemble regroupant un certain nombre de comportement destin�s � travailler correctement de concert dans un but clairement d�termin�" (et tu avoueras que cette d�finition correspond s�rieusement � la notion d'interface ) on se rend compte que c'est exactement la m�me chose qu'une classe, surtout en C++, vu qu'il ne dispose pas de la possibilit� de faire la distinction.

D�s lors, prenons l'exemple une interface IPositionnable. En java, tu devrais avoir quelque chose ressemblant �

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
public interface IPositionnable{
    public void moveTo(Position newPos);
    public void move(Type diffX, Type diffY /*, Type diffZ*/);
};
public class MaClasse implements IPositionnable{
/* il faut définir les comportements hérités de IPositionnable dans toutes les classes
 * implémentant cette interface
 */
};

Mais, il n'y a rien qui nous emp�che en C++ d'avoir quelque chose ressemblant �

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
20
21
22
23
24
25
26
class IPositionnable{
public:
    void moveTo(Position const & newPos){
        pos_=newPos;
    }
    void move(Type diffX, Type diffY /*, Type diffZ*/){
        pos_ = Position(pos_.x()+diffX, pos_.y()+diffY/*,pos.z()+diffZ*/);
    }
    Type x() const{
        return pos_.x();
    }
    Type y() const{
        return pos_.y();
    }
    /*
    Type z() const{
        return pos_.z()
    }
    */
private:
    Position pos_;
};
class MaClass : public IPositionnable{
/* on n'a même plus besoin de faire quoi que ce soit pour supporter l'interface IPositionnable
 */
};

voire, pourquoi pas, mieux encore :

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
template <typename CRTP, typename V, typename F>
class IPositionnable{
public:
    using value_t = V;
    using flag_t = F;
    using pos_t = Position<value_t, flag_t>;
    void moveTo(pos_t const & newPos){
        pos_ = newPos;
    }
    template <typename U = F,
               typename = typename std::enable_if<std::is_same<U, Flag2D>::value>::type>
    void move(value_t diffX, value_t diffY){
        pos_=pos_t{pos_.x()+diffX, pos_.y()+diffY};
    }
    template <typename U = F,
               typename = typename std::enable_if<std::is_same<U, Flag3D>::value>::type>
    void move(value_t diffX, value_t diffY, value_t diffZ){
        pos_=pos_t{pos_.x()+diffX, pos_.y()+diffY, pos_.z()+diffZ};
    }
 
    value_t x() const{
        return pos_.x();
    }
    value_t y() const{
        return pos_.y();
    }
    template <typename U = F,
               typename = typename std::enable_if<std::is_same<U, Flag3D>::value>::type>
    value_t z() const{
        return pos_.z()
    }
private:
    pos_t pos_;
};
class MaClasse : public IPositionnable<MaClasse, double, Flag3D>{
    /* il n'y a plus rien à faire en ce qui concerne l'interface IPositionnable */
};

(la version template de IPositionnable est faite � main lev�e, il y a peut �tre quelques corrections � apporter )

la classe IPositionnable correspond bel et bien � la notion d'interface (c'est une classe qui regroupe un ensemble de comportements "destin�s � travailler ensemble"), et pourtant, elle dispose de "tout ce qu'il faut" pour pouvoir d�finir les comportements en question.

Mieux encore, la version template de cette classe permet, gr�ce au CRTP, d'�viter que l'interface serve de "glue artificielle" pour regrouper deux hi�rarchies de classes entre elles sous pr�texte "qu'elles sont toutes les deux positionnables".

En deux mots comme en cent, la restriction impos�e par java en ce qui concerne la notion d'interface est sp�cifique � java et n'est due qu'au fait que ce langage a effectivement forc� la distinction "physique" entre les notions de classes et d'interfaces, alors que conceptuellement parlant, il n'y a absolument rien que pourrait faire une classe qu'une interface ne pourrait faire (� moins que ce soit le contraire )

Mais, du coup, on se rend donc aussi compte que les invariants destin�s � garantir le bon fonctionnement de l'interface se trouvent... au niveau de l'interface, et non de la classe qui l'impl�mente

[RPGamer]

A mon sens il n'y a pas de vision "Java" de l'interface. Java a simplement une philo plus assistante. L'interface "impose" l'impl�mentation d'une interface, c-�-d d'une s�rie de fonctions membres ou m�thodes ici (implicitement publics) qui forment tout ou partie du service de la classe impl�mentante. Par exemple une interface "Positionnable" imposerait � toute classe l'impl�mentant de d�finir des fonctions membres permettant � toutes ses instances d'�tre positionn�es (dans un syst�me polaire ou cart�sien par exemple). A partir de l�, une interface avec des donn�es membres, � fortiori des donn�es membres priv�es qui plus est, n'a a mon avis pas grand sens. En tout cas �a n'est plus interface, c'est un mix entre une interface et une classe, une sorte de classe abstraite?

Pour les contrats orthogonaux, j'ai bien compris le probl�me mais mis � par se casser les dents, je ne vois pas l'int�r�t de prendre le risque d'avoir des contrats non compatibles ou en tout cas dont le m�lange donnerait quelque chose de farfelu � respecter pour l'utilisateur.

[Luc Hermitte]

NB: j'ai r�pondu trop vite tout � l'heure.
Effectivement, une interface pure � la Java n'a pas exactement d'�tat. Est-ce pour autant qu'elle ne peut pas avoir d'invariant ? Je n'en suis pas s�r. On peut toujours exprimer l'invariant avec les informations publiques mises � disposition par la classe. p.ex:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
[[inv: capacity() <= size()]] struct IBufferedContainer;
[[inv: is_sorted(begin(), end())]] struct ISortedContainer;
 
struct sorted vector : IBufferedContainer, ISortedContainer;

[RPGamer]

Peut-�tre. Conceptuellement, la notion de contrat peut �ventuellement �tre �tendue � tous composants (donn�es, fonction, sous-classe, etc.) et toutes op�rations (appel, instanciation, h�ritage, composition, etc.). C'est une question de possibilit�s offertes par le langage (et d'int�r�t pratique surtout). En l'occurence C++ ne le peut pas encore et avec une interface adieux NVI.

[koala01]

A mon sens il n'y a pas de vision "Java" de l'interface. Java a simplement une philo plus assistante. L'interface "impose" l'impl�mentation d'une interface, c-�-d d'une s�rie de fonctions membres ou m�thodes ici (implicitement publics) qui forment tout ou partie du service de la classe impl�mentante. Par exemple une interface "Positionnable" imposerait � toute classe l'impl�mentant de d�finir des fonctions membres permettant � toutes ses instances d'�tre positionn�es (dans un syst�me polaire ou cart�sien par exemple).

Non, la seule chose qu'impose la notion d'interface (et que j'ai par malheur oubli� de citer dans mon intervention pr�c�dente) est effectivement d'�tre abstraite.

Mais il y a d'autres moyen d'assurer cette restriction que l'utilisation de fonction virtuelles pures � la mani�re java! : si tu places le destructeur de l'interface (et tant qu'� faire, le constructeur, juste pour respecter le principe du miroir), dans l'accessibilit� prot�g�e, tu obtiens bel et bien une classe qui n'est pas instanciable en tant que telle, mais qui l'est au travers des classes qui en d�rivent.

Ainsi, si on modifie un tout petit peu les codes que j'ai pr�sent�s plus haut pour leur donner la forme de

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
20
21
22
23
24
25
26
27
28
29
30
31
class IPositionnable{
public:
    void moveTo(Position const & newPos){
        pos_=newPos;
    }
    void move(Type diffX, Type diffY /*, Type diffZ*/){
        pos_ = Position(pos_.x()+diffX, pos_.y()+diffY/*,pos.z()+diffZ*/);
    }
    Type x() const{
        return pos_.x();
    }
    Type y() const{
        return pos_.y();
    }
    /*
    Type z() const{
        return pos_.z()
    }
    */
protected:
    /* il n'y a de toutes façons pas de sens à permettre la destruction d'une instance
     * dérivée alors qu'on la connait comme étant du type de l'interface, 
     * un destructeur protégé et non virtuel fait donc pleinement l'affaire
     */
    ~IPositionnable() = default;
   /* et tant qu'à faire, pour respecter le principe du miroir */
   IPositionnable(Position const & p=Position{}):pos_(p){
   }
private:
    Position pos_;
};

ou sous la forme template proche de

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
template <typename CRTP, typename V, typename F>
class IPositionnable{
public:
    using value_t = V;
    using flag_t = F;
    using pos_t = Position<value_t, flag_t>;
    void moveTo(pos_t const & newPos){
        pos_ = newPos;
    }
    template <typename U = F,
               typename = typename std::enable_if<std::is_same<U, Flag2D>::value>::type>
    void move(value_t diffX, value_t diffY){
        pos_=pos_t{pos_.x()+diffX, pos_.y()+diffY};
    }
    template <typename U = F,
               typename = typename std::enable_if<std::is_same<U, Flag3D>::value>::type>
    void move(value_t diffX, value_t diffY, value_t diffZ){
        pos_=pos_t{pos_.x()+diffX, pos_.y()+diffY, pos_.z()+diffZ};
    }
 
    value_t x() const{
        return pos_.x();
    }
    value_t y() const{
        return pos_.y();
    }
    template <typename U = F,
               typename = typename std::enable_if<std::is_same<U, Flag3D>::value>::type>
    value_t z() const{
        return pos_.z()
    }
 
protected:
    /* il n'y a de toutes façons pas de sens à permettre la destruction d'une instance
     * dérivée alors qu'on la connait comme étant du type de l'interface, 
     * un destructeur protégé et non virtuel fait donc pleinement l'affaire
     */
    ~IPositionnable() = default;
   /* et tant qu'à faire, pour respecter le principe du miroir */
   IPositionnable(pos_t const & p=pos_t{}):pos_(p){
   }
private:
    pos_t pos_;
};

tu obtiens bel et bien quelque chose qui ne peut �tre instanci� qu'au travers des classes qui en d�rivent, et le fait que les comportements expos�s soient effectivement d�finis au niveau de la classe de base n'en font pas moins des classes pr�sentant toutes les notions indispensables � la notion d'interface

Apr�s, que tu ailles plus loin pour pouvoir mettre en place des politiques de positionnement en syst�me polaire ou cart�sien ne correspond qu'� un "d�tail d'impl�mentation" (qui pourrait, le cas �ch�ant, �tre lui aussi d�fini � l'aide d'un flag particulier dans la version template)

A partir de l�, une interface avec des donn�es membres, � fortiori des donn�es membres priv�es qui plus est, n'a a mon avis pas grand sens. En tout cas �a n'est plus interface, c'est un mix entre une interface et une classe, une sorte de classe abstraite?

uniquement parce que la vision que tu as d'une interface est biais�e par les restrictions impos�es par un langage (qui, pour notre malheur, est sans doute le langage qui a r�ellement donn� naissance � la notion d'interface).

Mais � partir du moment o� tu consid�re la notion d'interface comme une notion de conception pure, les r�gles impos�es par un langage particulier n'ont forc�ment plus cours, vu qu'une notion conceptuelle est forc�ment ind�pendante de tout langage.

Et quand tu t'affranchis des r�gles impos�es par java, tu te rend compte que la seule qualit� impos�e par une interface est de ne pouvoir �tre instanci�e qu'au travers d'une classe qui impl�mente l'interface en question.

Bien sur, les fonctions virtuelles pures sont l'une des solutions dont on dispose pour y arriver, mais je viens de d�montrer qu'il en existe d'autres et, � partir de ce moment l�, on n'en a plus rien � foutre si l'interface dispose des d�tails d'impl�mentations permettant de d�finir pr�cis�ment les comportements auxquels nous sommes en droit de nous attendre de la part de l'interface.

[RPGamer]

C'est dommage qu'on s'�loigne du sujet de base mais je fais pleinement la diff�rence entre une classe abstraite et une interface (qui est aussi abstraite par la force des choses). A mon avis ls interfaces ne sont pas plus Javaesques que la PpC est Eiffeilesque (petit retour au sujet )

En ajoutant une impl�mentation dans ton interface, tu prives l'utilisateur de d�finir sa propre impl�mentation car la force de l'interface est justement d'imposer l'interface et non l'impl�mentation. Un exemple comme celui-ci me para�t bon � ce sujet :

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
// interface "flottant"
struct Floatable
{
    virtual void moveForward(...) = 0;
    virtual void moveBackward(...) = 0;
    virtual void turn(...) = 0;
};
 
// interface "volant"
struct Flyable
{
    virtual void takeOff(...) = 0;
    virtual void land(...) = 0;
    virtual void fly(...) = 0;
};
 
// interface "roulant"
struct Rollable
{
    virtual void accelerate(...) = 0;
    virtual void brake(...) = 0;
    virtual void turn(...)  = 0;
    virtual void honk() = 0;
};
 
// classe abstraite "véhicule"
class Vehicle
{
    private:
 
        unsigned int fuelLevel;
 
    protected:
 
         Vehicle() : fuelLevel(0) {}
         virtual ~Vehicle() = default;
 
    public:
 
        virtual void fillUp(unsigned int fuel)
        {
            fuelLevel += fuel;
        }
};
 
// avion à réaction
class JetPlane : public Vehicle, private Flyable
{
    private:
 
        unsigned int numPassengers;
        ...
 
    public:
 
        JetPlane() : Vehicle(), numPassengers(0) {}
 
        virtual void takeOff(...)
        {
            // décollage horizontal
        }
 
        virtual void land(...)
        {
            // attérrissage horizontal
        }
 
        virtual void fly(...)
        {
            // vol en haute altitude
        }
 
        void boarding()
        {
            // embarquement des passagers
        }
};
 
// hélicoptère
class Helicopter : public Vehicle, private Flyable
{
    public:
 
        Helicopter() : Vehicle() {}
 
        virtual void takeOff(...)
        {
            // décollage vertical
        }
 
        virtual void land(...)
        {
            // attérissage vertical
        }
 
        virtual void fly(...)
        {
            // vol en basse altitude
        }
};
 
// bâteau cargo
template <typename C>
class CargoBoat : public Vehicle, private Floatable
{
    private:
 
         C cargo; // notre cargaison
 
    public:
 
       CargoBoat() : Vehicle() {}
 
       virtual void moveForward(...)
       {
           // on fait avancer le cargo
       }
 
       virtual void moveBackward(...)
       {
           // on fait une marche arrière, très utile pour l'entrée en port
       }
 
       virtual void turn(...)
       {
           // on tourne à droite ou à gauche
       }
 
       void load(C cargo)
       {
           // on charge la cargaison
       }
};
 
// voiture de sport
class SportCar : public Vehicle, private Rollable
{
    private:
 
        Color color;
        Brand brand;
 
    public:
 
         SportCar(Color color, Brand brand) : 
            Vehicle(),
            color(color),
            brand(brand)
         {}
 
         virtual void accelerate(...) 
         {
             // on fait une petite acceleration
         }
 
         virtual void brake(...)
         {
             // on freine, il faut bien!
         }
 
         virtual void turn(...)
         {
             // on tourne à droite ou à gauche
         }
 
         virtual void honk()
         {
             // biiip !
         }
};

On va ainsi �tre capable de d�finir d�finir ce qu'est un v�hicule volant par exemple, sans pour autant pr�ciser la fa�on dont il vole, att�rri, etc. L'impl�mentation est l'affaire des classes. On peut alors par exemple facilement les regrouper dans un container, faire d�coller tous les v�hicules volants au m�me moment ou je ne sais quoi. Dans cet exemple pour qu'un v�hicule puisse �tre consid�r� comme tel, il doit forc�ment pouvoir faire le plein puisqu'il est �quip� d'un moteur (peu importe lequel). Il faut donc d�finir le remplissage du r�servoir � carburant et surtout le niveau de carburant restant. On pourrait retrouver un contrat au niveau de la classe Vehicle pour imposer un carburant � base de p�trol par exemple puis durcir le contrat sur les classes en fonction du type pr�cis de carburant n�cessaire.

[koala01]

C'est dommage qu'on s'�loigne du sujet de base mais je fais pleinement la diff�rence entre une classe abstraite et une interface (qui est aussi abstraite par la force des choses). A mon avis ls interfaces ne sont pas plus Javaesques que la PpC est Eiffeilesque (petit retour au sujet )

En ajoutant une impl�mentation dans ton interface, tu prives l'utilisateur de d�finir sa propre impl�mentation car la force de l'interface est justement d'imposer l'interface et non l'impl�mentation

D'abord, on se rend compte, pour beaucoup d'interface, il est tout � fait possible de d�finir des comportements "par d�faut" qui s'av�rent "suffisants et corrects" dans la plupart des situations, et, de plus, je ne vois absolument pas ce qui pourrait emp�cher l'utilisateur de l'interface de (re)d�finir un comportement particulier pour les quelques cas o� le comportement "par d�faut" ne conviendrait pas.

Dans la version non template que je donne, il n'y a en effet absolument rien qui interdise de d�clarer les fonctions membres virtuelles, au m�me titre qu'il n'y a absolument rien qui nous oblige � les d�clarer comme virtuelles pures

Et, dans la version template, il n'y a absolument rien qui nous interdise de pr�voir une sp�cialisation (partielle ou totale) en cas de besoin

On va ainsi �tre capable de d�finir d�finir ce qu'est un v�hicule volant par exemple, sans pour autant pr�ciser la fa�on dont il vole, att�rri, etc. L'impl�mentation est l'affaire des classes. On peut alors par exemple facilement les regrouper dans un container, faire d�coller tous les v�hicules volants au m�me moment ou je ne sais quoi. Dans cet exemple pour qu'un v�hicule puisse �tre consid�r� comme tel, il doit forc�ment pouvoir faire le plein puisqu'il est �quip� d'un moteur (peu importe lequel). Il faut donc d�finir le remplissage du r�servoir � carburant et surtout le niveau de carburant restant. On pourrait retrouver un contrat au niveau de la classe Vehicle pour imposer un carburant � base de p�trol par exemple puis durcir le contrat sur les classes en fonction du type pr�cis de carburant n�cessaire.

Mais qu'est ce qui nous emp�che de d�finir un comportement par d�faut si l'on est capable d'en trouver un qui puisse s'av�rer "correct et suffisant" dans la majorit� des cas

En dehors de l'approche de la notion d'interface telle que pr�sent�e par java, la r�ponse est simple : absolument rien. Et c'est encore plus vrai dans le sens o� C++ nous fournit �norm�ment de possibilit�s qui n'existent pas en java pour obtenir un r�sultat �quivalent!

[RPGamer]

Mais qu'est ce qui nous emp�che de d�finir un comportement par d�faut si l'on est capable d'en trouver un qui puisse s'av�rer "correct et suffisant" dans la majorit� des cas

C'est ce que je fais avec la classe abstraite Vehicle, c'est l'objectif de la classe abstraite (impl�menter ce comportement commun qui consiste � faire le plein), qui n'est pas exactement le m�me objectif que les interfaces, comme on peut le constater dans cet exemple. C'est pour �a que je le trouve particuli�rement bon pour mettre en avant cette diff�rence. En outre, les interfaces offrent de l'�volutivit� car il est directement admis qu'on ne connait pas tous les modes de propulsion possible. On permet donc tous types d'impl�mentations et on laisse cet responsabilit� aux classes filles.

[koala01]

C'est ce que je fais avec la classe abstraite Vehicle, c'est l'objectif de la classe abstraite (impl�menter ce comportement commun qui consiste � faire le plein), qui n'est pas exactement le m�me objectif que les interfaces, comme on peut le constater dans cet exemple. C'est pour �a que je le trouve particuli�rement bon pour mettre en avant cette diff�rence. En outre, les interfaces offrent de l'�volutivit� car il est directement admis qu'on ne connait pas tous les modes de propulsion possible. On permet donc tous types d'impl�mentations et on laisse cet responsabilit� aux classes filles.

Encore une fois, il semble que l'on soit plus ou moins d'accord sur le principal, bien qu'il reste quelques points de d�saccord sur les d�tails

Pour toi, un classe fournissant des comportements "par d�faut" sera consid�r�e comme une classe abstraite et ne sera pas une interface, alors que, de mon cot�, je ne vois absolument pas pourquoi nous ne pourrions d�signer ce genre de classe sous le terme d'interface

Mais pour ma part, je fais surtout la distinction entre le fait qu'une classe soit sp�cifiquement destin�e � servir de classe de base (par exemple : une classe Vehicle, dont h�riteraient aussi bien des classes Plane, Submarine ou Car), qui ont de fortes chances d'�tre abstraites "par nature", et toutes les classes qui ne font qu'exposer des comportements susceptibles d'�tre ajout�s � certaines classes (plus ou moins) concr�tes.

Pour moi, tout ce qui entre dans cette deuxi�me cat�gorie m�rite d'�tre d�sign� sous le terme g�n�rique d'interface, que les services expos�s nous proposent une impl�mentation par d�faut ou non.

Et, attention! je ne dis pas qu'il est syst�matiquement possible de fournir un comportement par d�faut pour les services expos�s par une interface; loin de l� Je dis juste que c'est juste une possibilit� qui peut �tre envisag�e si le langage utilis� le permet, et donc que la restriction du "aucun comportement n'est impl�ment� dans une interface" n'a de raison d'�tre que... dans le cadre d'un langage qui impose ce genre de restriction (comme java).