Bienvenue sur le forum !

Si vous souhaitez rejoindre la communauté, cliquez sur l'un de ces boutons !

Qt 5 : 5.9.1 - Qt Creator : 4.4.0 - Qt Installer : 2.0.3 - JOM : 1.1.2 - Qt Build suite : 1.7.0 - VS Qt 5 : 2.0.0

Class abstraite ou non ?

Bonjour,
je me rend compte dans mon projet que j'aurai besoin d'une sorte de classe "OUTILS" qui me permettrai de rassembler des fonctions qui n'ont aucun rapport entre ele et qui me servirai quand bon me semble , et sans avoir creer d'objet OUTILS au préalable.

Quelle approche dois je faire?
Est ce forcément une classe abstraite?
Est ce simplement des fonctions statiques?

Réponses

  • je penche plutôt pour une classe avec des fonctions statiques.
  • OK ca serai donc du genre:
    class outils
    {
    public:
    static bool ping_process();
    static bool isRunning(char *name);
    static QString getName();
    };
    et aprés je l'utilise ainsi :
    if(outils::getName()=="aaaa")
    alors blabla
    C'est bien ca ?
  • exactement, maintenant cela est une solution. Attends peut-être un peut pour voir si d'autre te propose des solution plus intéressantes.
  • September 2008 modifié
    je verrais plutot des fonctions derrière un namespace du genre "utilitaryTools", ou alors une classe singleton...
  • oula je ne sais pas utiliser les namespaces dans ce cas là.. mais apparement en utilisant des fonctions static , j'arrive à faire ce que je veux :)
  • salut,

    amha la bonne question à se poser au départ est : qu'auront en commun mes différentes classes concrètes qui dériveront de 'Outils' ?

    - si la réponse est "rien, je veux juste un endroit où stocker des fonctions", alors tu peux faire autant de classes statiques que d'outils dont tu as besoin. Chaque classe statique sera alors vue comme 'une collection de fonctions indépendantes ayant trait à une partie spécifique de ton application' (par exemple les outils pour le chargement des données, des outils pour la GUI, ...). L'idé&e de regrouper les fonctions par classes statiques te permettra de gérer plus finement les dépendances avec les autres classes de ton programme. Par exemple la classe outil pour le chargement des données ne fera un "include" que des classes de données ; celle pour la gui, qu'un "include" vers les classes de la GUI, etc...

    - si la réponse est "elles auront toutes en commun certaines choses, comme une fonction retournant leur nom, une fonction pour appliquer un traitement, ..." et/ou "je veux pouvoir stocker toutes les instances de mes outils dans un conteneur (genre liste chainée)" alors ton besoin se rapproche plus de la notion "d'interface" (en parlant 'modélisation objet' ou 'Java'), ce qui équivaut à une classe abstraite en C++
  • On est pas en java ici !
    Le C++ offre la possibilité d'utiliser des fonctions libres, alors pourquoi s'en priver ?

    (comprendre que je +100 la réponse avec les namespaces)
  • Davidbrcz said:
    On est pas en java ici !
    Et alors ? :rolleyes:
    Les grands principes 'objet' restent les mêmes qu'on développe en Java, C++, SmallTalk ou n'importe quel autre langage OO.

    Le mot 'interface' n'est pas un gros mot en C++, il nomme un concept générique en modélisation objet.
    En l'occurence une classe abstraite pure (ie. une classe qui ne comporte que des fonctions abstraite).
    Le C++ offre la possibilité d'utiliser des fonctions libres, alors pourquoi s'en priver ?
    T'as fourni aucun argument là, donc je te retourne la question: pourquoi vaudrait-il mieux utiliser des fonctions libres ? :rolleyes:

    On parle de modélisation. Il n'y a pas qu'une possibilité et qu'un seul choix pertinent qui peut s'appliquer à tous les cas de figure.
    C'est ce que j'essayais de montrer avec mon post: en fonction de la présence de fonctionnalités qui sont communes à chaque outil, il peut être pertinent de tout faire dériver d'une classe commune. De même, si les outils doivent pouvoir être instanciés, stockés, exécutés dynamiquement (concept du pattern factory et de collection de pointeurs de classe abstraite).
    (comprendre que je +100 la réponse avec les namespaces)
    Perso, je m'abstiendrai de plussoyer une solution tant qu'on n'aura pas cerné les besoins de rockt13fr.
    C'est eux seuls (les besoins) qui doivent déterminer la solution la plus adaptée, pas une préférence personnelle ou une 'guerre de clochers'.
  • Salut,

    Ma petite pierre au débat:
    > sans plus de détails, un namespace contenant des fonctions libre a ma préférence. La raison est que si elle n'ont aucun lien entre elles, alors il n'y a pas de classe (et encore moins de singleton !).
    > Sans vouloir troller, les principes objets n'incluent pas de placer des classes partout :) cf le contenu de (opérations sur des objets répondant à certains contrats).
    > Plus de détails seraient évidemment bienvenus pour que chacun y voie plus clair :D
Connectez-vous ou Inscrivez-vous pour répondre.