Discussion :

[MikeRowSoft]

Quoi? Orienté objet?
C'est déjà très proche d'instance, structure algorithmique des comportements d'entités (instances) et visibilité des "compétences ou registres" des instances.
Instance qui elle même est créé par le système d'exploitation une instruction (maloc?) et qui se retrouve ne jamais être comme se qu'il est dit en théorie.
INT64 par exemple dans C++ Builder qui peut-être instancié avec des systèmes d'exploitations 16 ou 32 bits.
Un instance peut être composé de plusieurs instances.
Le linker lui faisant un truc pour que cela ne soit pas possible de faire fonctionner des blocs binaires 64 bits avec des systèmes 32 bits.
Sans compter la mémoire vive avec les systèmes d'exploitations en 32 bits standard il n'est pas possible d'adresser 4 Go sur une barrette alors que deux barrettes de 2 Go oui, mais n'a jamais été utilisé que je sache (Linux ou MS Windows home edition).

Je crois que steve jobs est malheureusement bien mort...

Comme de se procurer Darwin OS en ISO pour PC AMD64.

[Kevin-lourenco]

Ok je n'ai rien compris, as-tu des exemples concrets de ce que pourrait m apporter de plus l orienté object que le procédural ?

En sachant que je suis avant tout développeur (Web) le jargon employé est trop technique et théorique pour moi, j ai besoin d exemple concret pour mieux visualiser.

Merci à toi !

[Pierre Louis Chevalier]

Ok je n'ai rien compris, as-tu des exemples concrets de ce que pourrait m apporter de plus l orienté object que le procédural ?

En sachant que je suis avant tout développeur (Web) le jargon employé est trop technique et théorique pour moi, j ai besoin d exemple concret pour mieux visualiser.

Merci à toi !

Salut, tu peux voir ici pour des cours et tutoriels POO , partie : Généralités & initiation -> Objets.

[Kevin-lourenco]

Merci ! Mais bon tout cas on peut le faire avec des variables passé en référence ?

[MikeRowSoft]

Je crois que la solution la plus pratique pour toi serait que celui qui souhaite t'apporter des réponses te demander le type d'interface qui te permettrait de comprendre le mieux le principe. Et surtout la façon d'on tu souhaite réutilisé ces méthodes.
L'orienté objet n'est pas uniquement informatique mais permet aussi de structurer certaines choses avec méthodologie pour répondre à des besoins après analyses.

[el_slapper]

La vraie question est : à qui ça s'adresse? A ma fille de 8 ans qui n'a jamais touché un PC? alors oui, c'est une bonne définition. Au vétéran qui a 20 ans de COBOL derrière lui, et qu'on force à passer au Java - et donc à un langage objet? Alors ça ne marchera pas du tout. Pour lui, la bonne définition, c'est : "une classe, c'est une structure de données. A laquelle on rajoute tout le code qui s'applique dessus. Ça évite d'avoir à recoder les mêmes choses dans chaque module qui utilise la même donnée de la même manière. L'objet, ce sont les données elles-mêmes".

Et il y a surement plein d'autres publics. Qui demandent plein d'autres définitions.

[martopioche]

Steve Jobs le type qui n'as jamais codé 1 seule ligne de code de toute sa vie ? Comment il pouvait savoir ce qu'était la prog objet en ne sachant pas codé ?

Par contre l'explication est plutôt bonne, je dois le reconnaitre.

À l'opposé, on peut aussi relever qu'il y a des plateaux de devs entiers qui codent à longueur de journée, voir pour certains avec des langages orientés objet et qui pourtant ne savent pas ce qu'est la "prog objet"...

[Kevin-lourenco]

Donc si on code en procédural et que nous avons cette approche objet, on peut dire que nous faisons alors de la programmation orienté objet (même si on utilise pas forcément les class, constructeurs et compagonie comme enseignés dans les tutos sur la POO en PHP ) ?

[Kevin-lourenco]

Je prend l exemple des tutos de POO de PHP puisque je n'est lu que ceux là, si il s agit plus d'u concept de programmation, au fond peu importe la manière d y parvenir procédural ou non.

[MikeRowSoft]

La vraie question est : à qui ça s'adresse? A ma fille de 8 ans qui n'a jamais touché un PC? alors oui, c'est une bonne définition. Au vétéran qui a 20 ans de COBOL derrière lui, et qu'on force à passer au Java - et donc à un langage objet? Alors ça ne marchera pas du tout. Pour lui, la bonne définition, c'est : "une classe, c'est une structure de données. A laquelle on rajoute tout le code qui s'applique dessus. Ça évite d'avoir à recoder les mêmes choses dans chaque module qui utilise la même donnée de la même manière. L'objet, ce sont les données elles-mêmes".

Et il y a surement plein d'autres publics. Qui demandent plein d'autres définitions.

Les variables internes et les fonctions d'une instance. Qui elle même peut faire parti d'une instance, le tous faisant parti d'un "main" qui lui même à l'exécution fini par faire parti d'une instance "main" système. (les types?)

Au niveau bac+5 sans y réussir là j'ai très bien compris.

Par contre le code du travail là comme les plus jeunes je vais avoir du mal, car beaucoup à apprendre en très peu de temps. (pourtant 30 minutes par semaine devrait suffire à éclairer cette apprentissage progressif)

Le coté humoristique serait de faire la liaison entre un responsable de service et une mère de famille qui demande à un employé et un enfant de mettre un peu d'ordre dans son bureau, requête de trier, classer avec méthodologies leurs espaces de travail respectif.

[DonQuiche]

Donc si on code en procédural et que nous avons cette approche objet, on peut dire que nous faisons alors de la programmation orienté objet (même si on utilise pas forcément les class, constructeurs et compagonie comme enseignés dans les tutos sur la POO en PHP ) ?

Si je te comprends bien, tu te demandes si le fait de créer des objets en ajoutant des champs dynamiquement à une table peut être considéré comme de la POO ? Par opposition au fait de passer par les classes de php où le type est défini formellement ? Peut-être, ça dépend de ce que tu en fais, mais probablement pas sinon tu verrais des avantages à déclarer des classes.


La POO c'est avant tout l'encapsulation : chaque objet doit être une boîte noire masquant ses détails internes pour que tu puisses ignorer ceux-ci lorsque tu utilises ton objet. Le but est de diviser ton code en petits problèmes indépendants, modulaires et bien organisés, n'exposant que le strict minimum au reste du monde.

Lorsqu'on crée un type (classe ou non) on doit donc choisir quels attributs seront visibles à l'extérieur et lesquels seront internes, et quelles méthodes permettent de manipuler ces variables internes. Ta façon de faire répond t-elle à ce besoin, par exemple avec une convention de nommage spécifique pour les champs privés ? Ou bien tous tes objets ne sont-ils que des collections d'états publics que tous manipulent à leur gré ? Utiliser une classe permet de spécifier la visibilité de chaque membre et remplce avantageusement une une convention de nommage.

[RyzenOC]

La POO c'est avant tous une organisation du code en le groupant en objets, les objets sont des éléments comportant des informations et des fonctionnalités.

[vinmar]

C est cool, le sujet est simple: pour vous qu'elle est la représentation de l'object ? Et à la place on a un débat pour savoir si steave jobs savait coder..

Passons, moi je n'utilise pas l'object à proprement parler avec toute sa puissance (d'ailleurs pour mes petits projets voir moyen je n'en est pas forcément eu besoin).

Je ne réinvente cependant pas la roue en alliant un mélange de fonction et d'include avec variable pour répondre à des demandes différentes.

Pour moi si le tout est bien organisé, cela ne change pas grand chose, mais c'est sûrement qu'il doit y avoir d'autre qualité à l'orienté object que je ne connais pas encore ne n'ayant pas exploré de fond en comble.

Si quelqu'un veut bien m apporter des éléments de réponse, je suis preneur, trouvant que l'orienté complexifie le code, il y à sûrement une bonne raison à cela

Je vais tenté d'être clair :
Imagine que ton "mélange de fonction et d'include avec variable" et regroupé dans un ensemble logique qui te permet de créer un site Internet (que je suppose être tes "petits projets"). A chaque fois que tu réalises un site Internet, tu réutilises ton "mélange de fonction et d'include avec variable".

Etant donné que ton "mélange de fonction et d'include avec variable" est regroupé dans un ensemble logique (on parle d'encapsulation) qui s'appellera "Website" et qui est donc un objet (et donc une classe), au lieu d'écrire en procédurale plein de lignes de codes, tu pourras faire par exemple : $website = new Website() => badaboum ! Tu viens de faire ton site Internet. Si ça c'est pas beau !

Ensuite, tu veux changer le nom du site, tu n'as qu'à faire : $website->setTitle('Mon site Internet') => badaboum ! Tu viens de changer le title de la balise de tes pages web !

Tu veux afficher ton site : $website->display() => badaboum ! Ton site s'affiche.

Alors, certain l'ont expliqué, toute la machine représentant le "mélange de fonction et d'include avec variable" est caché dans l'objet "Website", et à un moment il faut le coder, et effectivement, c'est plus complexe que l'exemple que je te donne.

L'avantage de la POO c'est que c'est une méthode de programmation qui te permet de créer des gros logiciels qui regroupent plein d'objets et de les organiser d'une façon logique. Parce que dans la vraie vie, il n'y a pas q'un seul objet dans l'univers, et pire ils interagissent entre eux... et là, tu prend les tutos de developpez.com.

[Luckyluke34]

Steve Jobs vulgarise deux aspects de la programmation qui sont l'abstraction et l'encapsulation.

Deux aspects pas du tout spécifiques à la programmation objet. On fait la même chose en procédural pur ou en fonctionnel (et le fonctionnel peut par ailleurs lui-même être objet en plus).

Donc en fait il n'a pas du tout définit la programmation objet...

C'est complètement inexact L'encapsulation est bel est bien un des principaux traits caractéristiques de l'objet. Et en fonctionnel il n'y a pas d'encapsulation, les données sont séparées des traitements.

Par ailleurs tu n'as pas prêté attention à deux points fondamentaux de l'explication de Jobs qui sont le passage de messages et le fait qu'un objet a sa propre mémoire.

Pour Alan Kay, l'inventeur de la programmation orientée objet,

1. EverythingIsAnObject.

2. Objects communicate by sending and receiving messages (in terms of objects).

3. Objects have their own memory (in terms of objects).

4. Every object is an instance of a class (which must be an object).

5. The class holds the shared behavior for its instances (in the form of objects in a program list)

6. To eval a program list, control is passed to the first object and the remainder is treated as its message.

http://c2.com/cgi/wiki?AlanKaysDefin...ObjectOriented

[MikeRowSoft]

Pour Alan Kay, l'inventeur de la programmation orientée objet,

http://c2.com/cgi/wiki?AlanKaysDefin...ObjectOriented

Je me demandais où étais passer les classes abstraites (C++). Le modèle U.M.L. sa les définis comment encore?

Je crois que la théorie de "l'absence de" (manquement potentiel) va encore être confondu avec celle de l'ensemble vide. (LOTOS/M y est très sensible)

[Kevin-lourenco]

$website = new Website() => badaboum ! Tu viens de faire ton site Internet. Si ça c'est pas beau !

$website = Creerwebsite() =>badaboum ! Tu viens de faire aussi ton site Internet. Et sans objet et pourtant ça fonctionne très bien !

Même principe pour afficher le site :

AfficherSite($website);

Magique on a aussi affiché le site et le principe d'entonoir est bien respecté !

[vinmar]

$website = new Website() => badaboum ! Tu viens de faire ton site Internet. Si ça c'est pas beau !

$website = Creerwebsite() =>badaboum ! Tu viens de faire aussi ton site Internet. Et sans objet et pourtant ça fonctionne très bien !

Même principe pour afficher le site :

AfficherSite($website);

Magique on a aussi affiché le site et le principe d'entonoir est bien respecté !

Non mais là, tu n'as pas lu ce que j'ai écris. L'important à retenir était la méthode pas la finalité.

[Kevin-lourenco]

A bien sûr tu as tout à fait raison ! D'oú ma remarque: peut importe la méthode, tant que la finalité est là on parle bien de programmation objet dans les deux cas !

Je fais cette remarque car un amis m'avais conseiller de modifier l'intégralité de mon projet existant en appliquant les méthodes que tu as montré. Quand je lui est dis que le code existant faisait exactement la même chose, organisé de la même manière, il m'a simplement répondu que si c'est du procédural ce ne peux pas être orienté objet.

Son erreur à donc été de penser que l'oriente objet est une méthode spécifique alors qu'en réalité il s'agit d'un concept ! Peut importe la méthode, tant que le concept est respecté, je ne vois pas l'intérêt de modifier le code

[vinmar]

A bien sûr tu as tout à fait raison ! D'oú ma remarque: peut importe la méthode, tant que la finalité est là on parle bien de programmation objet dans les deux cas !

Je fais cette remarque car un amis m'avais conseiller de modifier l'intégralité de mon projet existant en appliquant les méthodes que tu as montré. Quand je lui est dis que le code existant faisait exactement la même chose, organisé de la même manière, il m'a simplement répondu que si c'est du procédural ce ne peux pas être orienté objet.

Son erreur à donc été de penser que l'oriente objet est une méthode spécifique alors qu'en réalité il s'agit d'un concept ! Peut importe la méthode, tant que le concept est respecté, je ne vois pas l'intérêt de modifier le code

Sazearte l'a dit plus haut : "La POO c'est avant tous une organisation du code en le groupant en objets, les objets sont des éléments comportant des informations et des fonctionnalités."

D'oú ma remarque: peut importe la méthode, tant que la finalité est là on parle bien de programmation objet dans les deux cas !

Oui et non, tu peux faire du vélo avec des roues carrées ou faire du vélo avec des roues rondes. Dans les deux cas, tu fais du vélo, tu avances, mais il y a un vélo plus pratique que l'autre. Ne le prends pas mal mais l'exemple que tu m'as donné c'est le vélo avec des roues carrées. Là encore tu me dis "tant que la finalité est là on parle bien de programmation objet" => ça ne veut rien dire. Peut-être qu'il te faut lire cela dans un premier temps : https://fr.wikipedia.org/wiki/Progra...t%C3%A9e_objet.

[Kevin-lourenco]

A non ne tant fait pas, je ne le prend pas mal dutout bien au contraire

Pour moi c'est plutôt comme vouloir faire du vélo et vouloir faire du skate board.

Mettons les deux vont à la même vitesse, si je fais du vélo et que l'on me conseil de passer au skate board il me faudra un temps d'adaptation, alors pourquoi ne pas rester sur mon vélo ? La seul chose que je perçois c est que le skate board est plus complexe, on avance différemment mais on ne gagne pas en vitesse ! Résultat pour moi la seul raison valable c est que si toute mon équipe roule en skate, je ne vais pas rester sur mon vélo, hors ici toute l'equipe est au vélo. Donc aucune raison de changer valable (peut être il y en a, mais personne n'a réussir à m expliquer clairement: "la méthodologie de l orienté objet c est mieux car on peut faire ça en plus ou ça de cette manière qui raccourcis le temps de dév ou la maintenance").

Je vais lire ton article sur wiki pour voir si ma vision différe du raisonnement