Discussion :

[Sve@r]

Bonjour

Je viens ici ouvrir une nouvelle discussion à propos d'un problème éventuel sur l'utilisation systématique du dictionnaire.

En effet, je me demande si le dictionnaire peut être un outil universel de gestion.

Je m'explique: imaginons que je veuille gérer une personne (nom, prénom, age). Instinctivement, je penserai au départ à un objet de ce type

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
class cPersonne(object):
    def __init__(self):
        self.__nom=None
        self.__prenom=None
        self.__age=None
 
    def setValue(*args, **kwargs):
        for (k, v) in kwargs.iteritems():
            if k == "nom":
                self.__nom=v
                continue
            if k == "prenom" :
                self.__prenom=v
                continue
            if k == "age":
                self.__age=v
                continue
            raise keyError
 
    def getValue(k):
        if k == "nom": return self.__nom
        if k == "prenom" : return self.__prenom
        if k == "age": return self.__age
        raise keyError

Puis, je peux partir sur ma gestion

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
personne=cPersonne()
personne.setValue(nom="toto", prenom="alfred", age=18)
print personne.getValue("nom")
print personne.getValue("prenom")
print personne.getValue("age")

etc...

Mais là, je me dis que je peux tout aussi bien partir directement sur un dictionnaire ce qui me simplifie en plus pas mal de code...

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class cPersonne(object):
    def __init__(self):
        self.__data={"nom": None, "prenom": None, "age": None}
 
    def setValue(*args, **kwargs):
        for (k, v) in kwargs.iteritems():
            if k not in self.__data.iterkeys(): raise keyError
            self.__data[k]=v
    def getValue(k):
        return self.__data[k]

Avec la même façon de s'en servir

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
personne=cPersonne()
personne.setValue(nom="toto", prenom="alfred", age=18)
print personne.getValue("nom")
print personne.getValue("prenom")
print personne.getValue("age")

Mais toutefois bien plus facilement évolutive (si je veux rajouter l'adresse je n'ai qu'une info à rajouter dans data). Alors en fait je me demande s'il y aurait une contre-indication quelconque (notamment sur la vitesse d'exécution) à envisager systématiquement la seconde manière de conception chaque fois qu'on doit gérer qqchose ??? Parce que quand je regarde divers objets par-ci par là (par exemple sur des exemples PyQt), c'est toujours la première conception qui est mise en oeuvre. Là je me dis que ceux qui ont programmé ces exemples ne sont pas des manches et ont donc sûrement dû avoir la même idée mais ils ne l'ont jamais exploitée.
Et donc peut-être je me dis que cette façon de concevoir des objets "tout dico" ne serait peut-être pas tiptop question perfos.

Donc si quelqu'un a un avis là-dessus...

Merci à tous de votre attention

[wiztricks]

Salut,

Mais toutefois bien plus facilement évolutive (si je veux rajouter l'adresse je n'ai qu'une info à rajouter dans data). Alors en fait je me demande s'il y aurait une contre-indication quelconque (notamment sur la vitesse d'exécution) à envisager systématiquement la seconde manière de conception chaque fois qu'on doit gérer qqchose ???

Fonctionnellement, c'est pareil.
La deuxième forme est une sorte de proxy entre une classe/instance et un "record" qui pourrait sortir d'une BDD, d'un fichier,...
C'est plus flexible, mais côté performance, chaque indirection coûte.

Parce que quand je regarde divers objets par-ci par là (par exemple sur des exemples PyQt), c'est toujours la première conception qui est mise en oeuvre. Là je me dis que ceux qui ont programmé ces exemples ne sont pas des manches et ont donc sûrement dû avoir la même idée mais ils ne l'ont jamais exploitée.

Le but de ce genre d'exemple est de montrer l'utilisation de Qt (ou autre). Ils sont généralement "auto-porteur": peu ou pas d'interfaces avec le monde extérieur.

- W

[Sve@r]

La deuxième forme est une sorte de proxy entre une classe/instance et un "record" qui pourrait sortir d'une BDD, d'un fichier,...

Héhé... tu te doutes bien évidemment que c'est exactement mon cas. Et en plus je suis confronté aux évolutions "relativement" fréquences de la bdd en question. Et vas-y qu'un tel ou un autre vient me voir pour me demander s'il est possible de rajouter une info en plus sans se douter que de l'autre coté le hamster il galope dans sa cage pour suivre...

C'est plus flexible, mais côté performance, chaque indirection coûte.

C'est ce que je pensais. Maintenant faut voir le ratio de ce coût. Surtout que dans mon cas précis, je gère "un" seul objet (et non un tableau d'objets)...

[wiztricks]

Héhé... tu te doutes bien évidemment que c'est exactement mon cas.

Les tutos ne sont pas toujours le reflet de la vraie vie.

Et en plus je suis confronté aux évolutions "relativement" fréquences de la bdd en question.

SQAlchemy est pas mal pour çà: çà crée plein de redirections pour faciliter la bougote du programmeur. Mais c'est "compliqué", il faut passer du temps pour être confortable avec.
- W