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 :

C est-il orienté objet?


Sujet :

C

  1. #1
    Inactif  
    Homme Profil pro
    Collégien
    Inscrit en
    Octobre 2012
    Messages
    78
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Octobre 2012
    Messages : 78
    Points : 0
    Points
    0
    Par défaut C est-il orienté objet?
    Le mot-clé struct est-il l'ancêtre du mot-clé class de la plupart des langages modernes? Du moins, les structures crées par struct sont des classes comme les autres, juste avec des arguments mais quand même une classe. D'autres similtudes existe entre les structures et les classes :
    -Les deux sont des types personnalisés.
    -Les deux contiennent des attributs
    -Les attributs des deux sont accessibles via la notation objet.attribut

    Et vous, qu'en pensez vous?
    Pensez-vous que struct est-il l'ancêtre de l'orienté objet? Pourquoi?
    Pensez-vous que C est orienté objet? Pourquoi?
    Pensez-vous que C++ et Objective-C aurait dû n'être que des nouvelles normes pour le C? Pourquoi?

  2. #2
    Membre éprouvé
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 1 821
    Points : 979
    Points
    979
    Par défaut
    Salut,

    C n'est pas orienté objet.
    Pour moi, un langage objet permet de standardiser et de simplifier la création d'objet.
    C'est très important de "standardiser" car au moins tout le monde travail de la même manière.
    L'utilisation des pointeurs en langage C est problématique car tu as directement accès à la mémoire => avec un langage objet, il y a une couche abstraction qui permet de déclarer automatiquement l'espace mémoire des objets et empêche de modifier certaines zone mémoire protégées.

    Pour moi le seul avantage du langage C est de pouvoir déclarer des variables globales : ça permet de gagner de l'espace mémoire par rapport à l'utilisation d'allocation dynamique d'espace mémoire (utilisée par les langages objet) mais ça complexifie les programmes et augmente le risque de faire du code buggé.
    => langage C utile pour des systèmes embarqués ou pour travailler proche du hardware (ex : création de drivers).

    La démarche de conception d'un programme C n'est pas la même que sur le C++.

  3. #3
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Citation Envoyé par sosolal Voir le message
    -La convention de nommage est la même (on commence par une majuscule).
    Attention, en C il est déconseillé de nommer quelque chose avec une majuscule : tout ce qui commence par un underscore et une majuscule est un identifant reservé (7.1.3 de la norme C99), et tout ce qui commence par E suivi d'une autre majuscule (ou d'un chiffre) est potentiellement utilisé pour les erreurs (errno.h), de meme pour FE_ suivi d'une majuscule (virgule flottante), LC_ majuscule (locale.h), FP_ majuscule (math.h), SIG majuscule et SIG_ majuscule (signal.h).

    Apres, si on considere qu'un objet peut contenir des attributs et des fonctions, alors non le C n'est pas oriente objet, meme s'il est tout a fait possible d'ecrire de telles choses en C.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  4. #4
    Inactif  
    Homme Profil pro
    Collégien
    Inscrit en
    Octobre 2012
    Messages
    78
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Octobre 2012
    Messages : 78
    Points : 0
    Points
    0
    Par défaut
    Citation Envoyé par boboss123 Voir le message
    avec un langage objet, il y a une couche abstraction qui permet de déclarer automatiquement l'espace mémoire des objets et empêche de modifier certaines zone mémoire protégées
    Documente-toi un peu : cela n'a rien avoir avec l'orienté objet

  5. #5
    Expert confirmé Avatar de ManusDei
    Homme Profil pro
    vilain troll de l'UE
    Inscrit en
    Février 2010
    Messages
    1 619
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : vilain troll de l'UE

    Informations forums :
    Inscription : Février 2010
    Messages : 1 619
    Points : 4 350
    Points
    4 350
    Par défaut
    Citation Envoyé par sosolal Voir le message
    -Les deux sont des types personnalisés.
    -Les deux contiennent des attributs
    -Les attributs des deux sont accessibles via la notation objet.attribut
    - Il y en a un des deux qui implémente la notion de constructeurs et destructeurs.
    - Il y en a un des deux qui implémente la notions de méthodes liées à un objet. C'est techniquement faisable en C, mais pas franchement intuitif ni prévu pour, et si t'insistes ça peut être la source de bugs immondes.
    - Il y en a un des deux qui implémente les notions d'héritage.
    Et on pourrait continuer longtemps comme ça.

    Donc non, C n'est pas orienté objet.
    http://www.traducteur-sms.com/ On ne sait jamais quand il va servir, donc il faut toujours le garder sous la main

  6. #6
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par sosolal Voir le message
    Documente-toi un peu : cela n'a rien avoir avec l'orienté objet
    Membres privés, membres publics ?

  7. #7
    Inactif  
    Homme Profil pro
    Collégien
    Inscrit en
    Octobre 2012
    Messages
    78
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Octobre 2012
    Messages : 78
    Points : 0
    Points
    0
    Par défaut
    J'ai bien dit ancêtre.
    PS : Et non, la portée n'a rien à voir avec l'orienté objet : Python est un des langages qui éxagèrent le plus sur l'orienté objet, et pourtant il n'a pas de portée.

  8. #8
    Expert éminent sénior
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    Mai 2010
    Messages
    3 214
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : Mai 2010
    Messages : 3 214
    Points : 10 136
    Points
    10 136
    Par défaut
    Ouaw un topic mort né
    Il n'y a pas de débat la dessus le langage C n'est pas un langage objet.
    C'est comme si je disais "Est que une lampe peut s'allumer ?" evidamment que oui et en peut se poser intérêt d'une telle question.

    Pensez-vous que C++ et Objective-C aurait dû n'être que des nouvelles normes pour le C
    Comment dire C++ est un autre langage que le C , c'est pas quelque petite amélioration.
    Après pour Objective-C c'est un autre langage qui n'a rien a voir avec le C.
    Parler de possibilité de normes pour des langages différent du C me semple inapproprié.

    Pour moi le seul avantage du langage C est de pouvoir déclarer des variables globales : ça permet de gagner de l'espace mémoire par rapport à l'utilisation d'allocation dynamique d'espace mémoire (utilisée par les langages objet) mais ça complexifie les programmes et augmente le risque de faire du code buggé.
    => langage C utile pour des systèmes embarqués ou pour travailler proche du hardware (ex : création de drivers).
    Le seul avantage du C c'est les variables globals ? (qui sont déconseillé je le rappel) c'est une blague...
    Les variables globals sont disponible sur plusieurs langages , non ça ne rend pas le code buggé , ça peut augmenté la complexité enfin c'est surtout que ça empêche un code modulaire et réutilisable.
    Après le C permet de tout faire autre que des drivers ou de embarqué.

  9. #9
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    Et non, la portée n'a rien à voir avec l'orienté objet : Python est un des langages qui éxagèrent le plus sur l'orienté objet, et pourtant il n'a pas de portée.
    Je sentais venir l'argument Python ^^

    Python n'est peut-être pas le meilleur exemple (enfin, ça dépend ce que tu souhaites montrer). C'est un langage très permissif, laissant une latitude maximale au programmeur. On pourrait presque dire que Python viole certains principes de base de l'OOP comme l'encapsulation avec une API sans accès à l'implémentation, le rajout de membre à une instance à la volée, etc.

    D'autre part, il y a quand même une notion de portée en Python mais elle est beaucoup moins stricte que celle qu'on avoir en C par exemple. J'ai moi-même été surpris du résultat affiché par f() :
    $ cat test.py 
    a = 2
    def f():
    	print a
    f()
    
    def g():
    	a = 42
    	print a
    g()
    print a
    $ python test.py 
    2
    42
    2
    $ 
    Enfin, je ne pense pas que Python soit le langage qui exagère le plus l'orienté-objet : tu peux écrire du code sans faire de classe. En revanche, c'est impossible en Java : il te faut forcer une classe qui va contenir le main().

  10. #10
    Membre éclairé
    Inscrit en
    Juillet 2012
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : Juillet 2012
    Messages : 231
    Points : 870
    Points
    870
    Par défaut
    Citation Envoyé par ManusDei
    - Il y en a un des deux qui implémente la notion de constructeurs et destructeurs.
    La notion de destructeur n’a rien à voir avec l’OO, c’est un détail d’implémentation.
    Les langages à GC (Java, Python, Ruby, …) n’ont pas de destructeurs donc ce ne sont pas des langages OO pour toi ?

    Citation Envoyé par Bktero
    Citation Envoyé par sosolal
    Documente-toi un peu : cela n'a rien avoir avec l'orienté objet
    Membres privés, membres publics ?
    Python n’a pas de private/public, pourtant il est plus OO que Java (en Java les fonctions ne sont pas de objets, les types primitifs non plus, …)

    Citation Envoyé par Bktero
    C'est un langage très permissif, laissant une latitude maximale au programmeur.
    Python ne te laisse pas faire n’importe quoi non plus (surtout au niveau du typage, c’est pas PHP ou Javascript non plus ) mais c’est vrai que, comme tout langage de script, il est assez souple (et donc permissif).

    Citation Envoyé par Bktero
    On pourrait presque dire que Python viole certains principes de base de l'OOP comme l'encapsulation avec une API sans accès à l'implémentation
    Je rappelle que « encapsulation is not information hiding » (mais les deux vont souvent de pair, c’est vrai)
    Cependant, tu peux restreindre l’accès aux attributs en Python (avec les décorateurs @property et @foo.setter).

    Pour les fonctions, Python utilise une convention (si le nom de la fonction commence avec deux underscores (genre __foo) alors elle doit être considéré comme privée).
    Attention, ce n’est pas imposée par le langage (tu peux y accéder quand même), juste une convention.
    Pourquoi ? Parce que si tu veux vraiment contourner private tu le peux (en C++ par example) et que « We're all consenting adults here » est le motto de Python donc GvR (Guido van Rossum) a décidé de ne pas ajouter ce mécanisme dans Python et de se baser sur la bienséance des développeurs (un choix discutable…).

    Citation Envoyé par Bktero
    le rajout de membre à une instance à la volée
    Ça c’est plus chiant par contre, c’est vrai.
    Cependant, je ne vois pas quel principe de l’OOP ça brise.

    Citation Envoyé par Bktero
    Enfin, je ne pense pas que Python soit le langage qui exagère le plus l'orienté-objet : tu peux écrire du code sans faire de classe. En revanche, c'est impossible en Java : il te faut forcer une classe qui va contenir le main().
    Et pourtant, Python est bien plus orienté objet que Java (les types primitifs sont des objets, les modules sont des objets, les fonctions sont des objets, …).
    Être orienté objet ce n’est pas tout mettre dans des classes.

    D’ailleurs, les classes ne sont pas nécessaires (JavaScript est OO mais prototype-based, pas class-based) et suffisantes pour avoir un langage objet.
    Ce qui caractérise vraiment la POO c’est :
    - encapsulation
    - polymorphisme
    - héritage
    Cf. ici (c’est wikipédia, mais des ouvrages sont cités).

    Cela dit, non, le C n’est pas un langage OO.
    Certes, on peut simuler les mécanismes OO, mais comme ça n’est pas intégré dans le langage alors le C n’est pas OO (contrairement au C++ par exemple).

  11. #11
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Citation Envoyé par grim7reaper Voir le message
    La notion de destructeur n’a rien à voir avec l’OO, c’est un détail d’implémentation.
    Les langages à GC (Java, Python, Ruby, …) n’ont pas de destructeurs donc ce ne sont pas des langages OO pour toi ?
    Il faut nuancer un peu les propos.
    Mais l'absence de destructeur empêche d'utiliser certains "bons principes" comme le RAII (?).
    De plus Java a un "destructeur" mais on est pas sûr qu'il soit appelé à chaque fois .

    Python n’a pas de private/public, pourtant il est plus OO que Java (en Java les fonctions ne sont pas de objets, les types primitifs non plus, …)
    Cet argument ne tient pas.
    Ce n'est pas parce qu'un langage est plus "OO" qu'un autre (est-ce que cela veut dire quelque chose déjà ?) qu'il fait tout mieux qu'un autre au niveau de l'OO.
    Les types primitifs ou les fonctions simples ne vont pas à l'encontre de l'OO au contraire, ils servent de "briques de bases" aux objets.

    Pourquoi ? Parce que si tu veux vraiment contourner private tu le peux (en C++ par example) et que « We're all consenting adults here » est le motto de Python donc GvR (Guido van Rossum) a décidé de ne pas ajouter ce mécanisme dans Python et de se baser sur la bienséance des développeurs (un choix discutable…).
    En C++ il faut vraiment le vouloir et le faire exprès en python, c'est peut être moins évident (d'après ce que je lis) :
    • si la méthode privée ne commence pas pas __, on ne sait pas qu'elle est privée
    • la tentation peut être un peu trop grande parfois


    Cependant, je ne vois pas quel principe de l’OOP ça brise.
    Encapsulation, si tu rajoute un membre, tu rajoute le membre à toutes les classes filles, ton membre peut accéder aux données private etc.


    Et pourtant, Python est bien plus orienté objet que Java (les types primitifs sont des objets, les modules sont des objets, les fonctions sont des objets, …).
    J'ai vraiment du mal avec cela "plus orienté objet" qu'un autre. Tu le mesures comment "l'orientabilité objet d'un langage" ?

  12. #12
    Membre éclairé
    Inscrit en
    Juillet 2012
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : Juillet 2012
    Messages : 231
    Points : 870
    Points
    870
    Par défaut
    Citation Envoyé par Neckara
    Mais l'absence de destructeur empêche d'utiliser certains "bons principes" comme le RAII (?).
    Et c’est même très chiant parfois.
    Heureusement que Java a introduit le try-with-resources en Java 7, ça améliore un peu le bousin mais bon ça ne vaut pas le RAII.

    Citation Envoyé par Neckara
    De plus Java a un "destructeur" mais on est pas sûr qu'il soit appelé à chaque fois .
    Tu parles de la méthode finalize?
    Ce n’est pas un destructeur (car ça ne peut pas être utilisé en tant que tel) car elle peut ne jamais être appelée durant la vie de l’application comme tu le mentionne.

    Citation Envoyé par Neckara
    Cet argument ne tient pas.
    Ce n'est pas parce qu'un langage est plus "OO" qu'un autre (est-ce que cela veut dire quelque chose déjà ?) qu'il fait tout mieux qu'un autre au niveau de l'OO.
    Certes, aucun langage n’est parfait.
    Cependant l’encapsulation de Python n’a rien à envier à Java (encapsulation = regrouper les données et les méthodes qui agissent dessus).
    Par contre, niveau restriction d’accès là Java s’en sort mieux en effet. Cependant, ce genre de choses n’a rien à voir avec la POO (Ada83 avait déjà ce genre de mécanismes public/private sans être pour autant un langage OO (il a fallu attendre Ada95 ou Ada2005)).

    Citation Envoyé par Neckara
    Les types primitifs ou les fonctions simples ne vont pas à l'encontre de l'OO
    Peut-être, mais ça fait tâche pour un langage comme Java qui est (était?) vendu comme un langage purement objet (alors que C++ se veux clairement multi-paradigme donc ça « choque » moins).

    Citation Envoyé par Neckara
    au contraire ils servent de "briques de bases" aux objets.
    Pas nécessairement.
    En Ruby par example, tout est objet (idem pour Smalltalk il me semble) donc les briques de bases sont des objets aussi.

    Citation Envoyé par Neckara
    En C++ il faut vraiment le vouloir et le faire exprès en python, c'est peut être moins évident
    Je suis tout a fait d’accord.
    J’ai bien dit que le choix de Python de se reposer sur la bienséances des programmeurs est discutable (et je ne trouve pas ça terrible non plus…).

    Citation Envoyé par Neckara
    Citation Envoyé par grim7reaper
    Citation Envoyé par Bktero
    le rajout de membre à une instance à la volée
    Ça c’est plus chiant par contre, c’est vrai.
    Cependant, je ne vois pas quel principe de l’OOP ça brise.
    Encapsulation, si tu rajoute un membre, tu rajoute le membre à toutes les classes filles, ton membre peut accéder aux données private etc.
    C’est à dire ? Je ne vois pas le rapport :/. Tu peux donner un exemple ou reformuler ?
    Bktero parle du rajout d’un membre à la volée à une instance par une classe.
    Mais je trouve ça très moche aussi…

    Citation Envoyé par Neckara
    J'ai vraiment du mal avec cela "plus orienté objet" qu'un autre. Tu le mesures comment "l'orientabilité objet d'un langage" ?
    C’est plus un ressenti qu’un truc vraiment technique (les seules explications qui me viennent à l’esprit sont bancales ou subjectives >_<), donc considérons ça comme un abus de langage de ma part. Désolé.

  13. #13
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par grim7reaper Voir le message
    Python n’a pas de private/public, pourtant il est plus OO que Java (en Java les fonctions ne sont pas de objets, les types primitifs non plus, …)
    Je vois ce que tu veux dire. C'est très juste d'ailleurs ! Je pensais surtout au fait qu'en Java, tu ne peux pas te passer de classe alors qu'en Python, tu peux programmer sans jamais créer de classe. La sensation d'OOP semble plus présente en Java qu'en Python (en tout cas, c'est mon ressenti quand je code).

    Python ne te laisse pas faire n’importe quoi non plus (surtout au niveau du typage, c’est pas PHP ou Javascript non plus ) mais c’est vrai que, comme tout langage de script, il est assez souple (et donc permissif).
    Oh la ! Non ! Et je ne dis pas ça : il est très souple, mais aussi très strict sur d'autres points (le type est dynamique mais fort).

    Je rappelle que « encapsulation is not information hiding » (mais les deux vont souvent de pair, c’est vrai)

    Cependant, tu peux restreindre l’accès aux attributs en Python (avec les décorateurs @property et @foo.setter).

    Pour les fonctions, Python utilise une convention (si le nom de la fonction commence avec deux underscores (genre __foo) alors elle doit être considéré comme privée).
    Attention, ce n’est pas imposée par le langage (tu peux y accéder quand même), juste une convention.

    « We're all consenting adults here » est le motto de Python donc GvR (Guido van Rossum
    Il est vrai qu'on peut faire de l'encapsulation sans faire une partie de cache-cache. J'apprécie que moyennement le moto de Python à ce niveau : ma boite fournie des solutions Java embarqué et nos clients viennent souvent du C. Quand je vois à quel point ils ont envie de briser l'encapsulation, je remercie Java de bien cacher la structure interne. Mais j'aime bien Python aussi hein !

    Le name mangling est une protection du pauvre si j'ai bonne mémoire, elle est contournable en 2 2. La propriété __all__ (c'est bien elle ?) d'un module est pas trop mal non plus mais ça reste facilement contournable quand même.

    Pour moi, cacher la structure interne pour vraiment rester à une API publique permet de respecter des principes de conception tels "programmer contre des interfaces, pas contre des implémentations" (le D de SOLID). Si tu donnes accès à ta structure interne, tu tentes les utilisateurs de programmer contre l'implémentation. Je suis d'accord qu'il faut savoir ce qu'on fait, mais de part ma (pourtant petite) expérience, c'est la porte ouverte aux pires choses

    le rajout de membre à une instance à la volée
    Ça c’est plus chiant par contre, c’est vrai.
    Cependant, je ne vois pas quel principe de l’OOP ça brise.
    Ché pas trop... Je ne sais pas si ça a un nom précis. C'est le concept qu'une classe est définie par son API. Je trouve ça un peu embêtant de pouvoir en rajouter à la volée : tu peux rajouter des méthodes ou des attributs à une instance qui du coup devient différent d'une autre instance de la même classe ou d'une classe fille à laquelle on n'aurait rien rajouté. Tu te retrouves avec 2 objets de même type qui sont différents.

  14. #14
    Membre éprouvé
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 1 821
    Points : 979
    Points
    979
    Par défaut
    Citation Envoyé par Bktero
    Membres privés, membres publics ?
    C'est bien de ça que je parlais. Je ne savais pas que certains langages objet n'avaient pas cette notion, désolé.


    Citation Envoyé par Kannagi Voir le message
    Le seul avantage du C c'est les variables globals ? (qui sont déconseillé je le rappel) c'est une blague...
    Je persiste et signe à dire que les variables globales ça peut être très utile : réduction de la conso de RAM et augmentation la rapidité du code... mais après faut faire gaffe aux risques d'erreurs


    Citation Envoyé par Kannagi Voir le message
    Les variables globals sont disponible sur plusieurs langages , non ça ne rend pas le code buggé , ça peut augmenté la complexité enfin c'est surtout que ça empêche un code modulaire et réutilisable.
    Ce que j'ai voulu dire, c'est que vu que le langage C augmente la compelxité du programme alors le risque de bug est augmenté par rapport à un langage objet (bien entendu, on peut faire un programme en C non buggé et un programme en langage objet buggé)


    Citation Envoyé par Kannagi Voir le message
    Après le C permet de tout faire autre que des drivers ou de embarqué.
    Je n'ai pas dit qu'on ne pouvait pas faire autre chose que des drivers et de l'embarqué avec : j'ai dit que c'est surtout utile pour ça.
    Pour moi, si tu as un nouveau projet à créer en partant de 0 (hors embarqué et driver), je ne vois pas l’intérêt de partir sur du C => dans quel cas tu utiliserais ce langage ?

  15. #15
    Membre éclairé
    Inscrit en
    Juillet 2012
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : Juillet 2012
    Messages : 231
    Points : 870
    Points
    870
    Par défaut
    Citation Envoyé par Bktero
    Citation Envoyé par grim7reaper
    Python ne te laisse pas faire n’importe quoi non plus (surtout au niveau du typage, c’est pas PHP ou Javascript non plus ) mais c’est vrai que, comme tout langage de script, il est assez souple (et donc permissif).
    Oh la ! Non ! Et je ne dis pas ça : il est très souple, mais aussi très strict sur d'autres points (le type est dynamique mais fort).
    Ma phrase doit être ambiguë mais c’est ce que je voulais dire.
    Python est souple mais ne te laisse pas faire n’importe quoi au niveau des types (comme PHP et Javascript)

    Citation Envoyé par Bktero
    Le name mangling est une protection du pauvre si j'ai bonne mémoire, elle est contournable en 2 2. La propriété __all__ (c'est bien elle ?) d'un module est pas trop mal non plus mais ça reste facilement contournable quand même.
    Bah tu sais, en C++ aussi je te contourne private en 2 2 :
    Code c++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    #define private public
    #include "ma_classe.h"
    #undef private
    Et voilà .
    C’est bien crade (on est d’accord) mais ça fonctionne
    Java demande à peine plus de boulot (il suffit d’utiliser l’introspection).

    Citation Envoyé par Bktero
    Ché pas trop... Je ne sais pas si ça a un nom précis. C'est le concept qu'une classe est définie par son API. Je trouve ça un peu embêtant de pouvoir en rajouter à la volée : tu peux rajouter des méthodes ou des attributs à une instance qui du coup devient différent d'une autre instance de la même classe ou d'une classe fille à laquelle on n'aurait rien rajouté. Tu te retrouves avec 2 objets de même type qui sont différents.
    C’est peut-être ce que Neckara essaye de m’expliquer.
    Moi aussi je n’aime pas vraiment cette fonctionnalité de Python et je ne l’ai jamais utilisé.

  16. #16
    Expert éminent sénior
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    Mai 2010
    Messages
    3 214
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : Mai 2010
    Messages : 3 214
    Points : 10 136
    Points
    10 136
    Par défaut
    Citation Envoyé par boboss123 Voir le message
    Je persiste et signe à dire que les variables globales ça peut être très utile : réduction de la conso de RAM et augmentation la rapidité du code... mais après faut faire gaffe aux risques d'erreurs
    Ce que j'ai voulu dire, c'est que vu que le langage C augmente la compelxité du programme alors le risque de bug est augmenté par rapport à un langage objet (bien entendu, on peut faire un programme en C non buggé et un programme en langage objet buggé)
    Je ne dis pas que les variables global ne peut pas être utiles , juste que dans la plupart des cas on peut s'en passé et que c'est souvent mieux de s'en passer , rien que pour le maintenabilité du code notamment.
    C'est souvent explication donné le C augmente la complexité et le risque de bug , je n'en sais rien je code en C depuis un moment et j'ai rarement ce soucis la , de même quand je change de langage je ne fais pas moins de bug.

    Citation Envoyé par boboss123 Voir le message
    Je n'ai pas dit qu'on ne pouvait pas faire autre chose que des drivers et de l'embarqué avec : j'ai dit que c'est surtout utile pour ça.
    Pour moi, si tu as un nouveau projet à créer en partant de 0 (hors embarqué et driver), je ne vois pas l’intérêt de partir sur du C => dans quel cas tu utiliserais ce langage ?
    Je pars souvent de 0 (mais avec le temps on se construit une petite lib perso tout de même) mais après ça dépend de la compétence de chaqu'un , mais sinon je l'utilise dans le jeux vidéo (2D ou 3D d'ailleurs) ,et quelque fois avec GTK+.

  17. #17
    Membre expérimenté Avatar de Trademark
    Profil pro
    Inscrit en
    Février 2009
    Messages
    762
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2009
    Messages : 762
    Points : 1 396
    Points
    1 396
    Par défaut
    C'est pas question de détail d'implémentation de savoir si C est orienté objet ou pas, on peut très bien faire de l'orienté objet avec du C, il suffit de stocker des pointeurs de fonction dans les struct et de "cacher" les membres internes. On peut émuler quasiment toutes les fonctionnalités OO d'un langage OO traditionnel mais il n'est évidemment pas adapté pour ça.

    C'est une question de philosophie, en C les données sont au centre des traitements, on appelle des fonctions sur des données pour modifier ces données, et sous forme de traitement successifs on arrive à un résultat. En POO, on ne pense plus vraiment aux données qu'on manipule mais aux services que peuvent nous rendre ces données. On appelle une méthode sur un objet pour qu'il nous rende un service, les données qu'il manipule ? ça n'a pas d'importance. Grâce à la POO, on obtient des modules avec un plus haut niveau d'abstraction vu qu'on pense en terme de service rendu.

    Pour résumer, être OO ou pas, c'est une philosophie lorsqu'on code, des classes en Java qui ne contiennent que des get/set sur tous les attributs ne sont pas plus OO qu'une structure en C. Par contre le langage Java est beaucoup plus adapté si le programmeur veut utiliser la POO car il propose tous les outils de base pour le faire.

  18. #18
    Inactif  
    Homme Profil pro
    Collégien
    Inscrit en
    Octobre 2012
    Messages
    78
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Octobre 2012
    Messages : 78
    Points : 0
    Points
    0
    Par défaut
    Tiens, je sais pas pourquoi mais ça me donne une idée : créer une framework pour C qui simule la POO. D'ailleur je crois que c'est déja fait.

  19. #19
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    Juin 2002
    Messages
    2 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Juin 2002
    Messages : 2 165
    Points : 4 637
    Points
    4 637
    Par défaut
    Citation Envoyé par grim7reaper Voir le message
    Ce qui caractérise vraiment la POO c’est :
    - encapsulation
    - polymorphisme
    - héritage
    Polymorphisme d'inclusion (ou de sous-typage) pour être précis. Les autres formes de polymorphisme ne sont pas franchement liés à la POO.

    Généralement, le dispatch simple basé sur le type dynamique de l'objet (qu'il soit nommé single dispatch, dynamic dispatch, late binding ou dynamic binding) est également considéré comme une propriété essentielle à la POO.

  20. #20
    Inactif  
    Homme Profil pro
    Collégien
    Inscrit en
    Octobre 2012
    Messages
    78
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Octobre 2012
    Messages : 78
    Points : 0
    Points
    0
    Par défaut
    Pour moi, c'est plutôt
    -classes :
    -peuvent hériter d'autres
    -permettent de créer des objets qui :
    -ont attributs et méthodes
    -ont encapsulation (que ça soit propriétés ou public/private)
    -sont polymorphes

Discussions similaires

  1. Réponses: 83
    Dernier message: 17/10/2011, 15h02
  2. La programmation orientée-objet est-elle dépassée ?
    Par Idelways dans le forum Actualités
    Réponses: 0
    Dernier message: 25/03/2011, 14h35
  3. Réponses: 8
    Dernier message: 18/01/2007, 22h01
  4. Réponses: 3
    Dernier message: 09/05/2006, 16h16
  5. VBA est-il un langage orienté objet ?
    Par Kcirtap dans le forum Général VBA
    Réponses: 5
    Dernier message: 06/12/2005, 10h46

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