choix de conception pour un objet

Bonjour,
je vais faire un objet "Client". Cet objet aura une méthode .Add afin de permettre l'ajout d'un client dans un base de données.
Cet objet aura d'autres méthodes et un ensemble de propriétés qui correspondent + ou - aux différentes colonnes de ma table CLIENT.
Question: comment passer les informations à mon objet Client pour appliquer la méthode .Add ?

Methode 1 : utiliser les propriétés de l'objet Client dnas la méthode Add
Client = new Client();
Client.numero = 123;
Client.nom = "eee";
Client.adresse = "aaa";
Client.Add();


Methode 2 : Passer toutes les info en paramétres de la méthode .Add
Client = new Client();
Client.Add (numero, nom, adresse);
// ou numero, nom, adresse sont des variables


Methode 3:Créer une structure qui sera passée en paramétre à la méthode .Add
StructAddClient structAddClient = new StructAddClient
structAddClient.numero = 123;
structAddClient.nom = "eee";
structAddClient.adresse= "aaaa";
Client = new Client();
Client.Add (structAddClient);

Pour ma part, j'ai une préférence pour la 3eme méthode car elle permet à l'utilisateur de l'objet de connaître précisément les champs à initialiser.

Qu'elle est la mieux, y en a t il d'autres ?

je ne sais pas dans quel language tu programme (peut etre que tu l'as précisé mais j'ai pas du le lire), mais pourquoi ne pas faire un constructeur de ta classe client avec tes trois champs n°, adresse et nom. Ensuite ta méthode Add ajouterait ton objet client, bêtement, dont les membres sont ceux spécifiés ?

Si tu fais de la POO, c'est ce qui me paraitrait le plus intuitif, mais je suis pas non plus LA référence en programmation...

Citation:

---

Envoyé par babedt

Bonjour,
je vais faire un objet "Client". Cet objet aura une méthode .Add afin de permettre l'ajout d'un client dans un base de données.
Cet objet aura d'autres méthodes et un ensemble de propriétés qui correspondent + ou - aux différentes colonnes de ma table CLIENT.
Question: comment passer les informations à mon objet Client pour appliquer la méthode .Add ?

Methode 1 : utiliser les propriétés de l'objet Client dnas la méthode Add
Client = new Client();
Client.numero = 123;
Client.nom = "eee";
Client.adresse = "aaa";
Client.Add();


Methode 2 : Passer toutes les info en paramétres de la méthode .Add
Client = new Client();
Client.Add (numero, nom, adresse);
// ou numero, nom, adresse sont des variables


Methode 3:Créer une structure qui sera passée en paramétre à la méthode .Add
StructAddClient structAddClient = new StructAddClient
structAddClient.numero = 123;
structAddClient.nom = "eee";
structAddClient.adresse= "aaaa";
Client = new Client();
Client.Add (structAddClient);

Pour ma part, j'ai une préférence pour la 3eme méthode car elle permet à l'utilisateur de l'objet de connaître précisément les champs à initialiser.

Qu'elle est la mieux, y en a t il d'autres ?

---

Methode 4:
martin = new Client(numero, nom, adresse);
dbTruc.addClient(martin)

Tu crees un client independamment de n'importe quelle base de donnees. Tu ajoutes un client grace a une classe qui gere l'insertion, la suppression des donnees dans ta BDD. C'est plus simple si tu veux changer de BDD. Tu peux meme avoir une classe par BDD.

La methode 1 n'est pas OO. Et la methode 3 est trop compliquee. Un constructeur avec 3 variables, c'est facile a initialiser.

:mouarf:
au moins on est d'accord

même si ma table possède plus de 30 colonnes (donc 30 param pour mon constructeur). J'en ai mis que trois dans les exemples pour ne pas avoir un trop gros poste...

Je développe en C# (je ne l'avais pas précisé)

je pense... oui. Meme si ta table possède plus de 30 colonnes. Dans tous les cas, si ce sont les temps de réponse auxquels tu pense, la "méthode 4" est optimale...

Salut,

*Peut-être* devrais tu déjà réfléchir à l'éventualité de "subdiviser" cette table composé d'énormément de champs en plusieurs tables en contenant chacune beaucoup moins.

En effet, même si je ne remet absolument pas en question le fait qu'un "client" puisse véhiculer une trentaine d'informations différentes, il faudrait déjà voir le nombre d'informations qui ne sont pas utilisées d'office (soit parce que l'utilisation d'une information donnée "empêche" celle d'une autre, soit parce qu'une information particulière est facultative dans certaines conditions)...

Entendons nous bien: ne sachant absolument pas quels objectifs sont poursuivis par la base de données, je ne me permettrai pas de juger de la nécessité de disposer de ces trente champs.

Par contre, je me pose des questions sur l'utilité de voir apparaitre ces trente champs dans une seule et même table...

Il faut savoir que, si ta table est composée de trente champs et que seule une dizaine sont effectivement utilisés en permanence, alors que les autres sont d'utilisation facultative, cela fini quand même par représenter une dépense d'espace inutile impressionnante.

Le tout sans compter que les requêtes de sélection et de mise à jour sont rendues bien plus difficile sur ce genre de table.

Evidemment, si tu n'es pas libre de la manière d'envisager les tables de la base de données, je comprendrai si tu me dis que tu ne peux pas la changer ;)

D'un autre coté, on dit souvent qu'en OO, si un objet a plus d'une responsabilité, c'est sans doute qu'il en a trop...

Je t'inviterais donc aussi à réfléchir aux responsabilités qui reviennent clairement à ton "client" et à celles qui devraient échoir à d'autres objets

De manière générale, il me semble de bon ton de se dire que, quitte à fournir une référence sur le "client" en cours de gestion, il me semblerait cohérent de distribuer différemment les responsabilités (tant du point de vue de la BDD que du point de vue des différentes classes que tu envisage de créer ;))

Merci pour toutes ces réponses (qui vont dans le même sens) :

Pour la petite histoire : j'ai évoqué une table CLIENT pour l'exemple - plus simple pour en discuter.
En fait, je travaille dans le milieu industriel et je dois gérer beaucoup d'informations. La table en question a déjà été "explosée" en trois tables (avec des relations 1,1 de chaque côté) - ce sont + ou - des données de fabrication de produits.

Merci encore

Ah, mais si tu avais parlé d'un produit à fabriquer, j'aurais déjà pu être plus précis...

Ta table de fabrication de produits pourrait par exemple etre subdivisé en trois tables, mais chacune comprenant un nombre restreints de champs, avec des relations 1-n...

Ainsi, tu aurais une table produit contenant

• le nom du produit
• sa description
• (une clé unique)
• (un numéro de référence)

Tu aurais aussi une table "ingrédients" contenant

• la référence sur le produit
• l'ingrédient à rajouter
• la quantité
• l'unité de mesure (si nécessaire)
• avec clé sur la référence sur le produit et l'ingrédient

Et tu aurait enfin une table etape contenant

• une référence sur le produit
• le numéro de l'étape
• (clé sur la référence et sur l'étape)
• le type d'action à entreprendre (mélanger, chauffer, refroidir, broyer, ...)
• un ou deux champs supplémentaire pour les informations "qui vont bien"

Au final, tu aurais un nombre sans doute acru d'enregistrement, mais un nombre restreint de champs à gérer ;)

Et le produit en phase de programmation serait composé

• de son nom
• de sa référence
• d'un conteneur d'ingrédients
• d'un conteneur d'étapes

et fournirait l'interface utile à la gestion de ces deux tableaux ;)

(tu aurais évidemment une classe "ingrédient" et une classe "etape", et on peut envisager que produit hérite d'ingrédient... des fois qu'il s'agisse d'un produit semi fini servant pour un autre produit :D)

Et tout cela reviendrait à dire "Pattern Composite"+"Pattern patron de méthode" ;)

Citation:

---

Envoyé par hed62

Et tout cela reviendrait à dire "Pattern Composite"+"Pattern patron de méthode" ;)

---

En gros, mais tu avouera que cela pourrait simplifier fortement la conception, non :question:

Je me permet d'ajouter, un peu à part :

Add, en général, c'est pour ajouter à un objet liste : maliste.Add(monobjet)
Et pour sauver un objet en base, c'est monobjet.Save()
J'ai été tres perturbé par le 1er post... juste à cause de ça. Peut-être une mauvaise habitude, mais j'ai vu beaucoup de code que je n'avais pas écrit qui utilise ces méthodes là, du coup, j'ai généralisé, et ça ne me semble pas mal ^^