IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

 C++ Discussion :

les classes en c++


Sujet :

C++

  1. #1
    Membre confirmé Avatar de colocolo
    Inscrit en
    Février 2007
    Messages
    166
    Détails du profil
    Informations forums :
    Inscription : Février 2007
    Messages : 166
    Par défaut les classes en c++
    salut;

    j'ai une classes GRAPH
    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
     
     
    class Graph {
     
    public:
      int ma[10][10];
      int nb;
     
     
     
      Graph (int );
      int ajouter_sommet();
      void retirer_sommet();
      void ajouter_arc();
      void retirer_arc();
      void Afficher();
      void Succ();
    };
    je veux utilser l'attribut nb de cette classe dans une autre classe
    comment je fait?

    merci

  2. #2
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    Avec "."

  3. #3
    Membre expérimenté
    Inscrit en
    Octobre 2007
    Messages
    285
    Détails du profil
    Informations personnelles :
    Âge : 44

    Informations forums :
    Inscription : Octobre 2007
    Messages : 285
    Par défaut
    Avec "."
    "...." ?
    Tout dépend de la fonctionnalité de la classe qui a besoin de Nb de graph.
    Soit CMaclasse qui à besoin de connaître Nb.

    1 1ère solution : Graph est un objet de CMaclasse
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    class CMaclasse
    {
    public:
      Graph m_mongraph;
      int m_unentierpourlasolution2;
     
    public:
      void unefonction();
    }
    dans la fonction :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    void CMaclasse::unefonction()
    {
      // On utilise Nb de Graph avec :
      int unentier = mongraph.nb;
    }
    1 2ème solution : Graph et CMaclasse appartienne à une troisième classe
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    class CTroisiemeClasse
    {
    public:
      Graph m_mongraph;
      CMaclasse m_maclasse;
     
    public:
      void unefonction3emeclasse();
    }
    dans la fonction :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    void CTroisiemeClasse::unefonction3emeclasse()
    {
      // On utilise Nb de Graph avec :
      m_maclasse.unentierpourlasolution2 = mongraph.nb;
    }
    Il y a 50 manières de transmettre une valeur d'une classe à l'autre. Dans les deux exemples précédent, c'est vraiment la base.
    On peut rajouter et rendre plus propre avec attributs privés, transmission par référence, déclaration dynamique... Toute la puissance de C++ bref.

    Donne nous plus d'infos (contexte...)
    Puis vas te ballader sur les tutos... pleins de choses interressante pour apprendre le C++.

  4. #4
    Membre Expert Avatar de Astraya
    Homme Profil pro
    Consommateur de café
    Inscrit en
    Mai 2007
    Messages
    1 048
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Consommateur de café
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2007
    Messages : 1 048
    Par défaut
    Bonjour!

    Je ne sait pas si j'ai très bien cerné ton porblème mais pour passer une varibale d'une classe a une autre étant donné que ton nb est public sa ne devrai pas être is compliqué.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    int get_nb(){
    return nb;}
     
    //ou tout simplement
     
    Classenécessitant.var1 = graph.nb
     
    //Pour fonction nécessiteuse
    fonction(graph.nb);
    Après comme dit JeromeBcx tout dépend de ton contexte et de sont utilisation.

  5. #5
    Membre confirmé Avatar de colocolo
    Inscrit en
    Février 2007
    Messages
    166
    Détails du profil
    Informations forums :
    Inscription : Février 2007
    Messages : 166
    Par défaut
    j'ai essayer de faire que ma nouvelle classe qui veux utiliser le "nb" est amie de la class graphe.
    class Graph {

    public:
    int ma[10][10];
    int nb;// je veux utiliser nb dans une fonction de la classe comp

    Graph (int );
    int ajouter_sommet();
    void retirer_sommet();
    void ajouter_arc();
    void retirer_arc();
    void Afficher();
    void Succ();
    friend class comp; // la classe comp et ami de la class graph
    };
    en complilons tjrs il ya une erreur de ce genre:
    error: "nb" was not declared in this scope

  6. #6
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 395
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 395
    Par défaut
    Montre comment tu essaies de l'utiliser.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  7. #7
    Membre très actif Avatar de elmcherqui
    Profil pro
    Inscrit en
    Février 2008
    Messages
    281
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : Maroc

    Informations forums :
    Inscription : Février 2008
    Messages : 281
    Par défaut
    tu met la classe sois en heritage ou en classe amie .

  8. #8
    Membre éclairé
    Inscrit en
    Juin 2007
    Messages
    359
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 359
    Par défaut
    Heu, je suis pas sûr, mais je crois qu'il veut voir comment utiliser une classe friend,...

    En fait le seul avantage (à ma connaissance) de déclarer une classe friend, c'est de permettre à la classe déclaré friend d'avoir accès à tous les attributs de ta classe, mais pour qu'elle puisse s'en servir, il faut bien lui dire quelle instance de la classe elle va utiliser,...

    Donc, en simple, ça donne un truc comme ça:

    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
    class une_class;
    class another_class;
    class une_class
    {
    	friend another_class;
    private:
    	int nbr;
    public:
    	une_class(){ nbr=5;}
    	void Affichage(){Console::WriteLine("mon nbr =");
    	Console::WriteLine(nbr);}
     
    } ;
    class another_class
    {	
    public:
    	void Affichage(une_class A){Console::WriteLine("le nbr de la classe qui m'a déclaré en ami est :");
    	Console::WriteLine(A.nbr);
    	}
     
    };
     
    int _tmain()
    {
        // TODO: Please replace the sample code below with your own.
    	une_class class1;
    	another_class class2;
    	class1.Affichage();
    	class2.Affichage(class1);
    	Console::ReadLine();
     
    	return 0;
    }
    En espérant que c'est pas HS,...

  9. #9
    Membre éclairé Avatar de befalimpertinent
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    561
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : Avril 2007
    Messages : 561
    Par défaut
    Citation Envoyé par colocolo Voir le message
    j'ai essayer de faire que ma nouvelle classe qui veux utiliser le "nb" est amie de la class graphe.
    Sauf cas particulier (plutôt rare finalement) essayes de ne pas trop utiliser friend. Utilises plutôt des getter/setter à la place.
    Crois moi le mot clé friend peut paraitre magic et répondre à ce que tu attend mais à terme c'est un très mauvais choix dans ton cas.
    Pour plus d'info cf

  10. #10
    Rédacteur

    Avatar de Davidbrcz
    Homme Profil pro
    Ing Supaéro - Doctorant ONERA
    Inscrit en
    Juin 2006
    Messages
    2 307
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ing Supaéro - Doctorant ONERA

    Informations forums :
    Inscription : Juin 2006
    Messages : 2 307
    Par défaut
    Citation Envoyé par befalimpertinent Voir le message
    Sauf cas particulier (plutôt rare finalement) essayes de ne pas trop utiliser friend. Utilises plutôt des getter/setter à la place.
    Friend c'est aml (sauf certains cas)
    getter/setter : c'est mal aussi !
    Car tu expose ton interface privé !
    On encapsule des comportements, pas des données.
    "Never use brute force in fighting an exponential." (Andrei Alexandrescu)

    Mes articles dont Conseils divers sur le C++
    Une très bonne doc sur le C++ (en) Why linux is better (fr)

  11. #11
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 395
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 395
    Par défaut
    SI les getters/setters étaient si mal que ça, pourquoi a-t-on inventé les Propriétés sur des plate-formes comme .Net et COM?
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  12. #12
    Membre Expert
    Avatar de coyotte507
    Profil pro
    Inscrit en
    Octobre 2006
    Messages
    1 327
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : Octobre 2006
    Messages : 1 327
    Par défaut
    Honnêtement je pense qu'il faut arrêter de dire que telle ou telle chose est mauvaise ou non.

    Chacun programme comme il le sent, il n'est pas interdit d'utiliser des char[] ni de l'héritage multiple, ni un sprintf, ni même de programmer en C++ sans la STL, en utilisant les nouvelles possibilités de la programmation objet du C++ avec des fonctions du C...

    Il n'est pas non plus interdit de mettre tous les membres en public pour ne pas avoir de setter/getter à utiliser, il n'est pas interdit de ne pas respecter à 100% le principe de l'encapsulation.

  13. #13
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut
    Salut,
    Citation Envoyé par coyotte507 Voir le message
    Honnêtement je pense qu'il faut arrêter de dire que telle ou telle chose est mauvaise ou non.

    Chacun programme comme il le sent, il n'est pas interdit d'utiliser des char[] ni de l'héritage multiple, ni un sprintf, ni même de programmer en C++ sans la STL, en utilisant les nouvelles possibilités de la programmation objet du C++ avec des fonctions du C...

    Il n'est pas non plus interdit de mettre tous les membres en public pour ne pas avoir de setter/getter à utiliser, il n'est pas interdit de ne pas respecter à 100% le principe de l'encapsulation.
    Si, dans l'absolu, tu as (en partie) raison, en pratique, c'est clairement une autre histoire.

    Si on insiste généralement sur le fait de préférer les capacités offertes par le C++ et par ses classes à toute possibilité équivalente héritée du C, c'est, avant tout parce que l'on se base sur les faits certain que:
    1. Les possibilités du C++ et de ses classes fonctionnent de manière généralement bien plus sécurisante que l'ensemble des fonctions équivalentes issues du C
    2. Même en étant particulièrement doué, tu mettra longtemps à faire seul (et sans doute moins bien) ce que de nombreuses personnes ont fait, en longtemps aussi, il faut quand même le signaler.
    3. Il est, finalement, bien plus facile de se rappeler d'une vingtaine de classes - même si elles disposent chacune d'une vingtaine de méthodes - en sachant à quoi elles servent, mais en étant sûr que leur implémentation est correcte et permet d'assurer une sécurisation suffisante du code (du point de vue des dépassements de capacités ou des fuites mémoire, par exemple) que d'avoir à gérer par soi-même l'ensemble des problèmes que ces classes et méthodes permettent d'éviter.

      D'autant plus que la plupart des classes ne présentent généralement qu'un nombre assez restreint de méthodes d'usage réellement courent (pour les autres, en connaissant les bons sites, et en sachant "que telle classe permet tel comportement", il est facile de retomber sur la méthode qui le met en oeuvre )
    4. Les mauvaise habitudes sont généralement tout à la fois plus faciles à prendre et plus difficiles à perdre que les bonnes. Au final, plus tu laisse quelqu'un s'enfermer dans un carcan de mauvaise habitudes, plus il lui sera difficile d'envisager de les abandonner au profit d'habitudes dont il peut très bien ne pas mettre l'efficacité en doute

    D'un autre côté, rien ne t'empêche d'essayer de couper une bûche avec un couteau à steak ou une lime à ongle... Mais tu avoueras qu'il est généralement plus facile de le faire avec la scie adaptée ou avec une bonne tronçonneuse .

    Dans tous les métiers, un des credo est que "le bon ouvrier utilise les bons outils" (sous entendu: les mieux adaptés à la situation).

    Les outils du programmeur, ce sont les langages.

    De manière générale, on peut distinguer trois grands types de langages:
    • les langages procéduraux
    • les langages fonctionnels
    • les langages (orientés) objets
    Chacun de ces types de langage est susceptible d'être "particulièrement" adapté à une situation donnée, et, au sein de ces différents types, il est souvent possible d'affiner le critère de sélection en vue de décider quel langage permettra d'arriver le plus facilement au but que l'on s'est fixé.

    Sans vouloir relancer un quelconque débat sur le thème du "quel langage est le meilleur", il faut bien être conscient que le C++ est clairement dans la catégorie des "langages (orientés) objets", même s'il a "le bon gout" de laisser la possibilité de choisir de travailler en procédural pur et simple.

    Cependant, il n'est pas rare de constater que, si tu décide de ne pas utiliser les capacités "objet" du C++, c'est qu'il existe un langage purement procédural (ou, pourquoi pas, fonctionnel) qui serait sans doute bien mieux adapté au but que tu poursuis

    Il est donc logique que l'on insiste pour inciter autant que faire se peut les "nouveaux venus" à utiliser le C++ pour ce qu'il est: un langage objet disposant de classes de nature à faciliter grandement le travail dans une grande majorité de situations.

    La différence qui existe entre les langages purement procéduraux et les langages dits "orientés objets" (ou "objets", pur et dur), c'est qu'ils permettent de s'abstraire des données réelles contenues dans les structures inévitables de données pour s'intéresser en priorité aux messages qu'elles véhiculent (qu'elles émettent ou qu'elles reçoivent)

    L'un des avantages immédiat est que le code qui utilise une structure de données conçue dans une optique objet sera plus pérenne que le code qui utilise une structure tout à fait équivalente conçue dans une optique purement procédurale.

    L'inconvénient majeur, car, rien n'est jamais ni tout blanc ni tout noir, est que cela nécessite sans doute une réflexion plus profonde en période de conception.

    En conclusion, je suis tout à fait d'accord avec toi quand tu réprouve les règles édictées "à l'emporte pièces" du genre de
    l'amitié, c'est mal
    tant il est vrai que, l'amitié est parfois utile - si pas nécessaire ou indispensable - dans certaines situations, même s'il reste important à veiller à ce que l'accès qu'elle autorise soit le moins intrusif possible ou du genre de
    les getters et setters, c'est mal
    ne serait-ce que parce que je préfère utiliser les terme "mutateurs" et "accesseurs" pour indiquer clairement qu'il ne s'agit pas *forcément* d'un simple return x; ou d'un simple x=valeur; mais qu'ils peuvent faire autre chose avant (ou après), mais aussi parce que j'estime que la décision de les proposer doit être évaluée en fonction des circonstances.

    Par contre, j'ai beaucoup plus de mal à être d'accord avec toi quand tu t'élève contre le principe de l'encapsulation.

    Je ne veux pas verser dans "l'encapsulation à tout prix", mais, comme l'encapsulation est quand même l'un des piliers du paradigme orienté objet, je reste persuadé qu'il reste préférable de ne rendre publics que les membres dont il apparait clairement qu'il n'est pas possible/opportun/sensé de les déclarer protégés ou privés.
    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

  14. #14
    Membre Expert
    Avatar de coyotte507
    Profil pro
    Inscrit en
    Octobre 2006
    Messages
    1 327
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : Octobre 2006
    Messages : 1 327
    Par défaut
    Koala01,

    je suis totalement d'accord avec ton post.

    Je ne m'élève pas du tout contre le principe de l'encapsulation, je voulais dire que quelques rares fois on pouvait avoir envie de passer outre et d'accéder à des données private. Je ne critique pas l'existence du mot-clé private ni du mot-clé protected.

    On encapsule des comportements, pas des données.
    D'ailleurs à y réfléchir, pour moi encapsuler c'était cacher des données, je crois que j'ai parlé sans savoir

    Enfin, je ne veux pas entrer dans un débat, je suis d'accord avec toi.

  15. #15
    Rédacteur

    Avatar de Davidbrcz
    Homme Profil pro
    Ing Supaéro - Doctorant ONERA
    Inscrit en
    Juin 2006
    Messages
    2 307
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ing Supaéro - Doctorant ONERA

    Informations forums :
    Inscription : Juin 2006
    Messages : 2 307
    Par défaut
    J'y suis peut être allé un peu fort dans mon 1er message .
    Donc, je reprend ;
    L'amitié c'est le mal dans 90% des cas car elle est mal utilisé.
    Pour moi, l'amitié ne devrait être utilisé que lorsque l'on doit scinder une classe en 2 pour X raisons ou dans des situations de ce genre.

    Les "mutateurs" et "accesseurs" sont peut être un peu moins le mal que l'amitié mais reste néanmoins assez mal utilisé dans une bonne partie des cas. (moi même des fois, j'en utilise et je sais alors que quelque chose ne va pas , mais comme c'est du code perso donc j'mef un peu ^^)

    En effet, même s'il permettent une vérification des données fournit dans le cas des mutateurs, il n'en reste pas moins qu'ils exposent l'interface privée d'une classe a ses utilisateurs. De fait, si la classe change, le code qui l'utilise risque de devoir changer.

    Dès lors, il faut priviligier une encapsulation des comportements dans les classes de telle sorte que même si on change la manière de réaliser ce comportement, l'utilisateur n'en sache rien.

    Enfin, comme la dit Koala, il faut aussi savoir quand même certain membre public. Néanmoins ces cas sont assez rare et devrait être - a mon avis - justifiés à chaque fois.

    Edit: lisez ce blog : http://blog.emmanueldeloget.com/ .C'est une vrai mine d'or sur la conception est ses principes.
    "Never use brute force in fighting an exponential." (Andrei Alexandrescu)

    Mes articles dont Conseils divers sur le C++
    Une très bonne doc sur le C++ (en) Why linux is better (fr)

  16. #16
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut
    En fait, tout dépend de si tes classes sont réellement des objet au sens propre (des objets pour lesquels on attend qu'il fournissent un certain nombre de services) ou s'il s'agit "tout simplement" de sécuriser les PODS (Plain Old Data Structures)...

    Si, et c'est conseillé, on n'a à faire qu'à des classes dont le but est de fournir certains services, les mutateurs deveinnent souvent inutiles, et, pour ce qui est de accesseurs, il s'agit de savoir s'il est sensé de faire que la classe fournisse le service de donner cette valeur.

    S'il s'agit de PODS, (exemple: un point 3D ), il deveint tout à fait cohérent de fournir des mutateurs et des accesseurs, sur des membres privés, de manière à permettre une meilleure pérennité des codes qui utilisent la classe...

    On voit donc bien qu'aucune règle trop ferme en la matière devient rapidement impossible à respecter
    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

  17. #17
    Membre expérimenté
    Inscrit en
    Octobre 2007
    Messages
    285
    Détails du profil
    Informations personnelles :
    Âge : 44

    Informations forums :
    Inscription : Octobre 2007
    Messages : 285
    Par défaut
    Citation Envoyé par brother2007 Voir le message
    bonjour c'est encore moi j'ai fait une petite erreur avant
    je vous donne un exemple de programme a la place qui
    j'espère pourra mieux vous aidez.
    brother2007,
    outre un décalage entre votre post et celui avisé de koala01, votre proposition ne fournit qu'une réponse dans un contexte particulier.

    Pour trouver la réponse, cela ne dépend pas de la technologie (objet, héritage, amitié, accesseur, ....), mais du contexte d'utilisation...
    Le problème vient du désir d'accéder à un attribut nb d'une classe A par une autre B. Avec seulement ces informations, il est très difficile de répondre au problème.
    En effet les quelques lignes suivantes illustres plusieurs solutions, non exhaustives...
    -Si la classe B propose de répondre à une problématique proche de celle de A (B plus spécifique A, ex: A=véhicule, B=moto) alors B devrait hériter de A.
    -Si la classe B répond à une autre problématique, il faudrait passer l'attribut nb en paramètre d'une fonction ou constructeur de B.
    -Enfin, la classe B propose des fonctionnalités plus globales que A, qui représente alors une sous fonctionnalité de B (équivalent à l'exemple de brother2007). Dans ce cas, A pourrait être un attribut de B, et nb serait accessible par le biais d'une méthode "get", ou plus généralement "accesseurs" (cf. Davidbrcz), et non pas directement accessible par attribut public.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [Taglibs] Utiliser les classes css ?
    Par PeteMitchell dans le forum Struts 1
    Réponses: 4
    Dernier message: 05/05/2007, 01h31
  2. Réponses: 31
    Dernier message: 30/03/2006, 16h57
  3. Les classes ne s'affichent pas
    Par karl3i dans le forum MFC
    Réponses: 8
    Dernier message: 26/01/2004, 14h52
  4. delocaliser les classe
    Par otb82 dans le forum Eclipse Java
    Réponses: 3
    Dernier message: 17/11/2003, 08h54
  5. Les classes amies en Delphi
    Par Bruno75 dans le forum Langage
    Réponses: 3
    Dernier message: 02/09/2003, 19h34

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo