Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jérémy Jeanson
Bonjour Christian,
En général cela est utilisé pour un framework métier afin de le ren dre plus lisible. Mais cela n'est pas conseillé. Il est préférable d'utiliser les namespace pou cela.
--- Jérémy Jeanson MCP http://www.jjeanson.fr
Bonjour Christian,
En général cela est utilisé pour un framework métier afin de le ren dre
plus lisible. Mais cela n'est pas conseillé.
Il est préférable d'utiliser les namespace pou cela.
En général cela est utilisé pour un framework métier afin de le ren dre plus lisible. Mais cela n'est pas conseillé. Il est préférable d'utiliser les namespace pou cela.
--- Jérémy Jeanson MCP http://www.jjeanson.fr
Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax
OK.
Merci pour le conseil
Christian
"Jérémy Jeanson" a écrit dans le message de news: Bonjour Christian,
En général cela est utilisé pour un framework métier afin de le rendre plus lisible. Mais cela n'est pas conseillé. Il est préférable d'utiliser les namespace pou cela.
--- Jérémy Jeanson MCP http://www.jjeanson.fr
OK.
Merci pour le conseil
Christian
"Jérémy Jeanson" <jeremy.jeanson@free.fr> a écrit dans le message de
news:bc2d67fe-50a5-44a4-a566-011ee04a745c@z26g2000yqm.googlegroups.com...
Bonjour Christian,
En général cela est utilisé pour un framework métier afin de le rendre
plus lisible. Mais cela n'est pas conseillé.
Il est préférable d'utiliser les namespace pou cela.
"Jérémy Jeanson" a écrit dans le message de news: Bonjour Christian,
En général cela est utilisé pour un framework métier afin de le rendre plus lisible. Mais cela n'est pas conseillé. Il est préférable d'utiliser les namespace pou cela.
--- Jérémy Jeanson MCP http://www.jjeanson.fr
Christophe Lephay
"Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax" a écrit dans le message de groupe de discussion :
OK.
Merci pour le conseil
Christian
"Jérémy Jeanson" a écrit dans le message de news: Bonjour Christian,
En général cela est utilisé pour un framework métier afin de le rendre plus lisible. Mais cela n'est pas conseillé. Il est préférable d'utiliser les namespace pou cela.
Il y a quand même une différence qui va au delà de la pollution de l'espace de noms.
L'encapsulation étend un principe essentiel qui vise à réduire le plus possible les effets de bord.
On réduit le couplage (et donc les risques d'effets de bord) en réduisant la portée et l'accessibilité d'un identificateur (qu'il s'agisse d'un objet ou d'un type).
Lorsqu'on a le choix, c'est mieux d'avoir un membre privé plutôt que publique, et c'est encore mieux d'avoir un objet local à une méthode plutôt que d'en faire une donnée membre.
C'est pareil avec une classe imbriquée - à la condition qu'on la déclare privée (ou éventuellement protégée).
En revanche, s'il s'agit de déclarer publique une classe imbriquée, cela ne présente pas le moindre intérêt et l'alternative proposée par Jérémy en rend la lecture plus facile.
"Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax" <nospam@weabow.com> a
écrit dans le message de groupe de discussion :
Os3ZIZNoKHA.1548@TK2MSFTNGP02.phx.gbl...
OK.
Merci pour le conseil
Christian
"Jérémy Jeanson" <jeremy.jeanson@free.fr> a écrit dans le message de
news:bc2d67fe-50a5-44a4-a566-011ee04a745c@z26g2000yqm.googlegroups.com...
Bonjour Christian,
En général cela est utilisé pour un framework métier afin de le rendre
plus lisible. Mais cela n'est pas conseillé.
Il est préférable d'utiliser les namespace pou cela.
Il y a quand même une différence qui va au delà de la pollution de l'espace
de noms.
L'encapsulation étend un principe essentiel qui vise à réduire le plus
possible les effets de bord.
On réduit le couplage (et donc les risques d'effets de bord) en réduisant la
portée et l'accessibilité d'un identificateur (qu'il s'agisse d'un objet ou
d'un type).
Lorsqu'on a le choix, c'est mieux d'avoir un membre privé plutôt que
publique, et c'est encore mieux d'avoir un objet local à une méthode plutôt
que d'en faire une donnée membre.
C'est pareil avec une classe imbriquée - à la condition qu'on la déclare
privée (ou éventuellement protégée).
En revanche, s'il s'agit de déclarer publique une classe imbriquée, cela ne
présente pas le moindre intérêt et l'alternative proposée par Jérémy en rend
la lecture plus facile.
"Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax" a écrit dans le message de groupe de discussion :
OK.
Merci pour le conseil
Christian
"Jérémy Jeanson" a écrit dans le message de news: Bonjour Christian,
En général cela est utilisé pour un framework métier afin de le rendre plus lisible. Mais cela n'est pas conseillé. Il est préférable d'utiliser les namespace pou cela.
Il y a quand même une différence qui va au delà de la pollution de l'espace de noms.
L'encapsulation étend un principe essentiel qui vise à réduire le plus possible les effets de bord.
On réduit le couplage (et donc les risques d'effets de bord) en réduisant la portée et l'accessibilité d'un identificateur (qu'il s'agisse d'un objet ou d'un type).
Lorsqu'on a le choix, c'est mieux d'avoir un membre privé plutôt que publique, et c'est encore mieux d'avoir un objet local à une méthode plutôt que d'en faire une donnée membre.
C'est pareil avec une classe imbriquée - à la condition qu'on la déclare privée (ou éventuellement protégée).
En revanche, s'il s'agit de déclarer publique une classe imbriquée, cela ne présente pas le moindre intérêt et l'alternative proposée par Jérémy en rend la lecture plus facile.
Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax
Merci de tes éclaircissements. Ils sont aussi précieux.
"Christophe Lephay" a écrit dans le message de news:4b654e3d$0$17492$
"Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax" a écrit dans le message de groupe de discussion :
OK.
Merci pour le conseil
Christian
"Jérémy Jeanson" a écrit dans le message de news: Bonjour Christian,
En général cela est utilisé pour un framework métier afin de le rendre plus lisible. Mais cela n'est pas conseillé. Il est préférable d'utiliser les namespace pou cela.
Il y a quand même une différence qui va au delà de la pollution de l'espace de noms.
L'encapsulation étend un principe essentiel qui vise à réduire le plus possible les effets de bord.
On réduit le couplage (et donc les risques d'effets de bord) en réduisant la portée et l'accessibilité d'un identificateur (qu'il s'agisse d'un objet ou d'un type).
Lorsqu'on a le choix, c'est mieux d'avoir un membre privé plutôt que publique, et c'est encore mieux d'avoir un objet local à une méthode plutôt que d'en faire une donnée membre.
C'est pareil avec une classe imbriquée - à la condition qu'on la déclare privée (ou éventuellement protégée).
En revanche, s'il s'agit de déclarer publique une classe imbriquée, cela ne présente pas le moindre intérêt et l'alternative proposée par Jérémy en rend la lecture plus facile.
Merci de tes éclaircissements. Ils sont aussi précieux.
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
de news:4b654e3d$0$17492$ba4acef3@news.orange.fr...
"Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax" <nospam@weabow.com>
a écrit dans le message de groupe de discussion :
Os3ZIZNoKHA.1548@TK2MSFTNGP02.phx.gbl...
OK.
Merci pour le conseil
Christian
"Jérémy Jeanson" <jeremy.jeanson@free.fr> a écrit dans le message de
news:bc2d67fe-50a5-44a4-a566-011ee04a745c@z26g2000yqm.googlegroups.com...
Bonjour Christian,
En général cela est utilisé pour un framework métier afin de le rendre
plus lisible. Mais cela n'est pas conseillé.
Il est préférable d'utiliser les namespace pou cela.
Il y a quand même une différence qui va au delà de la pollution de
l'espace de noms.
L'encapsulation étend un principe essentiel qui vise à réduire le plus
possible les effets de bord.
On réduit le couplage (et donc les risques d'effets de bord) en réduisant
la portée et l'accessibilité d'un identificateur (qu'il s'agisse d'un
objet ou d'un type).
Lorsqu'on a le choix, c'est mieux d'avoir un membre privé plutôt que
publique, et c'est encore mieux d'avoir un objet local à une méthode
plutôt que d'en faire une donnée membre.
C'est pareil avec une classe imbriquée - à la condition qu'on la déclare
privée (ou éventuellement protégée).
En revanche, s'il s'agit de déclarer publique une classe imbriquée, cela
ne présente pas le moindre intérêt et l'alternative proposée par Jérémy en
rend la lecture plus facile.
Merci de tes éclaircissements. Ils sont aussi précieux.
"Christophe Lephay" a écrit dans le message de news:4b654e3d$0$17492$
"Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax" a écrit dans le message de groupe de discussion :
OK.
Merci pour le conseil
Christian
"Jérémy Jeanson" a écrit dans le message de news: Bonjour Christian,
En général cela est utilisé pour un framework métier afin de le rendre plus lisible. Mais cela n'est pas conseillé. Il est préférable d'utiliser les namespace pou cela.
Il y a quand même une différence qui va au delà de la pollution de l'espace de noms.
L'encapsulation étend un principe essentiel qui vise à réduire le plus possible les effets de bord.
On réduit le couplage (et donc les risques d'effets de bord) en réduisant la portée et l'accessibilité d'un identificateur (qu'il s'agisse d'un objet ou d'un type).
Lorsqu'on a le choix, c'est mieux d'avoir un membre privé plutôt que publique, et c'est encore mieux d'avoir un objet local à une méthode plutôt que d'en faire une donnée membre.
C'est pareil avec une classe imbriquée - à la condition qu'on la déclare privée (ou éventuellement protégée).
En revanche, s'il s'agit de déclarer publique une classe imbriquée, cela ne présente pas le moindre intérêt et l'alternative proposée par Jérémy en rend la lecture plus facile.
Jean-Philippe Gouigoux
Bonjour,
Il est intéressant d'utiliser une classe interne pour simplifier le code d'une classe complexe. En règle générale, il vaut mieux que cette classe ne soit pas exposée à l'extérieur, et c'est d'ailleurs une règle dans un outil de vérification de qualité de code comme NDepend.
Maintenant, il y a toujours une exception valable à tout, et une définition d'énumération est un bon exemple. Il vaut mieux avoir un enum ModeCloture dans une classe Contrat que deux classes séparées Contrat et ModeClotureContrat.
JP
Bonjour,
Il est intéressant d'utiliser une classe interne pour simplifier le code
d'une classe complexe. En règle générale, il vaut mieux que cette classe
ne soit pas exposée à l'extérieur, et c'est d'ailleurs une règle dans un
outil de vérification de qualité de code comme NDepend.
Maintenant, il y a toujours une exception valable à tout, et une
définition d'énumération est un bon exemple. Il vaut mieux avoir un enum
ModeCloture dans une classe Contrat que deux classes séparées Contrat et
ModeClotureContrat.
Il est intéressant d'utiliser une classe interne pour simplifier le code d'une classe complexe. En règle générale, il vaut mieux que cette classe ne soit pas exposée à l'extérieur, et c'est d'ailleurs une règle dans un outil de vérification de qualité de code comme NDepend.
Maintenant, il y a toujours une exception valable à tout, et une définition d'énumération est un bon exemple. Il vaut mieux avoir un enum ModeCloture dans une classe Contrat que deux classes séparées Contrat et ModeClotureContrat.
