Discussion :

[il_a_ri]

Je me questionne sur l'importance de l'implentation d'une classe... Prenons une application qui consulte un base de données qui contient des informations sur des clients, est-il pertinant dans cette application de créer une classe client ou simplement utiliser des réquêtes SQL pour effectuer les opérations :

J'espère avoir été clair... sinon je préciserai en fonction de vos commentaires...

Merci d'avance

[laffreuxthomas]

alors : c'est simple, toutes les solutions sont défendables !

Alors j'ai une question du coup : ton application fera quoi, dans les grandes lignes?

Thomas

PS : dans les grandes lignes ça veut dire en deux grandes lignes

[cassandra]

je pense que si tu utilise une classe client... tu pourra toujours la reutiliser ensuite pour ameliorer ton programme ... ou meme l'utiliser avec un autre.

[il_a_ri]

Mon questionnement est plutôt au sens général de la programmation OO. Est-ce que la création de classe est à pratiquer en toute occasion? Ne serait-ce que pour permettre d'absorber et d'élaborer les concepts OO même dans le développement d'une application de petite envergure?

Pour en revenir à mon premier exemple et répondre à laffreuxthomas, mon application est un préambule à l'élaboration d'un systéme de gestion de l'information au sein de l'entreprise. Je comprends que l'apport des classes dans le développement OO n'est plus à expliquer mais lorsqu'on travaille sur une base de données (ex: infos d'un client), est-il nécessaire de créer une classe qui va gérer cette information? Ou bien cela devient-il du superflu puisque d'une manière ou d'un autre, il faudra récupérer, modifier, suprimmer ces infos avec du SQL et ensuite les afficher ou effectuer une quelconque opération?

J'imagine que je ne suis pas vraiment clair mais l'expression de mon questionnement à pour but de préciser ma penser en alimentant la discussion que cela peut entraîner... j'espère que vous serez nombreux à émettre vos idées et questions.

Merci et bonne journée

[laffreuxthomas]

Bon. Si ta question c'est de savoir s'il faut créer une classe pour chaque table SQL, la réponse est non.

Tu ne prends pas le problème par le bon bout :

Toi tu te dis : j'ai une base de données, donc maintenant comment la manipuler? Il faut créer des classes pour la manipuler yes or not ?

Ce qu'il faut que tu te dise : j'ai un problème (présenter une liste de clients à la secrétaire, une autre au directeur, faire des stats, ...) et comment le résoudre?

Il faut concevoir tes classes en fonction de à quoi elles servent. Pas en fonction de comment est fait la base de données.

Tu prends le problème en partant de la BD et tu te dis comment arriver jusqu'à l'utilisateur. Il faut partir des besoins des utilisateurs et redescendre jusqu'à la BD.

En espérant que ça t'aide...

Thomas

[il_a_ri]

L'évidence même mon cher Watson

Sincèrement merci, c'était trop évident pour que je l'aborde dans ce sens là... j'espère ne pas provoquer trop de fou rire en admettant une telle chose mais bon j'en suis encore au niveau débutant... et la tête pleine d'idées... faudrait que je fasse le ménage afin de permettre à mon esprit de "focusser" sur un problème

Encore merci pour ton apport Thomas

P.S. Ce message n'est en aucun cas ironique

[Christophe Brun]

Je tombe sur votre discussion un peu tardivement, et un peu par hasard. J'ignore si mon opinion là-dessus peut encore présenter quelque intérêt, trois mois et demi plus tard, mais voici :

L’importance qu’il faut donner à l’encapsulation de fonctionnalités dans un projet dépend beaucoup de l’environnement de travail que tu souhaites construire. Pour dire les choses brutalement, je pense qu’un projet de développement orienté objet qui n’utilise pas des familles de classes pour couvrir au moins 99% de son architecture sera au mieux médiocre, peut-être mauvais.

Il sera mauvais en termes de clarté de la construction, de maintenabilité et d’évolutivité. Il se peut très bien que le code fonctionne, évidemment. Il se peut très bein qu’il soit rapide à écrire, du moins dans sa version initiale. Et tant qu’il n’y a que un ou deux programmeurs à travailler dessus, tant qu’il y a peu de lignes de code, tant que ce sont les programmeurs qui ont conçu l’architecture initiale et qui l’ont bien présente à l’esprit qui ont la maintenance en charge, tout cela peut passer sans douleur.
Mais précisément, la POO propose des méthodes de conception (par encapsulation) qui permettent de s’affranchir de ces contraintes, en obligeant le programmeur à faire des découpages fonctionnels clairs. Avec des langages tels que le C++, l’écriture de classes permet aussi de déclarer des contraintes qui aident puissamment à structurer le code.

La principale difficulté de la POO consiste justement à vraiment adopter cette approche par encapsulation qui n’est guère intuitive. Spontanément, nous avons tendance à construire nos raisonnement (et nos algorithmes, donc notre code) de manière procédurale. L’approche orientée objet nous oblige à rompre avec cette structure mentale, ce qui explique que, si le principe de la POO semble relativement simple, sa mise en pratique efficace demande pas mal de travail et de réflexion. J’ai souvent entendu dire qu’il fallait au moins 5 ans pour faire un bon développeur ‘objets’. Pour autant que j’aie pu en juger, c’est exact.

Pour en revenir à ta question : si tu désires faire de la POO, ne la fais pas à moitié. Un projet construit de manière procédurale peut être un bon projet. Un projet construit sur un mode orienté objets peut être un bon projet. D’après ce que j’ai pu constater, un projet qui mélange les deux approches a une forte tendance à en cumuler les défauts plutôt que les avantages, et sera certainement un mauvais projet, ou à tout le moins médiocre.

A titre personnel, j’avoue que plus le temps passe, et mieux je prends la mesure de la puissance qui réside dans l’approche orientée objet. Même pour des petits projets personnels, j’utilise des classes (ou je les ré-utilise d’un projet à l’autre). Alors a fortiori, s’il s’agit de gérer le système d’information d’une entreprise...