Parfois, des objets sont constitués de données pures. Ces objets ont des champs, des accesseurs et pratiquement aucune autre méthode.
Parfois, des objets sont constitués de comportement pur. Ils ont d'autres objets représentant leur état ou des données sont transmises en tant que paramètres de méthode. Habituellement, de tels objets représentent des algorithmes ou une sorte de politique.
Quel ratio d'état / comportement préférez-vous?
Ce qui est plus maintenu?
Qu'est-ce qui est plus sujet aux erreurs?
4 Réponses :
J'aime les objets qui (par ordre de priorité):
Lorsque ces mesures sont en place, il est beaucoup plus difficile de gâcher les choses.
Objets sans comportement peut aussi bien être des tables de hachage, des objets sans état peuvent aussi bien être une collection de fonctions.
C'est encore mieux lorsque l'objet est mis en œuvre de manière à ne jamais entrer dans un état incohérent, même si une exception s'est produite.
J'aime les objets qui font l'un ou l'autre - représentent quelque chose qui a un comportement (idéalement, n'expose que des méthodes de vide) ou représente un état pur (idéalement, est immuable et n'a pas de code à l'écart de la maintenance de son état et de sa validation possible) .
Le premier type d'objets passe l'autre type sur l'autre. Ceci est assez proche du modèle du acteur et cela résout que cela résout beaucoup de problèmes. (Si cela fait cela dans Java / C #, vous pouvez transmettre des interfaces au premier type comme «valeurs»)
Je trouve que ce sont des objets au milieu (qui sont à la fois étatiques et comportementaux) que vous rencontrez des problèmes ... Un État dans des objets comportementaux est correct, tant que l'objectif principal n'est pas de ne pas être interrogé .
Si vous concevez des objets qui sont tous des comportements et aucun état ou tout état et aucun comportement, je pense qu'il y a une faille quelque part dans votre conception. Il n'est vraiment pas courant de courir dans ces types d'objets dans le monde réel, et si ce ne sont pas des objets supplémentaires que vous décrivez, mais que des représentations d'objets du monde réel, alors je pense qu'il y a quelque chose de mal quelque part.
Je n'ai pas de ratio défini pour l'état / le comportement. Je pense que chaque objet prend sa propre forme et cela pourrait différer assez radicalement parmi les objets. Mais je pense que le temps passe et si vous travaillez sur l'objet, les verbes auront tendance à être plus que les noms / adjectifs, c'est-à-dire que le comportement dominera l'état.
C'est ce que j'ai observé dans mes programmes.
Ce que vous dites, c'est vrai pour OO de style impératif.
Impératif oo est standard en or. Ne signifie pas que cela doit être utilisé partout, mais que tout doit être comparé à celui-ci. Si vous déviez de OO, vous devez savoir ce que vous le faites. Le scission de l'état et du comportement ne sont pas inhérents, absolus, de valeur et doivent être appliqués à des cas spécifiques où il est avantageux, n'essayant pas de satisfaire de la métrique.
Le comportement doit être mis en œuvre comme une classe distincte Sinon, un cas de généralisation prématurée, et même pire, violation injustifiée des principes OO. Oui, c'est sujet d'erreur.
Je dirais que "seulement". Considérons une affaire lorsque vous avez une fonctionnalité difficile. Ainsi, au lieu d'avoir un objet de Dieu, vous le divisez en objets collaborateurs distincts. Certains d'entre eux sont principalement des États et d'autres sont principalement des comportements. La séparation réelle dépend de cas spécifique que vous avez. Mais notez que tous ces objets (et classes correspondants) sont extrêmement non génériques.
Je ne vois pas comment ce scénario nécessite la séparation du comportement et de l'état. L'objet complexe peut tout aussi bien se casser en nombre de bons objets OO les deux. Je dirais que cela approche du problème de la mauvaise fin. En bon OO, vous ne construisez pas l'objet d'implémenter des fonctionnalités - vous concevez le système d'objets connectés dans lesquels la fonctionnalité souhaitée émerge presque automatiquement.
Eh bien, je serais d'accord dans un sens où une telle séparation peut arriver dans d'autres cas en tant que sous-produit ou échange. Mais c'est toujours quelque chose à éviter.
La séparation de l'état et des comportements pourrait également être faite pour assurer la séparation des préoccupations. Comment ça contredit OOP?
"Je ne vois pas comment ce scénario nécessite la séparation du comportement et de l'état." Bien sûr, il n'est pas toujours besoin, mais il est facile d'imaginer comment il [I> pourrait besoin. C'est pourquoi j'ai donné cet exemple.
Parce que l'objet qui ne contient pas de comportement n'est pas un véritable objet? Il peut s'agir d'un objet en programmation de termes linguistiques, il peut avoir des fonctions membres, mais du point de vue de la conception ou de l'analyse - c'est toujours une structure de données. "Séparation des préoccupations" dans OOP concerne la conception des objets, ce n'est donc pas applicable ici. Si c'était le cas, on peut l'utiliser pour argumenter sur la décomposition des objets dans des variables et des fonctions distinctes, pour une séparation plus approfondie.
En fait, c'est un cas particulier d'un problème plus générique. L'objet est quelque chose d'autosuffisant, quelque chose avec une signification inhérente, une utilisation ou une analogie de domaine. Si vous faites deux objets qui ne font aucun sens lorsqu'il est utilisé ensemble - et que ce qui se passe avec un comportement spécifique de classe dans une classe distincte - vous introduisez des erreurs potentielles et des scénarios de mauvaise utilisation de quelqu'un qui essaie d'utiliser une classe sans l'autre.
"Si vous faites deux objets ... vous introduisez des erreurs potentielles et des scénarios de mauvaise utilisation». C'est pourquoi il existe une visibilité protégée et package-privée pour les classes en Java (d'autres langues ont des fonctionnalités similaires). C'est pourquoi il y a des packages * .Impl, ainsi que de la mise en œuvre d'interfaces contenant des éléments «privés». C'est pourquoi il y a *. Packages internaux à Osgi.
"L'objet est quelque chose d'autosuffisant ...". Cela signifierait aucun objet collaborant. Je ne veux pas dire aucune collaboration d'objets du tout. Je veux dire d'énormes objets de Dieu qui ne sont pas autorisés à se séparer, car nous devons préserver l'autosuffisance. Maintenabilité + Séparation des préoccupations contre l'autosuffisance de OOP + de l'objet => L'autosuffisance gagne! Louange Dieu Objects !? Est-ce que je me trompe pas? "Séparation des préoccupations ... ce n'est pas applicable ici". Cela signifie-t-il que la séparation des préoccupations contredit OOP?
"... briser des objets dans des variables et des fonctions distinctes, pour une séparation plus complète" - vous exagérez évidemment ici.
Pourquoi c'est pourquoi? La répétition n'est pas un argument. Qu'est-ce que tu vas te cacher exactement? La visibilité de la classe de données que la classe et le comportement que seuls ne doit être identique (afin qu'elles puissent être utilisées du tout), et dans ce champ de visibilité, vous obtenez le problème que j'ai décrit ci-dessus. La visibilité ne vous aidera pas lorsque vous avez organisé des cours dans le puzzle, qui ne fonctionne que lorsque chaque pièce unique est dans son lieu unique.
"Cela signifierait aucun objet collaborant." - Absolument pas. Cela signifie que la collaboration d'objets fait partie du comportement codé de l'objet, pas de connaissances ésotériques.
"Dieu Objects", "Est-ce que cela signifie que la séparation des préoccupations contredit OOP" - c'est votre homme de paille. Impensez-vous que d'avoir un comportement et un état dans le même objet conduit à des objets de Dieu? C'est tout simplement faux. Si cela fait de votre expérience, vous faites votre conception très mal. L'objet Dieu ne peut pas arriver dans OOP, c'est un module de programmation fondamentalement structuré posant comme objet.
"L'objet est quelque chose d'autosuffisant ...". Que diriez-vous des modèles de conception? Beaucoup d'entre eux sont des objets que vous ne voudriez pas considérer "des objets réels": façade, pont, médiateur. Ils aussi, en quelque sorte de définition de l'objet OOP, qui est objet = Data + Méthodes pour faire fonctionner ces données encapsulées. Chaque instance de ces motifs est spécifique utilisée avec un ensemble particulier d'objets ou d'interfaces spécifiques, et ne sont vraiment pas des données + des méthodes, mais plutôt des ajouts à des objets «réels».
"Esfilez-vous que d'avoir un comportement et un état dans le même objet conduit à Dieu Objets?". Je discute que s'il y a un objet de Dieu, il devrait être divisé en objets plus petits. Cela peut être atteint dans certains cas par «sous-traitant» une partie du comportement dans un objet distinct.
"Que diriez-vous des modèles de conception?" - Oui, de nombreux modèles de conception cassent OOP (beaucoup ne le font pas) et comme lesdites quelques fois déjà, OOP n'est pas quelque chose qui devrait être utilisé aveuglément partout. Si vous utilisez certains modèles de conception vous apporte des avantages importants, les principes de POO peuvent et doivent être pliés et violés. Ma réponse même qui a commencé ces commentaires décrit une telle situation.
"Je vis que s'il y a un objet de Dieu, il devrait être divisé en objets plus petits." Oui "peut être atteint dans certains cas par" sous-traitance "une partie du comportement dans un objet distinct." Peut - oui, devrait - absolument non. À moins que ce comportement ne soit logiquement générique et indépendant, analysez l'objet de Dieu et trouvez une autre façon de le casser dans des objets plus petits. En outre, vous ne devriez pas concevoir dieu objet en premier lieu, pas essayer de traiter avec eux après.
Plus sur des objets de Dieu, si vous cumulez simplement certaines méthodes en classe séparée, vous ne faites pas face au problème, vous le balayez sous le tapis. L'objet de Dieu est toujours là, seulement certaines de ses méthodes ont maintenant un autre préfixe.
Ok alors, laissez-moi résumer le montant. Il existe des principes d'OOP (Obj = données + méthodes, etc.). Dans la plupart des cas habituels, ils devraient être suivis. Mais, il y a des cas quand ils pourraient être violés. Par exemple. motifs de conception, ou casser des objets pour une meilleure maintenabilité. Serons-nous d'accord sur cela? Le tout premier mon commentaire était à propos de gros mot "seulement" audacieux de votre réponse, puis j'ai donné un exemple spécifique (non habituel ni du moins ne devrait pas être habituel) d'un exemple de briser un gros objet pour la maintenabilité. Vous plaigniez-vous, il ne faut jamais utiliser de seuls objets de comportement, à l'exception de l'affaire que vous avez mentionnée dans la réponse. Est-ce exact?
"CAN - Oui, devrait - absolument non. Sauf si ce comportement n'est logiquement générique et indépendant." C'était la chose que je voulais entendre. Cela concerne le "seulement". Ne jamais dire jamais.
«PRINCIPES POOP ... violées ... pour briser des objets pour une meilleure maintenabilité» - Non, nous ne sommes pas d'accord sur ce point. OOP elle-même décourage fortement les gros objets, il n'est donc jamais nécessaire de la violer à cette fin. Si vous vous retrouvez avec de gros objets après OO Design, corrigez votre conception au lieu de diviser des objets. "CAN - oui, devrait - absolument non." - Ma réponse originale a "ne devrait être mise en œuvre que ..." Ne pensez-vous pas que ces deux phrases signifient la même chose? Quoi qu'il en soit, ce site est affreux pour des discussions, alors je dirais qu'il est temps de pouvoir celui-ci.
Je ne discuterais pas si le "devrait" était aussi grand et audacieux que "seulement". De plus, de votre réponse, on pourrait conclure que la violation de l'OOP est quelque chose d'absolument inexcusable, ce qui se tourna pour ne pas le faire pendant la discussion. Et je n'ai pas dit que séparé du comportement de gros objet ne devrait pas être "logiquement générique et indépendant". Je viens de faire un contre-exemple. "Je dirais qu'il est temps de pouvoir celui-ci." - Je suis d'accord.
Un modèle intéressant - chaque commentaire (à la fois à la fois à votre mien) devient correct si vous ajoutez plus de détails. Je suppose que c'est la façon dont les guerres saintes apparaissent :)
On dirait que vous avez manqué non seulement "devrait", mais aussi "injustifié". La lecture est importante.
Désolé, je ne suis pas un orienté anglais natif. "Devrait-il être mis en œuvre ... seulement s'il est générique ..." signifie "devrait être mis en œuvre ... s'il s'agit de générique ... et dans d'autres cas"?
Je comprends que "ne devrait être implémentée que si x" est identique à "ne doit pas être mise en œuvre si non x". Ce ne serait pas vrai sans le "seulement". S'il vous plaît, corrigez-moi si je me trompe.
Considérez également un motif de constructeur. Pour être précis, cela ne nécessite pas non plus une mise en œuvre du comportement, mais elle est souvent. Souvent, son seul état est la référence à l'objet construit. Sa mise en œuvre n'est pas générique. C'est un autre contre-exemple. Je ne discute pas que l'on devrait faire des objets de comportement seulement à chaque fois qu'il l'aime, mais il est complètement correct de le faire, si le comportement est logiquement indépendant.