Gérer les objets avec des classes - Page 4

(Nan mais en fait, ils voulaient un produit de GED - Gestion électronique de document avec suivi étudiant/enseignant - qui fasse aussi le recueil de données indiqué... mais bon, fallait le savoir )

Le langage, rarement ; l'OS, pas forcément (après, c'est plus le cahier des spécs techniques, sauf si l'usager/le client a des besoins explicites à ce niveau). Mais "tout un tas d'autres choses", oui

Nil (./93) :
sauf si l'usager/le client a des besoins explicites à ce niveau

Genre: "si ça ne tourne pas sous le dernier Fedora, alors "?

Non, plutôt genre "il faut que ça puisse tourner sur les machines déjà en place sans changement d'OS", ou "il faut que ça soit une application Web qui puisse tourner même sur un navigateur de la génération de IE4/Ns4", etc.

Et IE 3?

Kevin Kofler (./80) :

momotte (./75) :
tiens, exemple, toujours dans ton article:

What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

--> wtf...

Sur ce point, je dois défendre l'article, pour moi ce qu'il veut dire est tout à fait clair.

En revanche, pour en revenir à l'exemple des carrés et des rectangles: si j'ai bien compris, la solution proposée par l'auteur de l'article et aussi par JackosKing est d'avoir une classe abstraite AbstractRectangle qui définit des fonctions getHeight, getWidth, getArea, ..., mais pas de setters, puis d'avoir une classe Rectangle et une classe Square qui dérivent toutes les 2 de AbstractRectangle et proposent les bons setters. Cette méthode est valide et va fonctionner correctement, mais il y a un grand problème: si Rectangle a été développé sans penser à l'ajout successif d'une classe "carré" (comme le présuppose justement l'article à plusieurs endroits), alors il n'y aura certainement pas la bonne classe AbstractRectangle et donc on se retrouve à devoir changer toutes les utilisations de const Rectangle * en const AbstractRectangle * (idem pour les références), il faut donc retoucher tout le code (même si on utilise un remplacement global automatique, ça implique quand-même de tout recompiler), c'est la galère.

Cette modification est minime par rapport à produire le code que tu as proposé qui va t'apporter énormément de problème dans le futur. Je me permets d'ailleurs de te signaler le fait que ton code ne sera plus compatible tout comme le mien avec ton cas. En effet l'utilisateur de cette classe ne peut pas avoir la responsabilité d'utiliser les setters sur H et W.
Tu dois alors utiliser une IDP (ce qui est proposé).

Sous la notion de "est-un" se cache des contrats qui doivent être respectés. Le refactoring de codes est d'ailleurs bien plus facile lorsque l'on respecte certaines bonnes méthodes de la POO.

Nil> Il ne s'agit pas de tout savoir à l'avance, mais de pouvoir modifier le code facilement.

Pour les desgin patterns, je pense que c'est pas la peine d'insister. Restez dans vos bidouilles et le refus d'apprendre si vous voulez... mais vous resterez toujours à un niveau faible en POO (on vous demande peut être pas plus?).
C'est quand même curieux de lire aucune publication sur ce sujet, c'est même assez prétentieux de les critiquer et de prétendre tout connaître. Ces méthodes ont inspiré la STL, le java le C#... sur les sujets de design pattern et design by crontract.

(NB: KK tu me déçois un peu de ne pas t'intéresser à ce sujet, qui est pourtant relativement important (au moins par curiosité, et donc pour faire des critiques un peu plus constructives )

JackosKing (./97) :
Nil> Il ne s'agit pas de tout savoir à l'avance, mais de pouvoir modifier le code facilement.

On est d'accord, justement, modifier le code facilement revient à prendre en compte le fait qu'il est possible qu'on ne sache rien à l'avance ou presque (ou que certaines chose aient été oubliées).

Mais bon, dire qu'il y a *une* bonne façon de développer en POO, ça revient à dire qu'il n'y a qu'une bonne façon d'organiser des objets LDAP (je parle de ce que je connais mieux, j'avoue avoir fait ces dernières années plus d'analyse OO que de POO à proprement parlé puisque je ne travaillais que sur l'organisation des données et pas - ou peu - sur du développement). Il y a énormément de techniques qui se valent, toutes ont leurs points forts et toutes ont leurs points faibles. Certaines sont plus adaptées à de gros ou très gros projets, d'autres moins.

HS : Je ne sais pas chez vous, mais on est vraiment revenu du code totalement souple et évolutif (à mon grand malheur, d'ailleurs, mais vu l'historique de chacun de nos produits, on s'est rendu compte que c'était en partie du temps presque perdu... on développe du jetable qui dure 4 à 5 ans, ce qui est finalement à peine moins que du définitif qui dure 6 ans). On sait qu'un code fera une version majeure et qu'après il aura toutes les chances d'être réécrit totalement (parce que le langage aura grandement évolué (je prend l'exemple du Java, de .NET ou, pire, du PHP) parce que la structure de données aussi, parce que la plateforme cible aussi...).
On évite de reprendre du code qui a plus de 4 ans. Par contre (enfin, c'est pas vrai pour toute l'équipe, malheureusement), on essaye de documenter le plus possible pour pouvoir se baser sur les travaux d'analyse précédents et pour pouvoir intégrer des ressources étrangères plus facilement (quand on a un prestataire extérieur qui vient développer une appli ou mettre en place un service, il préfère avoir accès à une bonne analyse qu'à du code évolutif).

JackosKing (./97) :
Je me permets d'ailleurs de te signaler le fait que ton code ne sera plus compatible tout comme le mien avec ton cas. En effet l'utilisateur de cette classe ne peut pas avoir la responsabilité d'utiliser les setters sur H et W.

Je présuppose que la grande majorité des fonctions qui travaillent sur le rectangle est en lecture seule. S'il y a beaucoup de fonctions qui utilisent les méthodes "interdites" pour un carré, cette solution ne va pas fonctionner convenablement, c'est clair.

(Quand je dis "fonction" dans le paragraphe précédent, ça peut être une fonction globale ou une méthode de n'importe quel objet, peu importe.)

Nil (./98) :
parce que le langage aura grandement évolué (je prend l'exemple du Java, de .NET ou, pire, du PHP)

Vive le C , la plupart du code K&R compile toujours et le standard ANSI C89 / ISO C90 (qui a 19 ans!) bénéficie toujours d'un support très large. (Le standard actuel est l'ISO C99.)

(Ne pas rentrer dans le troll, ne pas rentrer dans le troll...)

./100 Est-ce vraiment positif ?
(cross - dsl je saute dedans à pieds joints)

Ah, ben j'apporte ma modeste contribution alors :

=> En tous cas c'est clair que ça change de Java, qui est incompatible avec lui-même à chaque nouvelle version.

ne pas répondre ne pas répondre ...

*Voix mielleuse* squalyl... squalyl... tu peux répondre... juste un petit post... sans conséquences... squalyl... libère le troll qui sommeille en toi...

Questions de rapidité de développpement et de portabilité j'immagine... Tout l'inverse de l'assembleur en somme

Bizarre de dire que tel ou tel langage objet est meilleur qu'un autre. Lorsque l'on développe un programme on veut le faire le plus rapidement possible dans un temps déterminé avec un budget déterminé, un effectif humain déterminé et un résultat déterminé. Si on a inventé le notion d'objet c'est que développer avec des langages impératifs comme le C des projets assez conséquent bah ça se cassé la gueule. Après utiliser de l'objet pour faire des trucs qui n'en n'ont pas besoin c'est perdre du temps et de l'argent.
L'objet est avant tout la pour pouvoir décomposer plus facilement l'architecture d'un projet et donc permettre un développement coopératif sûr et rapide.

Dire qu'un rectangle est une sorte de carré brise la programmation objet et donc le fait que tout instance soit sûr car dans cet exemple il existe une dépendance entre carré et rectangle alors qu'un carré est un élément à part entière avec des spécificitées différentes, même si proche d'un rectangle, ne peut être définie en objet (dans ce cas on pourrait dire qu'un vecteur est une sorte de point).

Enfin d'après mon point de vue le C# et le Java permettent un développement très rapide sans se soucier de détails de programmation (pointeurs, gestion mémoire, initialisation de composants complexes...) mais assiste le programmeur dans certaines tâches ce qui peut rendre certaines partie du code un peu obscure (clonage, surcharge, constructeur par copie...). Alors que en C++ on est très proche du bas niveau et donc on a un contrôle sur tout mais d'un côté on alourdi son code avec des algorithmes juste pour allouer correctement la mémoire, gérer correctement les structures de données... (pas de pointeurs intelligents (comptage de références, pas de méthodes de clonage, construction par copie et destruction descendantes complexes dans certains cas et Design patterns moins lisible qu'en Java et C#).

Bienvenue dans le troll, donc:

geogeo (./111) :
Si on a inventé le notion d'objet c'est que développer avec des langages impératifs comme le C des projets assez conséquent bah ça se cassé la gueule.

va dire ça à tonton torwalds, à tonton GTK/Gnome, etc...
honnêtement c'est que le C est trop compliqué pour les gens. Coder proprement des gros trucs en C c'est possible, coder salement des gros trucs en C ça devient imbitable.

geogeo (./111) :
Alors que en C++ on est très proche du bas niveau

wtf? c'est pas "compatible" que tu voulais dire? parce que proche...
le reste >

si le C est compliqué pour les gens, alors le C++ est imbitable pour les gens !

Squalyl: en meme temps le source de linux ou de GTK est vraiment imbitable... et ca n'a jamais vraiment été codé proprement...

Eh, comme quoi ce fut laborieux, il lui aura fallut 6 jours pour prendre, mais il a finit par prendre

Mouarf...
...
...
...

lol grilled (indirectement en plus)

112 > pas faux ^^

C'est rigolo, l'opposition JackosKing/la plupart des autres participants me rappelle l'opposition chercheur/ingénieur.

Je suis persuadé que pas mal de chercheurs ne feraient pas de bons ingénieurs, et vice-versa. Pourquoi ?
Parce que le but n'est pas le même.

Le chercheur travaille sur de la formalisation, où le but est d'être le plus rigoureux et précis possible.
L'ingénieur travaille sur de la pratique, où le but est qu'à la fin, le truc marche.

Mon boulot est dans la deuxième catégorie, donc je connais surtout des exemples qui font qu'un truc peut marcher sur le papier et pas "en vrai" :
- ça nécessite des ressources (mémoire, puissance de calcul...) trop importantes
- ça nécessite une connaissance ou un contrôle précis de l'environnement, alors que c'est impossible en pratique
- ce n'est pas suffisamment robuste face aux variations extérieures
- etc.

Des personnes qui écrivent des papiers comme ça, j'en ai vues (à commencer par certains enseignants-chercheurs d'école d'ingénieurs, qui n'ont pas dû mettre les mains dans le cambouis depuis longtemps). À l'inverse, je connais aussi des gens qui sont très bons en pratique, mais qui se retrouvent bloqués lorsque les problèmes nécessitent de sortir la théorie (traitement de signal, etc.).

Ça doit sûrement être intéressant pour un programmeur en entreprise de connaître les design patterns, ne serait-ce que pour savoir ce qui a déjà été fait et éviter de réinventer laborieusement la roue. Ce n'est pas une raison non plus pour vouloir y adhérer de façon rigide.

C'est d'ailleurs assez étonnant comme débat. Je pense que la majorité des gens ici connaissent les algos et structures de données classiques (Quicksort, arbres...). Je ne pense pas qu'on dise que c'est un avantage de ne pas les connaître. Mais si ça ne correspond pas bien au problème que vous avez à résoudre, vous n'allez pas vouloir les utiliser à tout prix, non ?

Pas mal le up
Le but de ces structures c'est de pouvoir les nommer et bénéficier d'optimisations connues en fonction des cas (ce sont des problématiques sur lesquelles d'autres gens ont bcp bossé). Les design patterns c'est pareil, ça te donne une solution qui fût bonne dans un cas particulier et que tu peux appliquer à autre chose qui y ressemble. Une sorte de jurisprudence si on veut. Ca ne veut pas dire que ce sera la meilleure solution si tu as identifié le cas correctement, mais elle ne sera certainement "pas mauvaise" car elle a fait ses preuves. Si tu pars sur cette base et que tu la cuisines aux petits oignons, il y a des chances que tu arrives à une excellente solution en passant relativement peu de temps (donc plus efficace par rapport à un dév depuis zéro) ^^

(ah, mince, j'avais pas vu que le sujet était aussi vieux j'étais arrivé ici par un lien depuis le sujet de Folco)

On se demande quel inconscient a bien pu poster ce lien