architecture d'un programme objet ?

Le
yveslc35
Bonjour et Bonne année à tous.
Pour commencer l'année, et comme l'hiver est déjà bien froid et risqu=
e
d'être long, je me suis mis à la programmation objet (je vois les
sourires de mes interlocuteurs des threads précédents). J'ai développ=
é
une petite appli de renommage de fichiers visible à cette adresse :

http://www.pythonfrance.com/codes/RENOMMEUR-FICHIERS-LOTS_48868.aspx

et j'ai mis toute mon appli dans une même classe. Ce n'est peut-être
pas très élégant.
Y-a-t-il une règle concernant l'architecture des programmes objet et
existe-t-il sur le web quelque chose qui en parle (si possible en
français) ? Je ne vois pas trop comment séparer les différentes
classes d'objet car tout est plus ou moins interdépendant. Passant de
la programmation procédurale à la prog. objet je suis un peu perdu
pour organiser mon appli.
merci de vos conseils.
YLC
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Bruno Desthuilliers
Le #18278011
a écrit :
Bonjour et Bonne année à tous.
Pour commencer l'année, et comme l'hiver est déjà bien froid et risque
d'être long, je me suis mis à la programmation objet (je vois les
sourires de mes interlocuteurs des threads précédents). J'ai développé
une petite appli de renommage de fichiers visible à cette adresse :

http://www.pythonfrance.com/codes/RENOMMEUR-FICHIERS-LOTS_48868.aspx

et j'ai mis toute mon appli dans une même classe. Ce n'est peut-être
pas très élégant.



Non, en effet.

Y-a-t-il une règle concernant l'architecture des programmes objet



Il y en a beaucoup, toutes plus ou moins discutables, et certaines pas
tellement spécifiques à l'OO.

et
existe-t-il sur le web quelque chose qui en parle (si possible en
français) ? Je ne vois pas trop comment séparer les différentes
classes d'objet car tout est plus ou moins interdépendant. Passant de
la programmation procédurale à la prog. objet je suis un peu perdu
pour organiser mon appli.



Python ne t'oblige en rien à utiliser la POO là où elle n'est pas
nécessaire. Globalement, ton appli est composée de deux chose:

1/ une interface utilisateur
2/ le "moteur" - c'est à dire, toutes les fonctionnalités qui ne
relèvent pas directement de l'interface utilisateur.

Pour le 1/, tu n'a guère d'autre choix qu'utiliser la POO puisque ton
GUI toolkit (comme à peu près tous les GUI toolkits Python) est basé dessus.

Pour le 2/, ça n'a rien à faire dans le 1/, ça doit fonctionner
indépendemment du 1/, et accessoirement ça ne nécessite pas forcément
une approche objet (dans ton cas en particulier, quelques fonctions
suffiraient).

Sinon et tout à fait hors-sujet, je me permet d'attirer ton attention sur
- le formatage de chaines:
s = "%s/%s" % ('toto', 'tata')
print s
- le module os.path
- le module shutils
hervest
Le #18278331
yveslc35 a écrit le 02/01/2009 à 17h34 :
Bonjour et Bonne année à tous.
Pour commencer l'année, et comme l'hiver est déjà bien froid et risqu=
e
d'être long, je me suis mis à la programmation objet (je vois les
sourires de mes interlocuteurs des threads précédents). J'ai développ=
é
une petite appli de renommage de fichiers visible à cette adresse :

http://www.pythonfrance.com/codes/RENOMMEUR-FICHIERS-LOTS_48868.aspx

et j'ai mis toute mon appli dans une même classe. Ce n'est peut-être
pas très élégant.
Y-a-t-il une règle concernant l'architecture des programmes objet et
existe-t-il sur le web quelque chose qui en parle (si possible en
français) ? Je ne vois pas trop comment séparer les différentes
classes d'objet car tout est plus ou moins interdépendant. Passant de
la programmation procédurale à la prog. objet je suis un peu perdu
pour organiser mon appli.
merci de vos conseils.
YLC


bonjour

voici le livre que je conseil à tous ceux qui veulent apprendre à programmer en python. C'est le même qui m'a aidé. Il te montrera comment penser comme un programmeur.

www.cifen.ulg.ac.be/inforef/swi/download/python_notes.pdf

tu trouveras à la page 129 (chapitre 22) les réponses à tes questions sur les classes.

Bonne chance avec python objet
Pierre Maurette
Le #18278851
, le 02/01/2009 a écrit :
Bonjour et Bonne année à tous.
Pour commencer l'année, et comme l'hiver est déjà bien froid et risque
d'être long, je me suis mis à la programmation objet (je vois les
sourires de mes interlocuteurs des threads précédents). J'ai développé
une petite appli de renommage de fichiers visible à cette adresse :

http://www.pythonfrance.com/codes/RENOMMEUR-FICHIERS-LOTS_48868.aspx

et j'ai mis toute mon appli dans une même classe. Ce n'est peut-être
pas très élégant.
Y-a-t-il une règle concernant l'architecture des programmes objet et
existe-t-il sur le web quelque chose qui en parle (si possible en
français) ? Je ne vois pas trop comment séparer les différentes
classes d'objet car tout est plus ou moins interdépendant. Passant de
la programmation procédurale à la prog. objet je suis un peu perdu
pour organiser mon appli.



J'ai à peine regardé, c'est joli, plein de couleurs ;-) . Juste
quelques suggestions, en commençant par les plus futiles:

-- Pensez à renommer votre .py en .pyw

-- Il est dommage de ne pas développer ce genre de programme en
multiplateforme. En fait, c'est pratiquement automatique si on code
"dans les règles de l'art", en utilisant le bon module là où il faut,
comme os.path déjà signalé.

-- J'organise en général ce genre d'utilitaire de la façon suivante:
- Un utilitaire en ligne de commande, renommeur.py. Voir le module
standard optparse. Personnellement, j'aurais une classe
sessionRenommage, qui contiendrait une liste de fichers, un répertoire
cible, une série de paramètres de comportement et de renommage (tout
ça, ça correspond en gros à votre interface), une méthode getFilenames
qui renverrait les noms de fichiers modifiés, une méthode doIt qui
utiliserait la précédente pour finaliser le renommage, etc. Il ne me
semble pas nécessaire de séparer en deux fichiers cette partie d'une
main qui parserait la ligne de commandes et utiliserait la classe
sessionRenommage en quelques lignes.
- Un wrapper Tkinter, renommeurtk.pyw.
Vous pouvez ainsi utiliser votre travail de quatre façons:
- En clicodrome Tkinter.
- En console, en ligne de commandes.
- A partir de n'importe quel programme ou script, python ou autre, par
la ligne de commandes.
- A partir d'un programme python, en important renommeur.py et en
utilisant la classe sessionRenommage.

--
Pierre Maurette
Méta-MCI \(MVP\)
Le #18280081
Bonsoir !

Je vais jouer au petit BD(*) du vendredi...
Plutôt que de "programme objet", il faudrait parler de "programme
orienté objet".

@+

MCI


(*) J'espère que Bruno ne m'en voudra pas trop d'utiliser ses initiales
comme synonyme de puriste...
yveslc35
Le #18282621
Bonjour,
Que de réponses !.... merci à tous.
Bruno attire mon attention sur : le module os.path et le module
shutils. Pourquoi ?
Aurais-je mal utilisé os.path ? Quant au module shutil, il fait la
même chose que le rename utilisé, non ?
Pierre dit que j'aurais du faire un prog multiplateformes. Mon
programme utilise-t-il donc des fonctions spécifiques à Windows ? J'ai
pourtant fait attention à ne pas utiliser des fonctions spécifiques.
YLC
Bruno Desthuilliers
Le #18283411
Méta-MCI (MVP) a écrit :
Bonsoir !

Je vais jouer au petit BD(*) du vendredi...



(snip)

(*) J'espère que Bruno ne m'en voudra pas trop d'utiliser ses initiales
comme synonyme de puriste...



Pas de problème, j'assume !-)
Bruno Desthuilliers
Le #18283741
a écrit :
Bonjour,
Que de réponses !.... merci à tous.
Bruno attire mon attention sur : le module os.path et le module
shutils. Pourquoi ?



Heu... Parce que ça peut être utile ?-)

Aurais-je mal utilisé os.path ?



C'est surtout que tu n'utilises pas os.path.join()

Quant au module shutil, il fait la
même chose que le rename utilisé, non ?



Concernant celui-ci, c'était juste à toutes fins utiles (puisque tu
était dans des opération de fichier) - la bibliothèque standard de
Python est vaste et il est courant, même après plusieurs années, de
réinventer la roue (carrée de préférence) alors que tout le nécessaire
existe déjà.

Pierre dit que j'aurais du faire un prog multiplateformes. Mon
programme utilise-t-il donc des fonctions spécifiques à Windows ?



from winsound import * # windows-only
dirinit=noudir="C:/" # windows-only
nomlog=os.getcwd()+"\renom.log" # separateur de chemin windows

HTH
yveslc35
Le #18283721
> > Pierre dit que j'aurais du faire un prog multiplateformes. Mon
> programme utilise-t-il donc des fonctions spécifiques à Windows ?

from winsound import * # windows-only
dirinit=noudir="C:/"   # windows-only
nomlog=os.getcwd()+"\renom.log" # separateur de chemin windows

HTH




Bon ok, pour winsound je n'y avais pas pensé. Mais qu'aurais-tu
utilisé à la place pour beeper en cas d'erreur ?
Sinon les variables initialisée avec des valeurs propres à Windows
peuvent facilement être initilisées par des valeurs propres à la
plateforme d'utilisation. Ce qui compte, je pense que ce sont les
fonctions utilisées qui doivent être portables.
YLC
Bruno Desthuilliers
Le #18286691
a écrit :
Pierre dit que j'aurais du faire un prog multiplateformes. Mon
programme utilise-t-il donc des fonctions spécifiques à Windows ?


from winsound import * # windows-only
dirinit=noudir="C:/" # windows-only
nomlog=os.getcwd()+"\renom.log" # separateur de chemin windows

HTH




Bon ok, pour winsound je n'y avais pas pensé. Mais qu'aurais-tu
utilisé à la place pour beeper en cas d'erreur ?



Rien - les programmes qui bippent m'exaspèrent !-)

Mais bon, si tu y tiens vraiment, à toi de voir quelles solutions sont
disponibles suivant les plateformes - en commençant par vérifier si ton
GUI toolkit ne propose pas déjà cette fonctionnalité.

Sinon les variables initialisée avec des valeurs propres à Windows
peuvent facilement être initilisées par des valeurs propres à la
plateforme d'utilisation.



Alors ne t'en prives pas !-)

Ce qui compte, je pense que ce sont les
fonctions utilisées qui doivent être portables.



Ce qui est un des intérêts de os.path.join()
Méta-MCI \(MVP\)
Le #18290961
Bonsoir !

développer ce genre de programme en multiplateforme



Comme je vois là un joli sujet de trolling, j'en profite allègrement
(faut pas m'en vouloir ; ce n'est pas une attaque perso ; c'est pour
mettre un peu d'animation).


Aaaahhhh, la "portabilité". Un mot à la mode.
Mais, ce mot recouvre quoi ? Il traite de la portabilité d'un programme
entre différentes plateformes.
OK.
Mais, de quelles plateformes parle-t'on ?

En fait, j'ai remarqué que c'est essentiellement une demande faite par
certains utilisateurs à propos de logiciels/programmes qui ne tournent
pas sur leur plateforme favorite.

Il n'est donc plus question d'universalité ou d'exo-intérêt, mais plutôt
"je voudrais que ça tourne sur MA plateforme".

Et, en pratique, il s'agit de Windows et de Linux. Avec,
éventuellement, une tolérance pour MacOS. Quand aux autres plateformes,
elles sont royalement ignorées.


Si on rapproche ça du fait que la portabilité (applicative) passe
souvent par un PPDC (Plus Petit Dénominateur Commun) des différentes
plateformes, je pense que faire une application portable est synonyme
d'une réduction fonctionnelle. Et, pour moi, cela va à l'encontre des
intérêts des utilisateurs pour lesquels on développe.


@-salutations
--
Michel Claveau
Publicité
Poster une réponse
Anonyme