voilà j'ai un énorme soucis par rapport à la programmation objet, c'est que je suis un novice mais vraiment au bas de l'échelle et je ne sais pas par où commencer si je dois commencer par du php objet ou java ou d'autre langages
Les bons cours qui causent de POO (et vraiment de POO, pas du bricolage) ne courent pas les rues. A mon avis, tu devrais simplement t'atteler à l'apprentissage d'un langage de programmation permettant l'OO (Python par exemple) et ensuite t'y intéresser d'un point de vue plus théorique pour mieux l'utiliser. Les points les plus importants (à mon sens) à comprendre à propos de l'OO :
les classes sont des fournisseurs de services (pas du stockage amélioré), et des abstractions de nos données,
les objets sont des instances de ces services liés à un état abstrait particulier (et la représentation concrète est secondaire),
l'encapsulation est un moyen de garantir la cohérence de nos objets, pas le but de l'orienté objet,
la notion d'héritage pour le polymorphisme exprime une variation de comportement pour un service (pas une factorisation de code ou de la mise en commun de données).
Et viennent s'ajouter à cela la compréhension de la Loi de Démeter et des principes SOLID. Comprendre cela n'est pas difficile. Même si sans connaissance de l'objet, ça doit te sembler très abstrait actuellement . Le mettre en pratique en revanche demande d'être très rigoureux avec soi-même et de ne pas s'autoriser d'entorses à ces idées, au moins pendant un temps.
+1 à Ksass `Peuk. Le Ruby aussi peut être un bon langage pour l’OO, en particulier pour le dernier point qu’il soulève à propos de l’héritage. Par contre, si l’on trouve des articles qui traitent de conception et de points particuliers, c’est plus dur de trouver un tutoriel qui l’aborde de zéro.
@PO : tu as la possibilité d’acheter des livres où tu ne cherches que des ressources en ligne ? Les ressources en anglais te gênent ou pas ?
@yo@n97one Ruby pour apprendre l'objet n'est peut-être pas le meilleur pour comprendre l'encapsulation
Avec tous les outils qui propose presque 100% de leurs methodes en publique, ca donne de mauvais habitude. (Dont ActiveRecord)
Sinon Ruby est un très bon langage pour apprendre le reste, dont la modularisation d'un projet, ou la création de librairie (C'est super facile dans ce langage)
@necros : Je suis presque entièrement d’accord avec toi au niveau de l’encapsulation. Mais, la plupart des guides de bonnes pratiques conseillent d’utiliser private et protected quand il le faut (sur ce point, Python est plus embêtant puisqu’il n’y a pas de mot-clé pour ça). Pour moi, le problème à propos de ça est bien le manque de tutoriel qui aborde la conception. Après c’est vrai qu’il y a mieux pour aborder l’encapsulation.
Les design pattern, il ne faut pas les apprendre, c'est juste une sorte de dico, genre tu fait un travail, tu est fier et tu veux savoir ce que c'est tu regarde, apprendre les DP est un piège que beaucoup font, car après certain v9nt vouloir appliquer bêtement sans contexte adapté..
Bien sûr, les apprendre bêtement est une mauvaise idée, mais savoir qu’ils existent est un plus. Malheureusement, comme vous l’avez dit, beaucoup de personnes les appliquent sans réfléchir réellement à leur besoin réel (tout comme certains commencent à créer des objets pour représenter tout et n’importe quoi).
Les DP doivent être étudiés (pas appris), mais dans un second temps seulement. Notamment, parce qu'une partie d'entre eux permet de rompre une partie des principes SOLID de manière contrôlée lorsqu'il n'est plus possible de les respecter parce que l'on a un besoin particulier. Je pense notamment au DP visiteur qui est très concrètement une rupture de l'OCP mais une rupture que l'on est obligée de faire si l'on veut être capables de faire proprement du multiple-dispatch dans les langages OO mainstreams. Le singleton, qui est l'anti-pattern le plus connu, a ses cas d'usage, mais encore une fois il introduit un fort couplage dans l'application donc il faut être capable de faire la part des choses en conception avant de l'utiliser.
Avoir connaissance des solutions qui font les bons compromis à des problèmes complexes est une nécessité, mais certainement pas lorsque l'on débute l'apprentissage de l'OO. Donc les DP oui, mais quand on sait déjà utiliser son cerveau pour concevoir en OO.
L'auteur n'est pas revenu et vu ton premier message Ksass Peuk (les suivants aussi d'ailleurs) je peux presque le comprendre
C'est presque comme dans un dîner mondain, ou l'un fait "montre" de ses bons mots pendant que les autres sont tout ouies :
" liés à un état abstrait particulier (et la représentation concrète est secondaire),"
"garantir la cohérence de nos objets, pas le but de l'orienté objet,",
"une variation de comportement pour un service (pas une factorisation de code"
w...t...f...
En plus s'il est en bas de l'échelle, il veut peut-être comprendre le principe, et avoir une explication simplifiée.
L'auteur -> par exemple, la POO, c'est le principe d'utiliser des "classes" qui peuvent communiquer entre elles, certaines classes héritent d'autres (classe mère = animal, classe fille = chien), le but est aussi de séparer le code et de pouvoir demander à une classe de faire le boulot et de te renvoyer le résultat, et elle aura peut-être elle-même fait appel à d'autres classes pour obtenir le résultat voulu, sans que tu t'occupes de quoique ce soit. Voilà, pas besoin d'étaler sa confiture (!)
Un petit jeu en Java est un bon moyen de comprendre, car il y a beaucoup de ressources sur le net, un bon tuto d'openclassrooms, et apprendre en faisant un jeu est un bon exercice.
> C'est presque comme dans un dîner mondain, ou l'un fait "montre" de ses bons mots pendant que les autres sont tout ouies
Ce n’est pas du tout ça. C’est juste que la POO est généralement mal enseigné, le premier message de @Ksass `Peuk recense ce qui est généralement mal enseigné (l’héritage et l’encapsulation en particulier).
> En plus s'il est en bas de l'échelle, il veut peut-être comprendre le principe, et avoir une explication simplifiée.
Euh, non. Il a demandé par quoi commencer, @Ksass `Peuk a conseillé d’apprendre un langage OO et a ensuite donné des conseils sur les points importants qu’il fallait comprendre. J’ai conseillé Python.
> par exemple, la POO, c'est le principe d'utiliser des "classes" qui peuvent communiquer entre elles, certaines classes héritent d'autres (classe mère = animal, classe fille = chien), le but est aussi de séparer le code et de pouvoir demander à une classe de faire le boulot et de te renvoyer le résultat, et elle aura peut-être elle-même fait appel à d'autres classes pour obtenir le résultat voulu, sans que tu t'occupes de quoique ce soit. Voilà, pas besoin d'étaler sa confiture (!)
Là ton explication est bof et laisse place à beaucoup d’interprétation. Par exemple représenter l’héritage juste comme ça conduit rapidement à faire des objets « comme dans la vraie vie » et donne rapidement à des problème comme celui du diamant. De même, le « sans que tu t’occupes de quoique ce soit » fait la POO ressembler un peu à de la magie et ce n’est pas du tout le cas.
> Un petit jeu en Java est un bon moyen de comprendre, car il y a beaucoup de ressources sur le net, un bon tuto d'openclassrooms, et apprendre en faisant un jeu est un bon exercice.
J’aime pas trop Java comme langage pour débuter la POO. Après je ne sais pas ce que vaut le tutoriel Java d’OC, mais avoir beaucoup de ressources sur le net ne veut pas dire qu’elles sont bonnes. Et selon moi, il y a pleins de petits programmes qui permettent de comprendre mieux que les jeux, notamment parce que les débutants ont tendance à faire de l’héritage dans tous les sens quand ils font un jeu.
PS : qu’est-ce qui te fait croire que si l’auteur n’est pas revenu c’est à cause des réponses ? Si on regarde sa date de dernière connexion, c’est le 12 avril, soit avant la première réponse.
Je te donne raison sur ton PS Même si je te soupçonne d'avoir cherché à trouver un argument négatif sur les autres points par simple opposition (Aller chercher la date de connexion de l'auteur c'est quand même assez fort, ça te donne raison sur ce point, mais quand même...! )
Non, je ne suis pas mesquin à ce point. Après avoir écrit mon message, je me suis dit que t’avais peut-être raison et que la discussion l’avait « effrayé », donc je suis allé vérifier ;
Pour les autres points, j’avoue que je voulais parfois juste m’opposer gentiment (comment ça j’ai un esprit de contradiction ), mais les arguments restent valables. Si je devais résumer, je dirais que la POO n’est pas si « simple » à bien expliquer et qu’il n’y a pas beaucoup de ressources de qualité.
Sinon, tu as des arguments pour le choix de Java (ce n’est pas une question-piège, hein) ?
En plus s'il est en bas de l'échelle, il veut peut-être comprendre le principe, et avoir une explication simplifiée.
Le problème c'est qu'en simplifiant, on a très vite fait d'arriver à une explication fausse. J'ai simplifié certains points et ma définition se retrouve à être un poil trop proche de la notion de type abstrait de données qui sont différent des objets. Si on prend par exemple ce que tu proposes :
PaulLou a écrit:
L'auteur -> par exemple, la POO, (1) c'est le principe d'utiliser des "classes" qui peuvent communiquer entre elles, (2) certaines classes héritent d'autres (classe mère = animal, classe fille = chien), (3) le but est aussi de séparer le code et de pouvoir demander à une classe de faire le boulot et de te renvoyer le résultat, et elle aura peut-être elle-même fait appel à d'autres classes pour obtenir le résultat voulu, sans que tu t'occupes de quoique ce soit. (4) Voilà, pas besoin d'étaler sa confiture
(1) Imprécis, ce sont les objets qui sont communiquant, pas les classes. Et plus important encore, ce ne fait pas mention du fait que les objets ont des comportements variants déterminés à l'exécution qui est le vrai trait différenciant en OO. Sinon, la définition matche presque avec la notion de type abstrait de données. La notion de classe n'est d'ailleurs pas une notion spécifique à l'objet et beaucoup de langages objets n'ont pas de notions similaire à la notion de classe (qui n'existe d'ailleurs même pas à l'origine en objet), et dans ma simplification, j'ai aussi utilisé ce terme alors qu'il ne devrait pas nécessairement s'y trouver.
(2) Ce n'est pas nécessaire à l'OO (on peut faire de l'OO sans héritage, cf par exemple "Self" qui ne fournit pas cette notion et qui est beaucoup plus OO que la majorité des langages tagués avec cette notion). D'autre part, ce n'est pas exclusif à l'OO puisque la notion d'héritage n'est pas utilisée qu'en OO. Quant à l'exemple, @yo@n97one a déjà commenté.
(3) Sauf que ça, c'est le concept de la programmation en général, on demande depuis des entités larges de faire un boulot plus spécifique auprès d'entités plus restreintes. Bref, c'est vrai en procédural, en fonctionnel, en logique, et en tout ce que tu veux.
(4) Ben, à croire que si du coup ... vu que ta définition n'est pas correcte (la mienne est loin d'être parfaite non aussi cela dit). L'OO n'est pas très bien défini de manière générale. Une de mes définitions préférées actuellement est celle proposée par William Cook, qui ne parle pas de classe (car le mot classe n'est pas du tout utilisé pour le même concept ici) d'ailleurs puisque ce n'est que le moyen que certains langages ont choisi pour modéliser la notion d'objet :
Un objet est un comportement de première classe déterminé dynamiquement.
C'est la plus simple et la plus précise que j'ai pu trouver dans la littérature mais je ne suis pas sûr qu'elle aurait vraiment aidé le PO. Elle a d'ailleurs le bon goût d'être plus précise que la mienne et de ne pas taper à côté (en même temps W.Cook qui l'a proposée est bien meilleur que moi). Et si on détaille un peu :
un comportement est un ensemble d'opérations qui peuvent être invoquées par des clients, et qui partagent des détails d'implémentation communs,
ils sont déterminés dynamiquement car différent objets vont pouvoir implémenter le même comportement mais de manière différente et la résolution du comportement choisi sera effectuée le plus tard possible,
ils sont de première classes car ils peuvent être manipulés en entrée et sortie d'autres opérations comme n'importe quelles autres valeurs.
Bref, définir l'OO, ce n'est pas si simple. Et on a vite fait de se gourrer. On peut même reprendre la définition originelle de l'OO :
"A program execution is regarded as a physical model, simulating the behavior of either a real or imaginary part of the world" Nygaard.
Et là on est contents parce que basiquement tout programme répond à cette définition, raison pour laquelle je ne peux pas voir cette définition qui est imprécise au possible et ne donne absolument aucune information (et le papier fondateur de Simula, qui a été conçu dans cette optique, n'aide franchement pas).
yo@n97one a écrit:
J’aime pas trop Java comme langage pour débuter la POO. Après je ne sais pas ce que vaut le tutoriel Java d’OC, mais avoir beaucoup de ressources sur le net ne veut pas dire qu’elles sont bonnes.
Le tutoriel est pas mal pour apprendre Java, par contre la partie conception est un peu mise à la trappe. On a notamment droit à l'héritage pour de la généralisation de données plutôt que de comportement et de la programmation orientée objet à grands coups de getters et setters, soit l'anti-thèse de l'objet puisqu'on expose l'état interne.
Son principal avantage par rapport à une definition courte mais fausse, c'est que lui au moins ne lui donne pas des informations qui sont à côté de la plaque :-) .
Après, tu peux aussi aider le PO en fournissant une définition courte. Mais essaies de la faire correcte cette fois.
PaulLou, ce n'est pas le première fois que je constate que tes interventions sont soit inutile, soit totalement fausses (et ici, on est chanceux, on cumule les deux). Je te le demande donc gentiment, merci de n'intervenir que sur les sujets que tu es SÛR de maîtriser, le but de ce forum n'est pas de faire de la désinformation, et je ne laisserai pas les utilisateurs le faire.
Ceci compte comme premier (je pense même l'avoir déjà fait remarquer) et dernier avertissement, la prochaine fois ce sera une sanction. Je t'invite, au passage, à me contacter en privé si tu veux constater ceci, mais de ne plus répondre sur ce sujet vu que tu n'apportes absolument aucun élément intéressant.
- Edité par Sakuto 18 avril 2017 à 8:44:19
Je ne suis plus modérateur, ne me contactez plus pour des demandes, je n'y répondrai pas.
Dans le fond je pense qu'il y a malheureusement un peu de vrai dans le fait qu'on fait sûrement peur aux petits nouveaux, ou du moins, qu'ils n'arrivent pas à saisir tout ce qu'on essaie de dire.
Ça me fait penser à mes cours de mécanique quantique à l'époque, c'était exactement le même style de réponses qu'ici : précises et complètes mais difficilement abordables quand on n'a pas saisi tous les concepts.
Même à l'époque quand j'ai débuté sur le SdZ, c'était un peu pareil, pour arriver à rattacher ce qu'on m'expliquait à mon code, c'est comme s'il me manquait un lien entre les deux ! J'avais du mal à appliquer les principes.
Le mieux reste évidemment les exemples concrets pour expliquer, mais encore faut-il que ça soit possible...
Dans le fond je pense qu'il y a malheureusement un peu de vrai dans le fait qu'on fait sûrement peur aux petits nouveaux, ou du moins, qu'ils n'arrivent pas à saisir tout ce qu'on essaie de dire.
Ouais pour ça que j'ai d'abord écris :
Ksass`Peuk a écrit:
A mon avis, tu devrais simplement t'atteler à l'apprentissage d'un langage de programmation permettant l'OO (Python par exemple) et ensuite t'y intéresser d'un point de vue plus théorique pour mieux l'utiliser.
Le reste des infos, il pourra toujours venir les potasser quand il aura acquis quelques bases. Les autres réponses, c'était plus tellement destiné au PO.
Sakuto : "tes interventions sont soit inutile, soit totalement fausses" : Mensonges. Donne les liens url... j'aide énormément de gens sur ce forum. Et si tu voulais qu'on se parle en privé, il fallait envoyer un message en privé, pas sur ce topic, tu n'appliques pas tes propres règles à toi-même.
Ksass Peuk : qu'importe le nombre de messages, si tu n'aides pas, je réagis. La condescendance ("on n'a pas besoin de les gérer"), mauvaise foi et narcissisme sont totalement inutiles pour l'auteur.
"ce sont les objets qui sont communiquant, pas les classes" grosse mauvaise foi, il n'est pas question de faire une distinction entre classe et objet dans mon message de 3 lignes...
"les objets sont des instances de ces services liés à un état abstrait particulier" Il n'est pas plus avancé.
Ma définition était incomplète, exact. Elle était "fausse" ? Non. Elle aide davantage l'auteur qui disait :
"voilà j'ai un énorme soucis par rapport à la programmation objet, c'est que je suis un novice mais vraiment au bas de l'échelle et je ne sais pas par où commencer si je dois commencer par du php objet ou java ou d'autre langages"
Si je cherche la même réponse que l'auteur, et que j'arrive sur ta réponse, je me barre. C'est donc contraire au principe de bon sens du forum. Et tous ensemble, ça fait un bon pavé qui fait fuir les débutants.
Sauf qu'après si tu te barres au premier obstacle rencontré, en l'occurence ici une définition du terme, tu n'iras de toute façon pas loin. Ce n'est pas grave de pas comprendre la définition, bien souvent il faut d'abord utiliser les outils avant de les comprendre. Mais il faut pourtant la garder au coin de la tête, de sorte à éviter de prendre de mauvaises habitudes comme par ex mettre des accesseurs (enfin surtout couple getter + setter) à tout va.
Même moi, ça fait 4 ans de C++ que je fais en discontinu, j'ai encore du mal à toujours rapprocher à la définition d'un objet, ça m'empêche pas de coder, mais à chaque fois je m'efforce de penser aux principes généraux de la POO et d'éviter d'en dévier, de sorte à avoir quelque chose de solide (et sans jeu de mots :D)
Donc, commencer par la théorie EST nécessaire, parce qu'à force de vouloir trouver des cours qui commencent les lignes de code dès le chapitre 2, on tombe sur des cours qui nous font faire un peu n'importe quoi.
@PaulLou, ta définition est proche de celle rencontrée un peu partout.
Sauf que cette définition répandue s'éloigne de la définition historique. Elle pose aussi le problème de perdre les propriétés intéressantes de l'OO pour généralement aboutir à faire un truc orienté données avec des classes. À propos de classes, il faut savoir que le monsieur (Alan Kay) qui a été le premier à dire "Object Oriented" et à qui donc appartient la définition du concept (quoique qu'on en dise, s'il dit que ni Java, ni C++, ni ... ne sont OO, il a raison) a avoué plus tard regretté d'avoir utilisé le mot "objet". A cause de cela, nous sommes tous (à un moment ou un autre) passés à côté de ce qu'il voulait nous montrer, si je puis dire -- J'ai les liens quelque part, Ksass`Peuk aussi, si certains d'entre vous sont intéressés par ces discussions historiques.
Ksass`Peuk a bien mieux décrit que moi les aspects théoriques, et je pense que pour le coup cela commence à débloquer un point où je ne voyais pas de différence (la différence entre TAD et OO). Merci
Bref, recentrons-nous. Que dire d'autre ? L'OO avant de chercher à comprendre sa théorie, il vaut mieux manipuler, quitte à comprendre tous les tenants et aboutissants plus tard. Python et Ruby sont effectivement de bons débuts. Le seul exo qui me plaise sur le sujet, c'est celui du Javaquarium (sur Zeste de Savoir). C'est le seul que j'ai trouvé qui ne confonde pas conception OO avec conception de base de données. Par contre, il montre vite les problèmes du paradigme OO tel qu'il est supporté dans les langages mainstream, car dégainer les Entity Component System (sorte de pattern inventé dans le monde du jeu video), ça démange furieusement.
Ksass Peuk : (1) La condescendance ("on n'a pas besoin de les gérer"), (2) mauvaise foi et (3) narcissisme sont totalement inutiles pour l'auteur.
(1) Comme je l'ai déjà dit, niveau condescendance le "oh pavé mon beau pavé" que tu as répondu, on a déjà du niveau. Surtout que ce post répond à un message argumenté qui explique les problèmes de ton message précédent, qui contenait déjà une attaque gratuite ("pas besoin d'étaler sa confiture").
(2) Je commente juste après.
(3) Non coupable, à force de côtoyer tous les jours des tueurs dans le domaine de l'informatique, on finit par gagner en humilité. Et à admettre par exemple que faire une définition simple de l'objet, ce n'est pas facile, malgré ce que veulent faire croire les "cours" pour débutant les plus communs. Si tu ne le crois pas, tu peux aller voir ce lien : http://wiki.c2.com/?DefinitionsForOo (merci @lmghs), c'est que des définitions différentes pour l'OO, il y en a des pages.
PaulLou a écrit:
(1)"ce sont les objets qui sont communiquant, pas les classes" grosse mauvaise foi, il n'est pas question de faire une distinction entre classe et objet dans mon message de 3 lignes...
Ma définition était incomplète, exact. Elle était "fausse" ? (2) Non.
(1) Pourtant cette distinction est très importante, c'est un des multiples problèmes que peuvent avoir les débutants au début. La difficulté à faire la distinction entre classe (un ensemble) et objet (un élément de l'ensemble) perturbe énormément. Et faire l'amalgame entre les deux dans une définition n'est définitivement pas une bonne chose.
Concernant la mauvaise foi, sérieux ? J'ai posé des arguments précis pour chacun des points que j'ai contredis (j'ai même rectifié au passage des points de ma définition que je trouvais finalement inadaptés). Seulement voilà, il faut lire avant d'attaquer gratuitement derrière, sinon on risque de faire preuve de ... mauvaise foi.
(2) Si, et je le maintiens. Sauf si tu as des arguments à mettre en face de ceux que j'ai donné.
PaulLou a écrit:
Elle aide davantage l'auteur qui disait :
"voilà j'ai un énorme soucis par rapport à la programmation objet, c'est que je suis un novice mais vraiment au bas de l'échelle et je ne sais pas par où commencer si je dois commencer par du php objet ou java ou d'autre langages"
Si je cherche la même réponse que l'auteur, et que j'arrive sur ta réponse, je me barre.
Très honnêtement si en voyant le message tu as la flemme de lire les 3 premières lignes à savoir :
Ksass`Peuk a écrit:
Les bons cours qui causent de POO (et vraiment de POO, pas du bricolage) ne courent pas les rues. A mon avis, tu devrais simplement t'atteler à l'apprentissage d'un langage de programmation permettant l'OO (Python par exemple) et ensuite t'y intéresser d'un point de vue plus théorique pour mieux l'utiliser.
L'informatique n'est probablement pas pour toi. Parce que l'informatique, c'est aussi avoir la patience de faire des pages et pages de lectures. Rien que pour un truc aussi con que la documentation, et encore bien plus quand on cherche à acquérir des notions plus avancées.
lmghs a écrit:
Ksass`Peuk a bien mieux décrit que moi les aspects théoriques, et je pense que pour le coup cela commence à débloquer un point où je ne voyais pas de différence (la différence entre TAD et OO). Merci
Sur la variance ? C'est ce qui m'a le plus secoué quand j'ai lu le papier de Cook. C'est pour ça que j'ai décalé le début de la rédaction du tutoriel sur l'OO (ça et le questionnement sur le respect systématique du DIP à titre pédagogique).
lmghs a écrit:
Le seul exo qui me plaise sur le sujet, c'est celui du Javaquarium (sur Zeste de Savoir). C'est le seul que j'ai trouvé qui ne confonde pas conception OO avec conception de base de données.
Maintenant, je le file à mes étudiants à faire en boulot supplémentaire, on verra les effets dans quelques semaines, pour ceux qui auront pris le temps de le faire bien sûr.
Ksass`Peuk a bien mieux décrit que moi les aspects théoriques, et je pense que pour le coup cela commence à débloquer un point où je ne voyais pas de différence (la différence entre TAD et OO). Merci
Sur la variance ? C'est ce qui m'a le plus secoué quand j'ai lu le papier de Cook. C'est pour ça que j'ai décalé le début de la rédaction du tutoriel sur l'OO (ça et le questionnement sur le respect systématique du DIP à titre pédagogique).
Je t'avoue que je ne sais plus depuis le temps. C'était surtout que ma vision OO est (/était) très orientées par mes outils, et que je n'aime vraiment pas du tout le typage dynamique. Du coup, les classes, j'aime. Et jusqu'à présent, j'avais tendance à considérer que des choses comme FILE, ou std::stack<>, sont des parfait exemples de T.A.D. Et de fait, je tendais à ne pas faire de différence entre une classe et un T.A.D. Et effectivement, quand on réintroduit le dynamisme cher à A. Kay dans la boucle, ça va changer des choses.
Bref, Je suis impatient de voir ce que tu vas bien pouvoir synthétiser avec toutes les références que tu as croisées
lmghs a écrit:
Le seul exo qui me plaise sur le sujet, c'est celui du Javaquarium (sur Zeste de Savoir). C'est le seul que j'ai trouvé qui ne confonde pas conception OO avec conception de base de données.
Maintenant, je le file à mes étudiants à faire en boulot supplémentaire, on verra les effets dans quelques semaines, pour ceux qui auront pris le temps de le faire bien sûr.
Je l'avais donné aussi en devoir à la maison dans mes formations, mais n'ai jamais eu de retour malheureusement
Bonjour à touts désolé pour ce grand retard mais entre la fin de ma formation et le stage j'ai pas eu une seconde pour regarder le topic qui est parti en live malheureusement alors en fait il faut que je commence par le ruby pour commencer à comprendre l'OO ensuite oui j'ai appris ( et mis en pratique ) les design patterns mais je n'ai toujours pas compris leur fonctionnement comment les utiliser et quoi mettre dedans. Au final là je vais reprendre doucement l'orienté web et ensuite vers l'orienté objet
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Architecte logiciel - Software craftsmanship convaincu.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Architecte logiciel - Software craftsmanship convaincu.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Je ne suis plus modérateur, ne me contactez plus pour des demandes, je n'y répondrai pas.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C