Formation informatique

Répondre
Partager Rechercher
Citation :
Publié par Erlum
Ben garder les attributs privés, c'est quand même une très bonne manière de dissocier l'intention et la manière effective qu'on utilise pour changer les attributs. Je ne capte pas trop l'intérêt de faire autrement, si ce n'est la simplicité.
Ça dépend des attributs, et surtout du contenu des setters. Si c'est juste une fonction qui recopie bêtement la valeur dans l'attribut, autant le laisser public.

On en fait tout un paradigme en C++ alors que dans d'autres langages (Python en tout cas) le concept même d'attribut / méthode privée n'existe pas. Il y a des conventions pour indiquer au programmeur qu'un attribut n'est pas censé être modifié depuis l'extérieur, mais c'est tout. En C++ c'est le langage qui peut faire barrière, et si tu veux faire un truc pas prévu faut aller modifier le .h - ou faire une classe fille si le programmeur a pensé à écrire protected au lieu de private.
Citation :
Publié par Erlum
Ben garder les attributs privés, c'est quand même une très bonne manière de dissocier l'intention et la manière effective qu'on utilise pour changer les attributs. Je ne capte pas trop l'intérêt de faire autrement, si ce n'est la simplicité.

Sinon quel est ton problème avec Swing ?
Le débat est bien connu donc je vais pas reprendre tous les longs arguments ici, mais il ne s'agit pas de remettre en cause la visibilité privée des attributs d'une classe, bien sûr. Par contre avoir des attributs "privés", mais les exposer presque directement à travers trouze mille get et set machin, c'est non seulement lourd mais montre surtout que sur le fond, on expose complètement la structure des données de la classe, ce qui va au final à l'encontre du principe de découplage.

"Un objet fait ce qu'on lui demande", et non "on fait ce qu'on veut avec l'information qu'on obtient de l'objet".

Pour Swing c'est loin, j'avais trouvé ça mega lourd à l'époque, et c'était en comparaison (ouch) de wxWidgets à l'epoque si je me souviens bien.
Citation :
Publié par Erlum
Ben garder les attributs privés, c'est quand même une très bonne manière de dissocier l'intention et la manière effective qu'on utilise pour changer les attributs. Je ne capte pas trop l'intérêt de faire autrement, si ce n'est la simplicité.
C'est surtout que pas mal de gens génèrent automatiquement les getters et setters via l'IDE par défaut, alors que les attributs devraient être set par le constructeur et éventuellement modifiés via des méthodes et non via des setters (ou mieux, essayer d'avoir de l'immutabilité au maximum, mais là c'est une autre histoire surtout en Java qui est assez limité sur cet aspect).

Sinon tous les langages ont leur utilité, Java on en a parlé avant, C# on va le retrouver dans les boites Microsoft, C/C++ est encore largement utilisé car quand on a des contraintes de perf on a pas trop le choix si on veut pas de GC, Python pour le dev système et qui est également utilisé par de nombreux chercheurs, PHP pour du dev web, Swift chez Apple, Javascript pour le front, après il y a également pas mal de niches (Scala, Go qu'on retrouve de plus en plus pour les dev système/infrastructure, Clojure...). Mais bon, faudrait split dans un autre sujet pour continuer cette discussion

Dernière modification par Nelphit ; 04/05/2018 à 23h10.
Citation :
Publié par Caniveau Royal
Personne n'écrira plus jamais autre chose qu'une application de jeu avec C++, désormais.
Les applications scientifiques auront Python ou R, celles système : C, et la plupart des autres Java.
Tjs utilisé dans l'industrie par de grosses boites pour produire des programme >10M€.
Citation :
Publié par Erlum
C# se place vraiment en concurrent de Java, j'en fais un petit peu ces derniers temps pour un projet et t'as vraiment l'impression que c'est un bon gros ripoff.

Par contre j'ai vraiment du mal avec un truc : contrairement au Java, il est visiblement très fréquent d'accéder directement (donc sans setter/getter) aux attributs d'un objet.
C'est un "bon gros ripoff" qui fait à peu prêt tout en mieux (en terme de productivité / plaisir pour le dev). C'était juste une petite plaie parce que c'était relativement locké Microsoft, mais avec Net Core c'est un véritable plaisir. Microsoft ont vraiment de très bons produits depuis qu'ils ont changé un peu leur direction, et VS Code est une véritable merveille de productivité (lisez leurs patch notes mensuels ...).

En dehors de ça, tu n'accèdes pas "directement" aux attributs d'un objet. Je suis presque sur que tu parles des properties. Quand tu écris quelque chose comme :

Code:
class Person {
    public string Name { get; set; }
}
Ce qui est généré c'est en gros l'équivalent de :

Code:
class Person {
    private string _name;
    
    public string GetName() {
        return _name;
    }

    public void SetName(string name) {
        _name = name;
    }
}
C'est juste du sucre syntaxique dans ce cas. Tu n'y accède pas plus directement qu'en Java. Je simplifie un peu parce que les properties sont un peu plus que du sucre syntaxique, mais les auto properties (qui donnent l'impression d'accéder directement aux membres) le sont.
Citation :
Publié par Assurancetourix
Exemple de type d'evil getter/setter alors qu'on devrait penser à l'immutabilité comme le notait Nelphit, par ailleurs.
Je ne suis pas sûr d'avoir compris. Quel est l'enjeu d'avoir des objets immuables ?

Compris: sûrement des problématiques de multithreading. Mais au jour le jour je bosse à 99,9% sur une partie monothread de notre soft d'où l'absence de problématiques de ce genre.

Dernière modification par Ex-voto ; 04/05/2018 à 22h21.
Citation :
Publié par Ex-voto
Je ne suis pas sûr d'avoir compris. Quel est l'enjeu d'avoir des objets immuables ?
Ben ici, est-ce qu'une personne change souvent de nom, et dans quelles conditions? Quand est-ce qu'une personne reçoit son nom?

Citation :
alors que les attributs devraient être set par le constructeur et éventuellement modifiés via des méthodes et non via des setters (ou mieux, essayer d'avoir de l'immutabilité au maximum
Citation :
Publié par Ex-voto
Je ne suis pas sûr d'avoir compris. Quel est l'enjeu d'avoir des objets immuable?.
Tout depend de l'objet de mon point de vue.

Si tu boss avec des pojo tu ten tappe.
Dire le contraire est juste un moyen de complexifier un process qui na pas besoin de letre.

Dans dautre cas limmutabilite permet de proteger un objet dun changement effectué par un dev un peu trop junior.
Citation :
Publié par Nelphit
C'est surtout que pas mal de gens génèrent automatiquement les getters et setters via l'IDE par défaut, alors que les attributs devraient être set par le constructeur et éventuellement modifiés via des méthodes et non via des setters (ou mieux, essayer d'avoir de l'immutabilité au maximum, mais là c'est une autre histoire surtout en Java qui est assez limité sur cet aspect).)
oui l'injection de dépendance permet de résoudre ce problème. + le fait de s'orienter vers du "Tell, don't ask".

L'intérêt de garder les attributs privé, c'est de maîtriser le périmètre de ta classe. Tu sais que si quelqu'un l'utilise, il va pas la faire buger en faisant n'importe quoi avec ses attributs. Et toi de ton côté, tu sais que comme ton attribut est privé, personne l'utilise de l'extérieur donc tu peux bien le gérer comme tu veux sans provoquer d'effet de bord. Si tu laisses tes attributs en public, ça va être la merde niveau maintenance et refacto car ça va être la galère pour savoir si quelqu'un a décidé de jouer avec à un autre endroit dans le code.

Par défaut, tout ce qui n'est pas destiné à être utiliser de l'extérieur de ta classe est en private, voir protected si tu souhaite ouvrir tout ou partir de ta classe à la surcharge. Cela évitera pas mal de déconvenue dans quelques mois, années

Pour les objets imutables, j'ai d'exemple en tête. Un des intérêts est que si ton objet est amené à se balader un peu dans le code de ton appli, il risque pas d'être modifier par erreur et du coup provoquer un bug en aval. Si vraiment t'as besoin d'avoir une version modifiés de cet objet, tu peux le cloner (toi à la main, ou alors ta genre le setter qui renvoi un clone de l'objet).

Dernière modification par Hiolaltios ; 05/05/2018 à 00h01.
Citation :
Publié par punkoff
Tout depend de l'objet de mon point de vue.

Si tu boss avec des pojo tu ten tappe.
Dire le contraire est juste un moyen de complexifier un process qui na pas besoin de letre.

Dans dautre cas limmutabilite permet de proteger un objet dun changement effectué par un dev un peu trop junior.
Bon je vais dériver en H.S complet mais tant pis.

L'immutabilité c'est avant tout pour éviter les effets de bords, qui sont une cause très fréquente de bugs. Un programme où (presque) tout est immutable est beaucoup plus maintenable qu'un où chaque action risque de provoquer un effet de bord à l'autre bout du programme.

Prenons un programme classique: il reçoit une requête HTTP, fait un traitement sur le contenu de la requête, fait un appel à une base de données et récupère des données, fait des traitements dessus, retourne ces données.
Ici, quelles sont les états ? Le serveur HTTP (qui tourne en permanence et reçoit des requêtes), et la connexion/threadpool vers la base de données. Tout le reste du programme peut être représenté comme une série de transformations prenant des données et les transformant (en gros des fonctions). Pourquoi j'aurais besoin d'un état ici ?

Mon traitement n'est donc pas: objet mutable 1 => je modifie l'objet => je modifie l'objet... (donc toujours ce même objet qui ne change jamais mais évolue au cours du temps) mais plutôt donnée immutable => nouvelle version de la donnée immutable => nouvelle version ... Je n'ai plus peur d'avoir un effet de bord, je peux raisonner simplement sur mon problème qui n'est plus qu'une série de fonctions indépendantes que j'applique sur ma donnée. Bref, de la programmation fonctionnelle.
De plus, les états (comme mon threadpool de ma base de données dans mon exemple précédent) sont explicitement identifiés, donc je sais exactement où je dois faire attention dans mon programme.

Java n'encourage pas du tout cela (entre autre car n'est pas un langage fonctionnel), mais on peut essayer quand même de limiter le nombre d'états dans nos programmes (mais bon c'est ultra compliqué pour pleins de raisons en Java), en interdisant la modification d'un objet une fois créé par exemple (car en réalité, un objet en Java a souvent d'autres objets en attributs, qui ont eux même d'autres objets en attributs, avec des références vers tout ce beau monde qui se baladent/sont injectées à droite à gauche).
De manière générale, la programmation objet à la Java a été survendue dans les années 90/début 2000 comme solution miracle et a été utilisé par défaut partout, heureusement on commence (un peu) à en revenir.
JS/JQuery pour le front, PHP pour le back. HTML/CSS/MYSQL obviously.
Ensuite seulement voir les notions d'OOP, de templating, de framework, de préprocesseur CSS et tout le reste.
Citation :
Publié par Caniveau Royal
Personne n'écrira plus jamais autre chose qu'une application de jeu avec C++, désormais.
Les applications scientifiques auront Python ou R, celles système : C, et la plupart des autres Java.
Ha ouais bah ouais :>

Citation :
Publié par Mimu
Ne touche pas à JQuery par pitié. On est en 2018.
Un peu ce que je me disais, aussi. Aujourd'hui le marché c'est React (lib) et Angular (framework). Bon il y a évidemment Vue (lib ou framework suivant l'utilisation qu'on en a), qui se veut être la meilleure option pour un débutant, mais c'est moins recherché niveau pro. JQuery c'est du legacy (donc forcément y'a encore des offres) et tout le monde essaye de s'en débarrasser. Les offres JQuery chutent rapidement au profit des offres React (et Angular, mais de ce que j'ai pu voir React reste le plus demandé). C'est aussi lié au fait que le monde js s'est un peu remis au niveau ces dernières années (même si ça reste dégueulasse, mais c'est ce qu'il se passe quand un language design dans un coin de table de restaurant devient la référence web) et donc que ce qu'apportait JQuery est désormais natif.

Pour la remarque juste au-dessus : ça n'a aucun sens de vouloir "apprendre react plutôt que js". React est une lib js. Tu commences toujours par apprendre les bases, tu vas pas balancer un mec n'ayant jamais touché au dev directement sur react.

Un chemin classique de formation frontend suit à peu prêt le chemin suivant :

  1. Apprendre les bases. Comprendre, se faire la main avec HTML / CSS / Javascript. Il y a quelques années on aurait rajouté JQuery dans les bases, mais c'est plus la peine de passer par là. Non pas que ce soit nécessairement une mauvaise idée que d'essayer, mais c'est vraiment plus dans une roadmap classique.
  2. Appronfondir un peu les sujets. Pour JS, ça veut dire être à jour par rapport à ES6 (ou ES2015, appelez ça comme vous voulez). Pour CSS, ça veut dire se faire la main sur des préprocesseurs (sass aujourd'hui ...), mais là c'est loin d'être un requis (chez React ils sont pas fan de ça par exemple).
  3. Se faire la main avec le tooling. Avec la cli angular et le starter react, c'est pas la peine pour un novice de se casser les couilles avec webpack / requirejs / bazel / gulp / grunt / w.e, c'est quelque chose qui passe sous le capot et y'a probablement moins de suicides depuis. Par contre au moins se faire la main sur Yarn (ou npm pour ceux qui n'aiment pas la vie) et les npm scripts, mais ça c'est l'objet de 2h. En dehors côté spécialisé JS, prendre en main Git, au moins les bases, mais ça c'est quelque chose qu'il est impératif de faire avant de passer à la suite (et ça te sera utile toute ta carrière, où que tu sois, quoi que tu fasses).
  4. Se faire la main sur les frameworks, que ce soit css ou js. Dans le cas js, en restant sur les deux options que sont React et Angular, les chemins seront un peu différents (anw ça dépendra entièrement de sa formation). Si tu vas vers Angular, il faudra impérativement te faire la main sur typescript avant (qui est une véritable merveille et l'unique chose qui a rendu le front agréable à dev). En gros Typescript est un superset typé de Javascript. Si tu vas vers React (qui n'est pas un framework, mais ...), c'est pas une nécessité et ça pourra attendre le futur (et je dirais même que ça doit attendre, l'intégration react-typescript n'est pas évidente pour un débutant, d'autant plus que c'est plus branché Flow côté React). Côté framework CSS tu as Bootstrap ou Bulma (qui est plus sympathique et complet à l'utilisation imo).
  5. Se faire la main sur les frameworks de tests. Si tu es plutôt React, tu rencontreras Jest. Si tu es plutôt Angular, ce sera Karma (qui est par dessus Jasmine ...). L'un ou l'autre c'est pas très grave, ce sont juste les options par défaut et donc celles les plus faciles à utiliser, mais autrement rien ne t'empêche d'utiliser Jest avec Angular. Le choix n'a vraiment pas d'importance ici, ce sont les concepts qui sont importants.
  6. Continuer ta vie ... rxjs, redux, ngrx, angular material, material ui, w/e, t'auras toujours des tonnes de trucs à découvrir. En parallèle t'auras surement l'occasion de découvrir le monde un peu plus orienté devops type docker/jenkins/travis/kubernets/ansible/aws..., mais c'est clairement pas tes priorités.
Sachant qu'on peut toujours varier un peu l'ordre (par exemple tout ce qui est tests ça peut être faire en parallèle de l'apprentissage js / react / angular, les frameworks css ça peut se voir avant les frameworks js). mais autrement c'est globalement la ligne la plus logique.

Si jamais on te laisse le choix du framework, l'ordre de facilité est Vue > React > Angular. Au niveau des perspectives pros, ou en tout cas du nombre d'offres, je dirais que c'est React > Angular >>> Vue. J'apprécie Angular, mais il y a plus d'un concept qui sera loin d'être évident pour un mec qui commence sa formation dev (même si on peut toujours utiliser les concepts sans rien comprendre, mais imo c'est pas la solution ...). Même pour des mecs qui ont de l'expérience d'ailleurs, mais là on parle plus souvent de mecs à la ramasse (le nombre de dev front qui se plaignent qu'un langage typé comme typescript c'est trop de contraintes finira par me tuer).

Côté backend je m'avancerais sur rien pour le PHP, je suis plus côté .net ou java sur ce plan là, mais je suppose que tu risques de voir passer php7 + laravel ou symfony + composer + mysql ou postgres (plus de chance pour mysql :>, ou mariadb mais c'est kiff kiff à ce stade) et les patterns qui vont avec.
Citation :
Publié par Squeef
Pour la remarque juste au-dessus : ça n'a aucun sens de vouloir "apprendre react plutôt que js". React est une lib js. Tu commences toujours par apprendre les bases, tu vas pas balancer un mec n'ayant jamais touché au dev directement sur react.
Disons que selon le fwk qu'il va choisir, il ne fera pas forcément du js ... vu qu'il finira par faire du typescript.

Dernière modification par Fio' ; 06/05/2018 à 10h30.
Certes, mais Typescript est un superset de Javascript. Derrière ça compile aussi en Javascript et tu retrouves les mêmes limitations et les mêmes choses à apprendre (closure par exemple, même si c'est moins ennuyant maintenant qu'on a let/const plutôt que cette merde de var). Passer par du js avant ne peut pas faire de mal, ne serait-ce que pour voir la différence qu'on a en terme de productivité / tooling / prévention de bugs incroyablement débiles / ... en ayant du typage statique (du moins en théorie, en pratique tu peux toujours foutre du any partout et perdre la majorité des intérêts).

Ceci étant, je suis plus du genre à penser que personne ne devrait écrire directement du js et je comprend pas que certains arrivent à le faire sans se tirer une balle, donc j'aurais aussi envie de recommander de se jeter sur Typescript directement. Je doute que ça dépende de lui de toute façon, mais ça risque de lui faire mal au cul quand il tombera dans un endroit sans ts (ou flow, même si je recommanderais pas de passer par là).
Citation :
Publié par BadProsper
N’importe quoi genre quoi ?
Par exemple, un des attributs public contient un objet. Quelqu'un fait muter volontairement ou involontairement cet objet et ça peut provoquer des bugs dans ta classe.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés