PROFDINFO.COM

Votre enseignant d'informatique en ligne

Comment avoir ses points en laboratoire

Nous prenons pour acquis que tout étudiant avisé apprécie obtenir un maximum de points pour son travail; c'est pourquoi nous avons créé ce document qui énumère de façon la plus précise possible, nos exigences pendant le cours de KAB.

Nom des fichiers et noms des classes

Commentaires

Où vont les commentaires dans les fichiers que vous créez? Que devez-vous y mettre? Voilà les réponses:

Le fameux #pragma once

#pragma once est une instruction au pré-compilateur qui permet de nous assurer qu'un fichier .h ne sera jamais inclus plus d'une fois lors d'une même compilation. C'est toujours possible qu'un fichier .h soit inclus dans un autre, puis qu'on inclue le premier et le deuxième (qui contient le premier) dans le main. Cette situation peut être problématique et causer d'étranges bogues à la compilation.

Pour éviter ça, on peut utiliser #IFNDEF, #DEFINE et #ENDIF pour définir une constante à la précompilation et déclarer la classe seulement si cette constante n'a pas été définie avant, ou on peut utiliser #pragma once, solution équivalente et élégante en une seule ligne.

Y a-t-il une différence entre les deux? Oui: #pragma once est spécifique au compilateur (et ne sera donc pas nécessairement supportée par tous), alors que #ifndef est universelle. Dans le cadre de ce cours, comme nous utilisons (normalement) tous le même compilateur, vous pourrez choisir la méthode qui vous plaît -- n'oubliez toutefois pas d'en utiliser une pour éviter des problèmes, même si votre projet est simple et que ça ne semble rien changer de le faire ou non!

L'utilisation de constantes

Il est toujours une exellente pratique d'utiliser des constantes plutôt que des nombres magiques qui surgissent soudainement dans le code sans plus d'explication. L'utilisation d'une constante clarifie le code (c'est toujours plus beau de faire une boucle qui va de Min à Max que de 3 à 49) et simplifie sa maintenance (c'est toujours plus facile de changer un nombre à un seul endroit qu'à douze, disséminés partout dans le code, dans plusieurs fichiers).

Tant que nous n'aurons pas vu une meilleure méthode, déclarez les constantes au début du .h concerné, mais avant la déclaration de la classe. Par exemple:

////////////////////////////////////////////////
// Compteur.h
// Joan S. Morales
// 2011-02-02
// Déclaration de la classe CCompteur
////////////////////////////////////////////////

#pragma once

const int Min = 0;
const int Max = 1000000; // Un million

class CCompteur
{
// ...
};

Le respect des spécifications

Lorsque l'énoncé de l'exercice spécifie certaines choses, vous devez les respecter. C'est possible que vous ayez en tête une autre façon de faire ça, qui peut même vous sembler meilleure que la méthode demandée. Peu importe, vous devez respecter les spécifications. C'est d'autant plus vrai si on vous fournit un .h ou un main pour tester vos classes -- modifier un .h a de grandes conséquences puisqu'on modifie alors l'interface: on ne devrait pas prendre ça à la légère. Et le professeur pourrait vouloir utiliser son main pour tester vos classes -- si ça mène à des erreurs, c'est vous qui en serez responsable.

Si vous pensez à une fonctionnalité supplémentaire, qui ne demande pas qu'on modifie les spécifications données et qui pourrait simplement être ajoutée au programme, libre à vous de le faire (en vous assurant que ce qui est demandé fonctionne toujours comme il le devrait et que les autres règles et normes de programmation soient respectées). Ceci ne vous donnera normalement pas de points supplémentaires (à moins que ça soit spécifié dans l'énoncé), mais si ça vous amuse, allez-y.

Lorsqu'on vous demande de créer un main qui teste vos classes, sans plus d'explications, vous pouvez être aussi créatif ou aussi simpliste que vous le voulez, tant que votre main teste effectivement chaque fonctionnalité de chaque classe (incluant des cas d'erreurs) et que son interface demeure claire.

Si l'interface d'une classe est fournie, vous pouvez toujours ajouter des méthodes privées (donc inutilisables de l'extérieur) qui vous seront utiles. Un get et un set peuvent être privés aussi, ne l'oubliez pas!

Les méthodes const

Toutes les méthodes qui ne modifient pas les attributs d'une classe devraient être déclarées const. C'est automatiquement le cas de tous les accesseurs (get), mais ça s'appliquera aussi sans aucun doute à plusieurs autres méthodes. Tâchez de développer le réflexe, c'est une bonne pratique.

L'encapsulation

C'est le premier grand principe de la programmation orientée objet et vous devrez vous assurer de le respecter en tout temps. Ça signifie que l'interface doit être simple et claire, que les détails de l'implémentation doivent être cachés et que l'objet bien encapsulé doit s'assurer de conserver en tout temps sa cohérence interne. Donc:

Séparer la classe de l'interface homme-machine (IHM)

À moins qu'il en soit spécifié autrement dans l'énoncé d'un exercice, votre classe ne doit normalement pas dépendre d'une IHM précise. Puisque la programmation orientée objet vise la réutilisation des objets d'un projet à un autre, on voudrait bien qu'une classe ne soit pas limitée à n'être utilisée que dans un projet console.

Évitez donc de mettre des cin et des cout directement dans vos méthodes. Normalement, la classe n'en fera pas et c'est le main qui s'occupera de ça (et de relayer l'information de et à la classe via des valeurs de retour et des paramètres). Ainsi, on pourra éventuellement utiliser votre classe dans un projet Windows sans console et tout fonctionnera aussi bien.

Notez que certaines exceptions à cette règle seront parfois faites pour simplifier les projets -- elles vous seront alors spécifiées.

Montrez nous votre progression et prenez de l'avance

Lorsque vous avez terminé un exercice, si vous n'êtes pas certain d'avoir bien fait les choses, montrez-le à votre professeur. Vous serez alors certain d'avancer dans la bonne direction!

Les séances d'exercices sont séparées par des séances théoriques. Parfois, la séance théorique sera indispensable pour arriver à faire correctement les laboratoires qui la suivent, mais parfois non. Si vous terminez rapidement les exercices demandés, c'est une bonne idée d'essayer de faire les suivants. Le professeur vous avisera si vous n'avez pas les notions théoriques nécessaires pour y arriver afin que vous ne perdiez pas votre temps.

N'hésitez pas à poser des questions

Sans sombrer dans l'excès et demander au professeur de valider chaque pas que vous faites, ne vous gênez pas pour poser des questions afin d'être certain d'avoir bien compris ce que vous devez faire, ou si vous êtes bloqué sur un problème qui semble insoluble. Toutefois, le professeur s'attend à ce que vous ayez tenté de faire du débogage avant de l'appeler à chaque problème...

La remise hebdomadaire

À peu près chaque semaine, votre professeur vous demandera de lui remettre un des exercices faits précédemment. Ceci peut survenir à tout moment, il est donc important que vous ayez fait les exercices demandés le jour demandé, quitte à les finir à la maison avant le cours d'après si vous n'avez pas été assez rapide en classe. Il est également important que vous conserviez tous ces exercices et que vous les ayez avec vous à chaque cours, sur une clé USB et/ou sur un dossier dans votre profil.

Lorsque vous remettez un projet, vous devrez d'abord effacer les fichiers et dossiers inutiles. Ces fichiers sont regénérés automatiquement lors de l'ouverture ou de la compilation du projet, donc inutile d'encombrer la boîte de remise avec ça! Effacez donc du dossier de votre solution :

Puis effacez du dossier de votre projet, se trouvant à l'intérieur du dossier de votre solution:

Ensuite, assurez-vous que votre solution n'est plus ouverte dans Visual Studio et zippez le dossier de la solution. Vous pouvez utiliser WinZip pour ce faire si vous l'avez, mais vous pouvez aussi cliquer sur le dossier de votre solution avec le bouton de droite de votre souris, puis choisir "Envoyer vers...", puis "Dossier compressé". Un fichier zip contenant toute votre arborescence de projet apparaîtra alors. C'est ce fichier que vous devrez remettre.

Pour la remise, connectez-vous à Colnet, puis, à droite de votre photo, cliquez sur le nom du cours (Programmation orientée objet). Allez ensuite à l'onglet "Évaluations" et repérez la ligne de laboratoire correspondant (il y en aura un par chapitre). Complètement à droite se trouvera un lien "Remettre un fichier". Cliquez dessus, puis téléchargez votre fichier zip.