classe, pas classe ?

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.

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 !

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 :D

Salut,

Citation:

---

Envoyé par Florian Goo

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 :D)

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

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

Citation:

---

Envoyé par koala01

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.

Citation:

---

Envoyé par HanLee

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"... :)

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"...

Citation:

---

Envoyé par Alp

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 ;)

Citation:

---

Envoyé par koala01

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,

---

Hmmm... C'est quand même la seule qui en est à ce point !
La plupart offrent l'interface nécessaire aux algos de la STL !
Bon ok, on ne demande pas autant de services aux conteneurs de la STL, mais bon. L'avis partagé par beaucoup d'experts est que certaines choses auraient pu (dû ?) être factorisées dans des algos génériques plutôt qu'à l'intérieur de std::string.

Citation:

---

Envoyé par koala01

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 ;)

---

Je vois tout à fait ce que tu veux dire. Les classes "Game" pour les jeux ou "Application" pour les "utilitaires", par exemple. Il y a effectivement très très souvent des classes qui servent juste à regrouper.

M'enfin, il faut quand même si possible donner à une classe une et une seule responsabilité. C'est un principe clé.

Citation:

---

Envoyé par Alp

M'enfin, il faut quand même si possible donner à une classe une et une seule responsabilité. C'est un principe clé.

---

Une et une seule responsabilité, oui - du moins autant que possible - mais cela ne signifie pas un et un seul service rendu par la classe...

Finalement, malgré que la responsabilité d'un classe soit unique, dés le moment où elle manipule plus d'un membre, tu va voir le nombre de services rendu (de "message émis /recus" littéralement exploser parce que chaque membre pris "un à un" permet déjà, à l'extrème limite de fournir deux messages particuliers, mais qu'apres les membres peuvent être pris de manière groupée, et que ca permet une infinité de message.

C'est en cela que je fais remarquer que "responsabilité unique" ne veux pas *forcément* dire "service rendu unique", même si, et nous sommes tous d'accord là dessus, l'idéal est quand même toujours de faire en sorte que la classe ne rende que les services qui sont réellement nécessaires, en respectant les principes KISS et YAGNI ;)