Salut,

J'ai crée une base de programme en SDL et C++. J'aimerais que vous me disiez ce que vous en pensez : Lien

S'il manque des éléments, dites-le moi pour que je l'améliore.

'jour,

Ce qui suis n'est valable que pour un flémard dans mon genre :

A première vu, je dois dire que ça parait mal parti. Pourquoi? Ben si tu n'utilises pas Fmod ou que tu utilises une lib supplémentaire, tu es très bloqué (ou tu recodes toute la class.)

Enfin ne le prends pas mal

Hiura

Alors, il vaudrait mieux que je l'enlève la FMOD Si je fais un autre classe qui gère la FMOD et que l'utilisateur ne déclare pas d'objet de la classe FMOD, le compilo, indiquera't'il des erreurs?

Franchement, si c'est seulement pour toi, mets ce que tu vas utiliser dans ta classe, mais pour donner ça à qqn, ça ne va pas trop jouer, à moins qu'il ai les mêmes besoins que toi...

(Je ne vois non plus pas trop l'interet de faire une classe pour ça..enfin si il y en a un dis le moi

A la vue du .h, je dirais pas terrible non plus. J'ai pas été voir le reste, parce que je me place dans la position du développeur client qui utilise la classe. En tant qu'utilisateur de la classe, l'implémentation ne m'intéresse pas, c'est ta tambouille. Pourquoi ton implémentation est elle bof?

Tout simplement parce qu'elle ne m'apporte rien, sinon des contraintes par rapport à la SDL "C". Dès lors pourquoi m'encombrerai je d'une couche de code supplémentaire, qui va ralentir mes algos, et peut en plus être buggée?

Définir une interface "pour le sport" n'a aucun intérêt. Un framework C++ qui vient se mettre sur une librairie C doit m'apporter quelque chose d'autre que des contraintes d'utilisation, sinon autant utiliser directement la librairie C.

L'implémentation que tu proposes, n'apporte rien. Regrouper les 4 instructions d'initialisation de la SDL dans une fonction membre de classe ne suffit pas à justifier l'utilisation de cette classe. De même, la gestion d'évènement que tu proposes est très sommaire et ne conviendra pas dans la majorité des cas.

Dans le cas d'un wrapper C++ pour la SDL, je pense qu'il y a deux éléments intéressant:

• Des Messages Crackers pour la gestion des évènements: L'idée est de faire supporter par le framework toute la gestion d'évènements avec un comportement par défaut, pouvant être spécialisé par héritage, un peu à la manière des framework d'interface bureautique pour la gestion des fenêtres.
• Un gestionnaire de ressources: Faire en sorte que le framework s'occupe de la gestion des ressources gérées par la bibliothèque. L'idée est de tenir à jour des listes de surface, fonts, etc... L'intérêt de tenir ces listes à jour permettra d'être sûr de tout libérer à la sortie du programme, mais également de ne charger un élément qu'une seule fois, gérer sa durée de vie automatiquement via des compteurs de référence, et enfin d'assurer sa synchronisation en cas d'utilisation par des timer, ou dans un programme multi-thread.
• Une encapsulation des objets de la SDL elle même, surfaces, font...

Si je voulais implémenter un wrapper objet sur la SDL c'est comme cela que je le verrais. Idéalement, le gestionnaire de ressource serait implémenté sous la forme d'un singleton. Pour la gestion des event, je verrais bien une pile de messages crackers, ce qui pourrait permettre à peu près n'importe quel enchainement de phase dans le programme. Par exemple basculer facilement d'un gestionnaire de clavier pour un jeu, à un gestionnaire de menu. La transition entre les différents gestionnaires étant assuré par le singleton, qui implémenterait une méthode générique de gestion des évènements (un peu dans le genre de la pompe à message de Windows pour ceux qui connaissent). L'intérêt de le gérer de cette manière est de pouvoir mettre facilement en place un contrôle d'erreur par gestion d'exception, sans avoir à mettre des try partout, la fonction de traitement racine de la boucle d'évènement, pouvant prendre en charge le traitement standard.

Ce qui est important, c'est l'apport en sécurité et en simplicité que permet le framwork, pour les programmeurs qui vont l'utiliser. Quand on conçoit une classe ou un ensemble de classes, c'est la simplicité pour le programmeur qui va l'utiliser qui doit toujours rester le point central. Une classe qui n'apporte rien n'a aucun intérêt, une classe qui complique le travail non plus.

Pour prendre un exemple concret, la conception de ma voiture est très largement au delà de mes compétences, ce qui ne m'empêche pas de l'utiliser tous les jours. Ici c'est la même chose, le programmeur qui utilise le framework, est comme moi avec ma voiture, il l'utilise et ne devrait pas avoir besoin de connaitre ni la SDL, ni les détails d'implémentation. Le fait que la conception de ma voiture ait nécessité le travail de centaines d'ingénieurs pendant des années est sans importance pour moi, elle marche conformément au cahier des charges et c'est tout ce qui m'importe. Quand on conçoit une classe, il faut toujours se placer du coté de l'utilisateur, pour lui faciliter la tâche au maximum. Les ingénieurs qui ont conçu ma voiture, l'ont doté d'une direction assistée, pour que je puisse la manoeuvrer sans efforts. Je n'ai pas la moindre idée du fonctionnement de la direction assistée de ma voiture, je n'ai pas besoin de forcer pour tourner le volant et c'est tout ce qui importe.

(edit)

PS: Quand je parle d'utilisateur, il s'agit bien sûr du programmeur qui va utiliser la classe dans ses programmes, pas de l'utilisateur final du programme. Mon discours s'applique cependant aussi aux utilisateurs de classe, le secret d'un bon programme est sa facilité d'utilisation.