01-08-2013, 07:56 PM
La traduction mot à mot, osef de la qualité (tu n'as qu'à imaginer qu'au lieu de traduire, je code mes livres, avec un code très simple à base de substitution directe d'un mot avec un autre). Là où j'aimerai me faire comprendre (mais apparemment, j'ai du mal, en fait, cela me dépayse pas trop, j'ai souvent eu des retours type "ah putain, ton idée était tordue, personne n'aurait pensé ça comme ça, mais finalement, ça marche plutôt bien") c'est que le principe que vous avez en tête, c'est:
j'ai une classe, bibliothèque, et je veux pouvoir lui demander un livre (l'un après l'autre, ou tous d'un coup, ou autre, osef) pour lui appliquer un traitement.
Mais cela me semble aller partiellement à l'encontre du principe objet, qui consiste (alors, peut être que je me trompe sur ce principe, auquel cas, corrigez moi) à ne rien connaître du contenu de l'objet que l'on manipule.
C'est comme Schrodinger et son chat: on se fiche de savoir si le chat est mort ou vivant, ce qui est intéressant, c'est de voir que la question en elle-même n'a pas de sens. Dans le cas de la bibliothèque, si on la voit comme un objet, ça n'a juste pas de sens de vouloir récupérer ce qui compose cette bibliothèque, puisque cela est censé faire partie de la "boite noire" de la bibliothèque.
Il me semble que ce n'est pas par hasard que le C/C++ considère les tableaux comme des types de base, et non des objets. L'idée est la même. Si on veut gérer la bibliothèque comme une collection de livres, on n'en fait pas un véritable objet (on peut toujours la coller dans une classe, mais ce ne sera pas une classe qui respecte le principe de "boite noire" de l'objet). Si on veut que la bibliothèque soit vue comme un objet, on "l'assume", et on n'autorise pas l'utilisateur à aller voir son contenu.
C'est un peu comme les getter et setters par défaut: à quoi cela rimerait-il d'avoir une classe ayant un attribut "private" (ou protected) que l'on relie à un getter et un setter par défaut? Autant faire de l'attribut un attribut "public"...
Enfin, voilà, c'est ma vision des choses (généralement, on me dit "extrémiste"...), je n'obligerai personne à suivre
Mais c'est une habitude de codage qui me permet de faire des traitements de plusieurs millions de données (dernier exemple en date: une maquette 3D de 10.000.000 de triangles) en moins d'une dizaine de minutes (contre 15 minutes pour seulement 10.000 triangles avec la technique du précédent groupe de travail qui justement travaillait plutôt sur du "on fout tout dans des objets même les tableaux, les matrices, les vecteurs et les types de base").
Oui, c'est un peu "hard codé", sauf que c'est la classe qui se hard code, donc, cela reste parfaitement maintenable; bien plus qu'un code hyper-généralisé partagé entre plusieurs classes / "zones" de code.
j'ai une classe, bibliothèque, et je veux pouvoir lui demander un livre (l'un après l'autre, ou tous d'un coup, ou autre, osef) pour lui appliquer un traitement.
Mais cela me semble aller partiellement à l'encontre du principe objet, qui consiste (alors, peut être que je me trompe sur ce principe, auquel cas, corrigez moi) à ne rien connaître du contenu de l'objet que l'on manipule.
C'est comme Schrodinger et son chat: on se fiche de savoir si le chat est mort ou vivant, ce qui est intéressant, c'est de voir que la question en elle-même n'a pas de sens. Dans le cas de la bibliothèque, si on la voit comme un objet, ça n'a juste pas de sens de vouloir récupérer ce qui compose cette bibliothèque, puisque cela est censé faire partie de la "boite noire" de la bibliothèque.
Il me semble que ce n'est pas par hasard que le C/C++ considère les tableaux comme des types de base, et non des objets. L'idée est la même. Si on veut gérer la bibliothèque comme une collection de livres, on n'en fait pas un véritable objet (on peut toujours la coller dans une classe, mais ce ne sera pas une classe qui respecte le principe de "boite noire" de l'objet). Si on veut que la bibliothèque soit vue comme un objet, on "l'assume", et on n'autorise pas l'utilisateur à aller voir son contenu.
C'est un peu comme les getter et setters par défaut: à quoi cela rimerait-il d'avoir une classe ayant un attribut "private" (ou protected) que l'on relie à un getter et un setter par défaut? Autant faire de l'attribut un attribut "public"...
Enfin, voilà, c'est ma vision des choses (généralement, on me dit "extrémiste"...), je n'obligerai personne à suivre
Mais c'est une habitude de codage qui me permet de faire des traitements de plusieurs millions de données (dernier exemple en date: une maquette 3D de 10.000.000 de triangles) en moins d'une dizaine de minutes (contre 15 minutes pour seulement 10.000 triangles avec la technique du précédent groupe de travail qui justement travaillait plutôt sur du "on fout tout dans des objets même les tableaux, les matrices, les vecteurs et les types de base").Oui, c'est un peu "hard codé", sauf que c'est la classe qui se hard code, donc, cela reste parfaitement maintenable; bien plus qu'un code hyper-généralisé partagé entre plusieurs classes / "zones" de code.