SI tu programmes en style objet un peu extrême, le corps de ton appli consiste principalement en une suite de déclaration d'objets interdépendants, qui gèrent après leurs interactions entre eux, donc par conséquent, une bonne partie du code est localisé au niveau des constructeurs... et des destructeurs, encore faut-il qu'il y en ait.
Le parallèle entre les constructeurs et les destructeurs est complétement mal venu. Le constructeur d'un objet est appelé à l'initiative de l'application, alors qu'en général on ne peut pas prévoir quand l'appel à un destructeur sera fait. Avoir une logique applicative dans un destructeur c'est un très mauvais design objet, il faut mieux avoir une méthode de finalisation appelée explicitement.
Tu parles en particulier de Python, alors qu'en Python l'utilisation des destructeurs est très découragée. D'abord parce que cela casse une partie du GC (en gros il a beaucoup de mal a détecter les cycles lorsque les objets définissent une méthode __del__). Ensuite parce qu'il y a (très) souvent moyen de faire mieux et plus propre. Un destructeur doit être utilisé dans des cas très particuliers.
[^] # Re: Destructeurs
Posté par Thomas Hervé . En réponse à la dépêche Sortie de Ruby 1.8.5. Évalué à 6.
Le parallèle entre les constructeurs et les destructeurs est complétement mal venu. Le constructeur d'un objet est appelé à l'initiative de l'application, alors qu'en général on ne peut pas prévoir quand l'appel à un destructeur sera fait. Avoir une logique applicative dans un destructeur c'est un très mauvais design objet, il faut mieux avoir une méthode de finalisation appelée explicitement.
Tu parles en particulier de Python, alors qu'en Python l'utilisation des destructeurs est très découragée. D'abord parce que cela casse une partie du GC (en gros il a beaucoup de mal a détecter les cycles lorsque les objets définissent une méthode __del__). Ensuite parce qu'il y a (très) souvent moyen de faire mieux et plus propre. Un destructeur doit être utilisé dans des cas très particuliers.