Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
Merci
Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
Merci
Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
Merci
Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
Je suppose que par classe "interface", tu veux dire la partie GUI ?On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
<HS>
Tel que tu le décris, ça prête trop à confusion pour donner une réponse
simple.
Dans l'absolu, il est évidemment préférable de séparer la logique
applicative de la logique de présentation. L'intérêt est bien évidemment
que ça rend la logique applicative indépendante de la présentation, donc:
* aisément testable
* (au moins théoriquement) réutilisable.
Après, la façon de s'y prendre dépend du type d'appli.
Un pattern courant sous Unix est d'avoir une appli en ligne de commande
avec une quantité invraisemblables d'options, et d'écrire une appli GUI
qui se contente de construire la ligne de commande d'après les choix de
l'utilisateur (et éventuellement de présenter les résultats). Dans ce
cas de figure, la séparation entre logique applicative et GUI est on ne
peut plus claire, puisqu'il s'agit de deux applis différentes !-)
Une autre solution est de concevoir la logique applicative sous forme de
bibliothèque, puis de développer une (ou des) interface(s) utilisateur
utilisant cette bibliothèque. Il est évident que ça ne peut fonctionner
que si la partie présentation ne gère que et exclusivement que la
présentation, et se contente pour le reste d'appeler la bibliothèque.
En tout état de cause, je te recommande de faire une petite recherche
sur "MVC".
Quant à celui qui te conseille de faire "hériter la classe programme de
la class interface", soit on a des définitions très différentes de "la
classe programme" (que je comprend comme étant "la logique
applicative"), soit je ne veux en aucun cas de lui sur un de mes projets.
</HS>
A part ça, tu a une question sur Python ?-)
Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
Je suppose que par classe "interface", tu veux dire la partie GUI ?
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
<HS>
Tel que tu le décris, ça prête trop à confusion pour donner une réponse
simple.
Dans l'absolu, il est évidemment préférable de séparer la logique
applicative de la logique de présentation. L'intérêt est bien évidemment
que ça rend la logique applicative indépendante de la présentation, donc:
* aisément testable
* (au moins théoriquement) réutilisable.
Après, la façon de s'y prendre dépend du type d'appli.
Un pattern courant sous Unix est d'avoir une appli en ligne de commande
avec une quantité invraisemblables d'options, et d'écrire une appli GUI
qui se contente de construire la ligne de commande d'après les choix de
l'utilisateur (et éventuellement de présenter les résultats). Dans ce
cas de figure, la séparation entre logique applicative et GUI est on ne
peut plus claire, puisqu'il s'agit de deux applis différentes !-)
Une autre solution est de concevoir la logique applicative sous forme de
bibliothèque, puis de développer une (ou des) interface(s) utilisateur
utilisant cette bibliothèque. Il est évident que ça ne peut fonctionner
que si la partie présentation ne gère que et exclusivement que la
présentation, et se contente pour le reste d'appeler la bibliothèque.
En tout état de cause, je te recommande de faire une petite recherche
sur "MVC".
Quant à celui qui te conseille de faire "hériter la classe programme de
la class interface", soit on a des définitions très différentes de "la
classe programme" (que je comprend comme étant "la logique
applicative"), soit je ne veux en aucun cas de lui sur un de mes projets.
</HS>
A part ça, tu a une question sur Python ?-)
Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
Je suppose que par classe "interface", tu veux dire la partie GUI ?On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
<HS>
Tel que tu le décris, ça prête trop à confusion pour donner une réponse
simple.
Dans l'absolu, il est évidemment préférable de séparer la logique
applicative de la logique de présentation. L'intérêt est bien évidemment
que ça rend la logique applicative indépendante de la présentation, donc:
* aisément testable
* (au moins théoriquement) réutilisable.
Après, la façon de s'y prendre dépend du type d'appli.
Un pattern courant sous Unix est d'avoir une appli en ligne de commande
avec une quantité invraisemblables d'options, et d'écrire une appli GUI
qui se contente de construire la ligne de commande d'après les choix de
l'utilisateur (et éventuellement de présenter les résultats). Dans ce
cas de figure, la séparation entre logique applicative et GUI est on ne
peut plus claire, puisqu'il s'agit de deux applis différentes !-)
Une autre solution est de concevoir la logique applicative sous forme de
bibliothèque, puis de développer une (ou des) interface(s) utilisateur
utilisant cette bibliothèque. Il est évident que ça ne peut fonctionner
que si la partie présentation ne gère que et exclusivement que la
présentation, et se contente pour le reste d'appeler la bibliothèque.
En tout état de cause, je te recommande de faire une petite recherche
sur "MVC".
Quant à celui qui te conseille de faire "hériter la classe programme de
la class interface", soit on a des définitions très différentes de "la
classe programme" (que je comprend comme étant "la logique
applicative"), soit je ne veux en aucun cas de lui sur un de mes projets.
</HS>
A part ça, tu a une question sur Python ?-)
Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
Je suppose que par classe "interface", tu veux dire la partie GUI ?On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
<HS>
Tel que tu le décris, ça prête trop à confusion pour donner une réponse
simple.
Dans l'absolu, il est évidemment préférable de séparer la logique
applicative de la logique de présentation. L'intérêt est bien évidemment
que ça rend la logique applicative indépendante de la présentation, donc:
* aisément testable
* (au moins théoriquement) réutilisable.
Après, la façon de s'y prendre dépend du type d'appli.
Un pattern courant sous Unix est d'avoir une appli en ligne de commande
avec une quantité invraisemblables d'options, et d'écrire une appli GUI
qui se contente de construire la ligne de commande d'après les choix de
l'utilisateur (et éventuellement de présenter les résultats). Dans ce
cas de figure, la séparation entre logique applicative et GUI est on ne
peut plus claire, puisqu'il s'agit de deux applis différentes !-)
Une autre solution est de concevoir la logique applicative sous forme de
bibliothèque, puis de développer une (ou des) interface(s) utilisateur
utilisant cette bibliothèque. Il est évident que ça ne peut fonctionner
que si la partie présentation ne gère que et exclusivement que la
présentation, et se contente pour le reste d'appeler la bibliothèque.
En tout état de cause, je te recommande de faire une petite recherche
sur "MVC".
Quant à celui qui te conseille de faire "hériter la classe programme de
la class interface", soit on a des définitions très différentes de "la
classe programme" (que je comprend comme étant "la logique
applicative"), soit je ne veux en aucun cas de lui sur un de mes projets.
</HS>
A part ça, tu a une question sur Python ?-)
Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
Je suppose que par classe "interface", tu veux dire la partie GUI ?
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
<HS>
Tel que tu le décris, ça prête trop à confusion pour donner une réponse
simple.
Dans l'absolu, il est évidemment préférable de séparer la logique
applicative de la logique de présentation. L'intérêt est bien évidemment
que ça rend la logique applicative indépendante de la présentation, donc:
* aisément testable
* (au moins théoriquement) réutilisable.
Après, la façon de s'y prendre dépend du type d'appli.
Un pattern courant sous Unix est d'avoir une appli en ligne de commande
avec une quantité invraisemblables d'options, et d'écrire une appli GUI
qui se contente de construire la ligne de commande d'après les choix de
l'utilisateur (et éventuellement de présenter les résultats). Dans ce
cas de figure, la séparation entre logique applicative et GUI est on ne
peut plus claire, puisqu'il s'agit de deux applis différentes !-)
Une autre solution est de concevoir la logique applicative sous forme de
bibliothèque, puis de développer une (ou des) interface(s) utilisateur
utilisant cette bibliothèque. Il est évident que ça ne peut fonctionner
que si la partie présentation ne gère que et exclusivement que la
présentation, et se contente pour le reste d'appeler la bibliothèque.
En tout état de cause, je te recommande de faire une petite recherche
sur "MVC".
Quant à celui qui te conseille de faire "hériter la classe programme de
la class interface", soit on a des définitions très différentes de "la
classe programme" (que je comprend comme étant "la logique
applicative"), soit je ne veux en aucun cas de lui sur un de mes projets.
</HS>
A part ça, tu a une question sur Python ?-)
Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
Je suppose que par classe "interface", tu veux dire la partie GUI ?On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
<HS>
Tel que tu le décris, ça prête trop à confusion pour donner une réponse
simple.
Dans l'absolu, il est évidemment préférable de séparer la logique
applicative de la logique de présentation. L'intérêt est bien évidemment
que ça rend la logique applicative indépendante de la présentation, donc:
* aisément testable
* (au moins théoriquement) réutilisable.
Après, la façon de s'y prendre dépend du type d'appli.
Un pattern courant sous Unix est d'avoir une appli en ligne de commande
avec une quantité invraisemblables d'options, et d'écrire une appli GUI
qui se contente de construire la ligne de commande d'après les choix de
l'utilisateur (et éventuellement de présenter les résultats). Dans ce
cas de figure, la séparation entre logique applicative et GUI est on ne
peut plus claire, puisqu'il s'agit de deux applis différentes !-)
Une autre solution est de concevoir la logique applicative sous forme de
bibliothèque, puis de développer une (ou des) interface(s) utilisateur
utilisant cette bibliothèque. Il est évident que ça ne peut fonctionner
que si la partie présentation ne gère que et exclusivement que la
présentation, et se contente pour le reste d'appeler la bibliothèque.
En tout état de cause, je te recommande de faire une petite recherche
sur "MVC".
Quant à celui qui te conseille de faire "hériter la classe programme de
la class interface", soit on a des définitions très différentes de "la
classe programme" (que je comprend comme étant "la logique
applicative"), soit je ne veux en aucun cas de lui sur un de mes projets.
</HS>
A part ça, tu a une question sur Python ?-)
Le concept de bibliothèque et d'interface me plaît plus que génerer des
lignes de commandes.
Le concept de bibliothèque et d'interface me plaît plus que génerer des
lignes de commandes.
Le concept de bibliothèque et d'interface me plaît plus que génerer des
lignes de commandes.
J'aurais juste une demande, si vous aviez un exemple de programme où
l'application est bien distincte de son interface graphique.
J'aurais juste une demande, si vous aviez un exemple de programme où
l'application est bien distincte de son interface graphique.
J'aurais juste une demande, si vous aviez un exemple de programme où
l'application est bien distincte de son interface graphique.
(hs : si tu pouvais éviter de top-poster, ça serait pas mal...)J'aurais juste une demande, si vous aviez un exemple de programme où
l'application est bien distincte de son interface graphique.
X-CD-Roast (et la plupart des cd-burners sous Nunux)
Sinon, google "GUI frontend", tu devrais trouver du monde...
Ok, Merci !
(hs : si tu pouvais éviter de top-poster, ça serait pas mal...)
J'aurais juste une demande, si vous aviez un exemple de programme où
l'application est bien distincte de son interface graphique.
X-CD-Roast (et la plupart des cd-burners sous Nunux)
Sinon, google "GUI frontend", tu devrais trouver du monde...
Ok, Merci !
(hs : si tu pouvais éviter de top-poster, ça serait pas mal...)J'aurais juste une demande, si vous aviez un exemple de programme où
l'application est bien distincte de son interface graphique.
X-CD-Roast (et la plupart des cd-burners sous Nunux)
Sinon, google "GUI frontend", tu devrais trouver du monde...
Ok, Merci !
BH wrote:Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
Merci
""" ...séparer du programme .... Hériter la class "interface" .... """:
c'est un peu antinomique non ? dès que tu hérites, tu dois importer ...
et de ce fait lier ta "logique" à l'IHM ... et ça c'est pas bon du tout.
Personellement je te conseille le principe inverse à celui qu'on t'a
préconisé: passe tes objets "applicatifs" à ton IHM ... mais jamais, au
grand jamais, ne lie les deux.
Si dans certain cas de figure (ça m'énerve mais ça m'arrive
régulièrement ... Mais chu mauvais) tu as besoin (par exemple: depuis un
timer) de faire péter une boîte de dialogue depuis ta "logique" ... alors
crée un couche IHM_To_APP à base de callback pour gérer ça.
A tord ou à raison c'est ce que je fais depuis quelques temps.
hg
Merci de tes information. Concernant Python, mon problème vient du fait
que les méthodes déclenchées par les bind sont dans la classe IHM pour
l'immense majorité des exemples que j'ai trouvé sur Internet.
Je n'arrive pas à comprendre comment séparer suffisament bien la logique
applicative de la logique interface pour concevoir mon appli dans les
règles de l'art.
BH wrote:
Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
Merci
""" ...séparer du programme .... Hériter la class "interface" .... """:
c'est un peu antinomique non ? dès que tu hérites, tu dois importer ...
et de ce fait lier ta "logique" à l'IHM ... et ça c'est pas bon du tout.
Personellement je te conseille le principe inverse à celui qu'on t'a
préconisé: passe tes objets "applicatifs" à ton IHM ... mais jamais, au
grand jamais, ne lie les deux.
Si dans certain cas de figure (ça m'énerve mais ça m'arrive
régulièrement ... Mais chu mauvais) tu as besoin (par exemple: depuis un
timer) de faire péter une boîte de dialogue depuis ta "logique" ... alors
crée un couche IHM_To_APP à base de callback pour gérer ça.
A tord ou à raison c'est ce que je fais depuis quelques temps.
hg
Merci de tes information. Concernant Python, mon problème vient du fait
que les méthodes déclenchées par les bind sont dans la classe IHM pour
l'immense majorité des exemples que j'ai trouvé sur Internet.
Je n'arrive pas à comprendre comment séparer suffisament bien la logique
applicative de la logique interface pour concevoir mon appli dans les
règles de l'art.
BH wrote:Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
Merci
""" ...séparer du programme .... Hériter la class "interface" .... """:
c'est un peu antinomique non ? dès que tu hérites, tu dois importer ...
et de ce fait lier ta "logique" à l'IHM ... et ça c'est pas bon du tout.
Personellement je te conseille le principe inverse à celui qu'on t'a
préconisé: passe tes objets "applicatifs" à ton IHM ... mais jamais, au
grand jamais, ne lie les deux.
Si dans certain cas de figure (ça m'énerve mais ça m'arrive
régulièrement ... Mais chu mauvais) tu as besoin (par exemple: depuis un
timer) de faire péter une boîte de dialogue depuis ta "logique" ... alors
crée un couche IHM_To_APP à base de callback pour gérer ça.
A tord ou à raison c'est ce que je fais depuis quelques temps.
hg
Merci de tes information. Concernant Python, mon problème vient du fait
que les méthodes déclenchées par les bind sont dans la classe IHM pour
l'immense majorité des exemples que j'ai trouvé sur Internet.
Je n'arrive pas à comprendre comment séparer suffisament bien la logique
applicative de la logique interface pour concevoir mon appli dans les
règles de l'art.
BH wrote:Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
Merci
""" ...séparer du programme .... Hériter la class "interface" .... """:
c'est un peu antinomique non ? dès que tu hérites, tu dois importer ... et
de ce fait lier ta "logique" à l'IHM ... et ça c'est pas bon du tout.
Personellement je te conseille le principe inverse à celui qu'on t'a
préconisé: passe tes objets "applicatifs" à ton IHM ... mais jamais, au
grand jamais, ne lie les deux.
Si dans certain cas de figure (ça m'énerve mais ça m'arrive
régulièrement ... Mais chu mauvais) tu as besoin (par exemple: depuis un
timer) de faire péter une boîte de dialogue depuis ta "logique" ... alors
crée un couche IHM_To_APP à base de callback pour gérer ça.
A tord ou à raison c'est ce que je fais depuis quelques temps.
hg
BH wrote:
Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
Merci
""" ...séparer du programme .... Hériter la class "interface" .... """:
c'est un peu antinomique non ? dès que tu hérites, tu dois importer ... et
de ce fait lier ta "logique" à l'IHM ... et ça c'est pas bon du tout.
Personellement je te conseille le principe inverse à celui qu'on t'a
préconisé: passe tes objets "applicatifs" à ton IHM ... mais jamais, au
grand jamais, ne lie les deux.
Si dans certain cas de figure (ça m'énerve mais ça m'arrive
régulièrement ... Mais chu mauvais) tu as besoin (par exemple: depuis un
timer) de faire péter une boîte de dialogue depuis ta "logique" ... alors
crée un couche IHM_To_APP à base de callback pour gérer ça.
A tord ou à raison c'est ce que je fais depuis quelques temps.
hg
BH wrote:Bonjour,
Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.
Quels sont les intérêts et inconvénients des deux approches ?
Merci
""" ...séparer du programme .... Hériter la class "interface" .... """:
c'est un peu antinomique non ? dès que tu hérites, tu dois importer ... et
de ce fait lier ta "logique" à l'IHM ... et ça c'est pas bon du tout.
Personellement je te conseille le principe inverse à celui qu'on t'a
préconisé: passe tes objets "applicatifs" à ton IHM ... mais jamais, au
grand jamais, ne lie les deux.
Si dans certain cas de figure (ça m'énerve mais ça m'arrive
régulièrement ... Mais chu mauvais) tu as besoin (par exemple: depuis un
timer) de faire péter une boîte de dialogue depuis ta "logique" ... alors
crée un couche IHM_To_APP à base de callback pour gérer ça.
A tord ou à raison c'est ce que je fais depuis quelques temps.
hg
Merci de tes information. Concernant Python, mon problème vient du fait
que les méthodes déclenchées par les bind sont dans la classe IHM pour
l'immense majorité des exemples que j'ai trouvé sur Internet.
Je n'arrive pas à comprendre comment séparer suffisament bien la logique
applicative de la logique interface pour concevoir mon appli dans les
règles de l'art.
Merci de tes information. Concernant Python, mon problème vient du fait
que les méthodes déclenchées par les bind sont dans la classe IHM pour
l'immense majorité des exemples que j'ai trouvé sur Internet.
Je n'arrive pas à comprendre comment séparer suffisament bien la logique
applicative de la logique interface pour concevoir mon appli dans les
règles de l'art.
Merci de tes information. Concernant Python, mon problème vient du fait
que les méthodes déclenchées par les bind sont dans la classe IHM pour
l'immense majorité des exemples que j'ai trouvé sur Internet.
Je n'arrive pas à comprendre comment séparer suffisament bien la logique
applicative de la logique interface pour concevoir mon appli dans les
règles de l'art.