Discussion :

[jahmanzaar]

Bonjour bonjour,
aujourd'hui, petite question sur les classes :

Après de longues nuits d'effort, j'ai une toute belle classe Actor qui s'occupe de tout ce qui concerne un Actor (création, affichage, changement de coordonnées ...etc).

De façon un peu brutale, j'ai ajouter à mon code hors classe actor la gestion des interractions entre les différents Actors (collisions, attractions ...), seulement je voudrais mettre un peu d'ordre à tout cela maintenant que la partie mathématique est callée.


D'ou mes interrogations :
1 - Cette classe Actor pourrait elle gérer deux Actors déja créés?
A priori je ne crois pas, d'ou ma 2nd intérrogation :
2 - Puis je passer par une classe genre 'Gestion_Actor', ce que je serais tenté de faire avec vraisemblamement l'utilisation de Friend que je ne connait pas encore ?
Ma question est alors la suivante (Friend, je devrais m'en sortir) :
Dans ce cas, Comment je fais pour le constructeur (a piori, je lui 'passe' deux objets Actors), mais ce ne serais pas vraiment une classe d'objets mais plus de fonctions sur des objets .....

En gros, je sais pas trop comment m'en sortir.

Quelqu'un peut il m'aiguiller sur ce sujet ?
Grand merci d'avance.

[Florian Goo]

Bonjour,

« Paas claaaaaasse ! » (en espérant qu'on ait les mêmes références)

Déjà, vu la description de ta classe Actor, tu m'as l'air de violer le principe de responsabilité unique, très bien expliqué ici : http://blog.emmanueldeloget.com/inde...abilite-unique

Remanie un peu ta base, de meilleures idées en découleront plus intuitivement !

[jahmanzaar]

blog fort instructif

je vais revoir un peu tout ça .....

m'enfin, ca m'aurais quand meme arrangé d'avoir une jolie classe GestActor dans laquelle j'aurais pu mettre toute la machinerie de gestion entre mes actors.

je vais mouliner un chouia tout ca et je repasse

merci

[koala01]

Salut,

Déjà, vu la description de ta classe Actor, tu m'as l'air de violer le principe de responsabilité unique, très bien expliqué ici : http://blog.emmanueldeloget.com/inde...abilite-unique

Attention, "responsabilité unique" ne veut pas dire "unique service rendu"

Si une classe fournit une grande quantité de services qui vont dans le sens où ils permettent à cette classe de prendre son (unique) responsabilité, tu respecte parfaitement la règle de la responsabilité unique

Qu'il suffise de voir la classe std::string pour se convaincre que de nombreux services (toutes les méthodes qu'elles contient), tendent vers la responsabilité que l'on a défini pour elle: permettre la gestion des chaines de caractères

Ceci dit, effectivement, la responsabilité de la gestion de deux acteurs et des inter-actions qui les unissent est sensiblement à déléguer à une classe "qui n'aurait que cela à faire" (ce qui sera déjà pas mal )

Un pattern "mediateur" ou "visiteur" semble a priori un choix intéressant

[jahmanzaar]

Je m'orientais effectivement vers la notion de 'service rendu', qui me parrait plus juste.

Cette précision me rassure dans la compréhension encore douteuse que j'ai du C++
merci à vous deux

[HanLee]

Qu'il suffise de voir la classe std::string pour se convaincre que de nombreux services (toutes les méthodes qu'elles contient), tendent vers la responsabilité que l'on a défini pour elle: permettre la gestion des chaines de caractères

Ben, std::string est peut-être le mauvais exemple.
Herb Sutter par exemple considère que la classe std::string en fait trop.

http://www.gotw.ca/gotw/084.htm

Je dois dire que je suis assez d'accord parce que j'aime les classes dont l'interface est simple et efficace, et qui fournit les opérations minimales (~ axiomes) nécessaires pour faire tout ce dont on a besoin, avec l'efficacité optimale.

[Alp]

Ben, std::string est peut-être le mauvais exemple.
Herb Sutter par exemple considère que la classe std::string en fait trop.

http://www.gotw.ca/gotw/084.htm

Je dois dire que je suis assez d'accord parce que j'aime les classes dont l'interface est simple et efficace, et qui fournit les opérations minimales (~ axiomes) nécessaires pour faire tout ce dont on a besoin, avec l'efficacité optimale.

C'est un avis qui me semble être majoritairement accepté et promu dans la communauté des experts C++. On qualifie souvent std::string de classe "fourre-tout"...

[koala01]

C'est un avis qui me semble être majoritairement accepté et promu dans la communauté des experts C++. On qualifie souvent std::string de classe "fourre-tout"...

Comprenons nous bien, je la qualifie aussi volontiers de "fourre tout", ou de "couteau suisse"...

Mais il n'empêche que j'apprécie de pouvoir parcourir la chaine dans tous les sens en n'ayant qu'une seule classe à gérer...

Le problème est toujours le même: un fois que tu sors des concepts de base de la programmation (pile, file, liste, arbre binaire), tu en viens rapidement à penser en responsabilité plus génériques... Et même au sujet de ces concepts de base, on peut envisager des responsabilité plus ou moins importante

D'ailleurs, quand tu regarde la plupart des conteneurs de la STL, tu te dis que la std::string n'est pas *forcément* une exception, et, quand tu commence à programmer de manière un peu intensive, tu remarque aussi rapidement que certaines classes vont devoir gérer plusieurs membres a priori "sans rapport entre eux", juste pour pouvoir remplir la responsabilité que tu as donné à ta classe

[koala01]

Il est vrai que std::string en fait énormément...

Cependant, la responsabilité de "gérer une chaine de caractères" peut tout à fait comprendre le fait de permettre de récupérer une sous chaine, de chercher la position d'un caractère ou d'une chaine de caractère dans la chaine d'origine, ...

On peut discuter du choix fait par les auteurs de la norme sur la "granularité" de la responsabilité de cette classe, mais, à tord ou à raison, c'est le choix qui a été fait.

Il arrivera toujours un moment où tu devra quand même choisir un responsabilité "générique" pour arriver à gérer l'ensemble des classes plus "spécialisées"...


On peut, et c'est presque conseillé, partir de classes dont la responsabilité est minimale, je dirais presque "atomique".

Mais, tôt ou tard, tu finira toujours par devoir regrouper deux (ou plus) de ces classes dans une autre qui aura une responsabilité plus "imprécise", avec comme conséquence qu'elle devra fournir "plus de services"...