Est-ce que je connais si bien la POO que ce que je crois ?

Le problème exposé dans ce sujet a été résolu.

Bonjour !

Avant tout, je précise que j’ai un parcours "autodidacte" et que je pense avoir appris la programmation en faisant des projets perso et en suivant des cours sur divers sites (Zeste de savoir, OC, des sites moins connus, des books de langage, la doc) et un mastère

Je pensais connaître la POO plutôt bien et je dois dire que récemment, j’ai eu un petit choc. Je pense qu’en faites, je n’ai jamais réellement fait de la POO.

J’ai ainsi plusieurs questions :

Qu’est-ce qu’une classe devrait réellement représenter?

Exemple :

const users = [
    { name: "Jean" },
    { name: "Paul" },
    { name: "Phillipe" },
    { name: "Antoine" }
]
 
function sortUser(users, condition) {
    // code 
    return users 
} 


const usersSort = sortUser(users, ...) 

Ici, j’aurai eu tendance à faire :


class UserList {
    private _name: string[];

    constructor(name: string[]) {
        this._name = name;
    } 

    sort(users, condition) {
        return users;
    }
} 

Mais je n’aurai pas plutôt dû faire une classe User / UserSorted ? Si oui sous quelle forme ? J’ai du mal à le visualiser.

Qu’est ce réellement que l’encapsulation ?

J’ai toujours cru que l’encapsulation voulait simplement dire : "Ok, j’ai une propriété privée mais je veux pouvoir y accéder et la modifier proprement" ce qui signifie getter/setter

Sauf qu’apparemment, il ne faudrait plus pouvoir modifier l’état d’un objet, une fois créer non ? Donc qu’est-ce qu’est l’encapsulation réellement ?

Javascript est-il réellement un bon exemple ?

J’ai l’impression que cette logique de bosser sous forme de classe est plutôt bonne en Java, C# et que le langage incite à travailler de la sorte mais si on prend l’exemple de Javascript, est-ce vraiment une bonne chose ?

Rust & Go

Comment vous feriez pour appliquer cette même logique OOP dans un langage comme Rust et Go qui ne comporte pas de classe ? (mais plutôt des strictes / implémentations des strictes ?

Si la réponse est : "Rust & Go ne sont pas des langages de programmation orienté objet" alors ma réponse sera : "Comment réfléchir pour concevoir ses programmes en Rust ou Go ?" (même si la réponse est forcément dépendante du langage et ne sera sûrement pas la même en fonction de Rust ou Go justement.

Je suis un peu sur le cul haha, (ce livre en est la cause

+0 -0

Lu’!

Si tu veux, il y quelques temps on avait discuté un peu ici.

Mais le point de base c’est qu’il n’y a pas de définition universelle de ce qu’est l’OO. Je suis de plus en plus convaincu que notre découpage en paradigmes crée des boîtes bien trop grandes pour qu’on puisse en tirer de quelconques généralités intéressantes.

Néanmoins pour l’encapsulation, ça consiste à cacher les détails d’implémentation de fonctionnalités pour permettre un usage externe (presque) indépendant de ce qui se passe en interne. Ça touche plus largement la conception que juste l’OO ou même le logiciel. Un processeur fournit une forme d’encapsulation.

Merci pour ta réponse Peuk, je vais regarder ça

ça consiste à cacher les détails d’implémentation de fonctionnalités pour permettre un usage externe (presque) indépendant de ce qui se passe en interne.

Je ne suis pas sûr de bien me l’imaginer, tu pourrais me faire un exemple de code pour que je puisse mieux me le situer ?

Salut Big blob

Je l’ai déjà fais, je travaille déjà en entreprise sur des framework / tools qui donnent un design mais ce n’est pas une garantie de bien faire les choses dans les autres cas puisque actuellement je dois travailler justement sans cadre

+1 -0

Quant à JavaScript c’est pas vraiment de la POO mais plutôt du prototype-based programming.

Je cite le lien Wikipédia que tu donnes:

Prototype-based programming is a style of object-oriented programming

Mais le lien en Français est plus claire bien que moins complet.

La programmation orientée prototype est une forme de programmation orientée objet sans classe, fondée sur la notion de prototype.

Au même titre que Class-based programming, c’est un style de POO.

+1 -0

Le problème Big, c’est que je ne pense pas être le bon public pour ce conseil, je ne suis pas un pur débutant en programmation qui apprend.

Je cherche juste à mieux comprendre la théorie de ce que j’utilise au quotidien pour me perfectionner.

+0 -0

Quand tu arrives à un certains niveau de compréhension de tes outils (suffisant pour les utiliser) et pour être "employable" puis que tu acquières un peu d’expérience pro (3 ans pour moi). Ce qui peut te faire vraiment progresser au delà de la pratique, c’est la théorie pour bien comprendre certaines notions que tu penses savoir utiliser.

Ce que j’essaie de dire, c’est qu’il y a une différence entre savoir faire des classes, interface etc pour faire un produit et le faire correctement (comme la théorie le voudrait).

Humm, ce que tu me sembles chercher ce sont “règles” ou plutôt des “principes” de base de l’ingénierie logiciel.

Je t’invite à te renseigner sur les principes SOLID et la loi de déméter. :)

Ça te permettra de bien comprendre le pourquoi des patrons de conception.

+3 -0

Je ne suis pas sûr de bien me l’imaginer, tu pourrais me faire un exemple de code pour que je puisse mieux me le situer ?

Imagine que tu veux payer à la caisse d’un magasin avec ta carte bleue. Et, pour ça, la personne en face de toi peut prendre ton pantalon, chercher ton portefeuille et y récupérer ta carte bleue.

Tu y retournes et tu mets ta carte bleue dans ton sac. Tu risques d’avoir un problème au moment de payer…

Les personnes autour de toi n’ont pas besoin de savoir où et comment tu ranges ta carte bleue. Et, ne doivent surtout pas à se baser sur la façon dont tu ranges ta carte bleue parce que le jour où tu la ranges différemment, ça va coincer.

Par contre, quand tu veux payer en caisse, la personne peut te demander ta carte bleue (ou simplement de payer). A toi, de savoir où elle est ou même de choisir comment tu veux régler (par sans contact, avec code, etc.).

L’encapsulation, c’est pareil : un objet n’a pas à exposer la façon dont il gère ses informations ou ses traitements. S’il le fait, il s’expose à ce que les autres objets se basent dessus et empêchent toute évolution/modification. Il doit donc rester le seul maître de son propre fonctionnement en interne (comment il stocke ses attributs, par exemple) pour pouvoir évoluer en limitant l’impact sur les autres.

Un objet doit uniquement proposer des méthodes qui permettent d’interagir avec lui et qui correspondent aux comportements que tu veux lui donner (être capable de payer, par exemple)

Un autre exemple est celui d’une voiture dont on veut contrôler la vitesse. Les lois de la physique m’interdisent de passer de 0 à 100 km/h instantanément : il y a forcément une phase d’accélération aussi courte soit-elle.

Si je laisse mon champ vitesse accessible, n’importe qui peut mettre la vitesse qu’il veut et casser les lois de la physique. Maintenant, si je cache ce champ (en le mettant en privé, par exemple) et que je ne propose que des méthodes accélérerJusqua et ralentirA, je peux assurer moi-même le respect de la physique.

En plus de cela, je pourrai très bien décider de gérer ma vitesse avec un double plutôt qu’un entier, voire avec un autre objet. Tant que je ne touche pas à mes méthodes publiques, ça n’aura d’impact sur personne d’autre que moi-même.

notre découpage en paradigmes crée des boîtes bien trop grandes pour qu’on puisse en tirer de quelconques généralités intéressantes.

Ksass`Peuk

Je reviens la dessus. Je suppose que tu parles en termes de code ?

Pour ce qui est l’apprentissage, même si c’est une notion artificielle, je trouve qu’elle est intéressante, parce qu’elle simplifie les choses pour l’apprenant. C’est plus simple d’apprendre des archétypes facilement reconnaissables et utilisables, plutôt qu’un joyeux bordel dans lequel il est difficile d’organiser les notions.

(Idem pour les sémantiques de classes)

+0 -0

(je laisse volontairement les sémantiques de classe à la C++ hors scope, pour moi c’est une erreur de design du langage qui rend ça nécessaire à traiter et c’est de toute façon spécique à C++)

Je parle en terme de notion de base. Je pense que dire à des étudiants "maintenant on va faire de l’OO" en employant pour ça une définition qui n’est de toute façon pas universelle et en y regroupant tout un tas de trucs dont certains qui ne sont même pas communs à tous les langages dits OO ou même carrément pas spécifiques à l’OO du tout, ne simplifie rien au final.

Truc typique, les cours d’OO commencent en parlant d’encapsulation. C’est très bien l’encapsulation. Mais c’est pas spécifique à l’OO et la notion vaudrait bien plus à être expliquée plus largement que ça, juste après la notion d’interface qui est également plus large que l’OO. Concevoir une belle interface et bien encapsuler c’est central en prog et ça ne nécessite absolument pas de faire intervenir la notion d’objet.

A partir de ces connaissances là parler de classe et d’objet est simple. Et on peut ensuite enchaîner sans problème sur la notion de substituabilité avec les diverses formes de polymorphisme.

En faisant ça, on obtient rien de foutraque dans l’explication et on n’est pas obligé de sortir du chapeau des définitions foireuses qui à mon sens n’éclairent même pas les débutants.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte