01-08-2013, 07:30 PM
Par l'auto-initialisation, j'entendais que si la bibliothèque n'est pas remplie élément par élément ni traitée élément par élément (donc, vu comme un tout indivisible et non comme une tableau), alors l'élément contenu ne sera jamais utilisé à l'extérieur (puisque de l'extérieur, la bibliothèque est indivisible).
Tendre à toujours le faire, oui. Mais je n'ai pas dit qu'il faut mettre au placard les collections / tableaux d'objets. Disons que je pense qu'il faudrait distinguer la classe qui est vue normalement comme un tout indivisible (boîte noire) et les collections / tableaux d'objets qui ne devraient pas être vus comme des classes (puisqu'on traite leur contenu "un à un"). Il me semble que la bonne pratique consiste à avoir des classes de type "boite noire" (principe de l'OO me semble-t-il, non?). Et si une classe est une simple collection d'objets que l'on peut manipuler l'un après l'autre (à l'écriture, la lecture ou la modification ou autre), alors la collection n'est pas vue comme une boite noire, puisqu'on en demande et traite ses composants internes. C'est cela que je trouve être une mauvaise pratique (mais de toute façon, je n'ai ni le droit, ni la notoriété ni l'opportunité de forcer les gens à faire ainsi, libre à chacun de procéder comme il le souhaite, le but étant d'avoir un code que l'on sache relire et maintenir, pas de faire "ce que les autres ont en tête juste pour faire bien / faire plaisir").
Donc, oui, cela dépend du travail à faire car dans certains cas, on a besoin d'un Array (qui ne devrait, à mon sens, être rien de plus qu'un Array, et non un véritable objet), alors que dans d'autres cas, si on veut traiter ce "array" comme un vrai objet, on ne devrait pas s'attacher aux différents éléments qui le composent, car on n'est pas censé connaitre ce qui compose l'objet lui-même.
Tendre à toujours le faire, oui. Mais je n'ai pas dit qu'il faut mettre au placard les collections / tableaux d'objets. Disons que je pense qu'il faudrait distinguer la classe qui est vue normalement comme un tout indivisible (boîte noire) et les collections / tableaux d'objets qui ne devraient pas être vus comme des classes (puisqu'on traite leur contenu "un à un"). Il me semble que la bonne pratique consiste à avoir des classes de type "boite noire" (principe de l'OO me semble-t-il, non?). Et si une classe est une simple collection d'objets que l'on peut manipuler l'un après l'autre (à l'écriture, la lecture ou la modification ou autre), alors la collection n'est pas vue comme une boite noire, puisqu'on en demande et traite ses composants internes. C'est cela que je trouve être une mauvaise pratique (mais de toute façon, je n'ai ni le droit, ni la notoriété ni l'opportunité de forcer les gens à faire ainsi, libre à chacun de procéder comme il le souhaite, le but étant d'avoir un code que l'on sache relire et maintenir, pas de faire "ce que les autres ont en tête juste pour faire bien / faire plaisir").
Donc, oui, cela dépend du travail à faire car dans certains cas, on a besoin d'un Array (qui ne devrait, à mon sens, être rien de plus qu'un Array, et non un véritable objet), alors que dans d'autres cas, si on veut traiter ce "array" comme un vrai objet, on ne devrait pas s'attacher aux différents éléments qui le composent, car on n'est pas censé connaitre ce qui compose l'objet lui-même.