Meilleure façon D'organiser des cours de MATLAB? [fermé]

le nouveau style de fichier unique a quelques avantages. Il vous permet et vous encourage à écrire beaucoup de petites méthodes, qui je pense conduit à mieux-code pondéré. La difficulté de créer un nouveau fichier, de le sauvegarder et de l'ajouter au contrôle source (nous Tous utilisant le contrôle à la source, non?) est mineur, mais additionné sur quelques douzaines de petites méthodes est suffisant qu'il me décourage habituellement de factoriser une classe dans des bits plus fins de fonctionnalité. Et éditer toute la classe est pratique pour parcourir, rechercher et remplacer, et ne pas avoir à ouvrir une douzaine d'onglets d'éditeur séparés, qui peuvent ensuite être utilisés pour organiser le code source pour les différentes classes.

pour les bases de codes plus grandes, il peut y avoir des avantages de performance au style de fichier unique. Les systèmes de contrôle des sources et de déploiement qui se succèdent au-dessus de l'arbre des sources ont un coût par fichier pour des choses comme les opérations stat et diff. Pour un codebase plus grand, disons, des milliers de méthodes, qui peuvent être significatives, en particulier sur un lecteur réseau. Je soupçonne qu'il y a aussi un effet de performance pour les applications déployées avec le compilateur Matlab. Temps de démarrage augmente avec la taille de l'déployé base de code. Il y a une partie par fichier de ce coût, des opérations de fichier, et parce que les fichiers (je pense) sont cryptés individuellement. Je soupçonne, mais je n'ai pas testé expérimentalement, que l'utilisation de définitions de classe de fichier unique réduira le coût de démarrage pour les applications compilées de Matlab.

cependant, j'utilise l'ancienne organisation multi-fichiers pour la plupart de mon code. En partie parce que notre base de code a été commencé il y a quelques années avant que le nouveau style était généralement disponible. Mais en partie pour la performance. La nouvelle organisation à fichier unique ne fonctionne qu'avec les nouvelles classes de Matlab de style MCOS, et elles sont plus lentes que les anciennes classes de Matlab de style en raison d'une expédition de méthode plus élevée. Par exemple: voici un extrait de benchmark montrant le temps d'exécution des méthodes do-nothing nop ().

Calling each function/method 100000 times
nop() function:                 0.02715 sec   0.27 usec per call
nop(obj) method:                0.24629 sec   2.46 usec per call
classdef nop(obj):              0.98572 sec   9.86 usec per call
classdef obj.nop():             1.81307 sec  18.13 usec per call

dans une base de code qui fait beaucoup d'appels de méthode, cela peut avoir un impact significatif sur le rendement. (Voir aussi est-ce que MATLAB OOP est lent ou est-ce que je fais quelque chose de mal?)

un autre nit est que L'auto-indenter de Matlab indentera chaque section et chaque méthode dans une définition de classe, de sorte que la ligne de base de tout votre code exécutable est deux onglets s'arrête, gaspillant 8 colonnes d'écran immobilier.

dans l'ensemble, si ce n'était pas pour des considérations de performance OO, j'irais probablement avec un seul fichier, et j'écris de nouvelles non performance critiques des classes de cette façon.

mise à jour: il ressemble aussi à contentsrpt(), un générateur de documentation utile, ne fonctionne pas avec les fonctions définies à l'intérieur du fichier classdef; seulement celles des fichiers de fonction séparés.

j'ai trouvé @-directories pour être une bidouille (public/privé par exemple, c'est quoi?) c'est mieux d'oublier. Dans la plupart des recient versions (depuis 2007b, je crois), la meilleure façon d'organiser vos classes avec des packages. Cela donne un espace de nom beaucoup plus propre. Je pense que travailler avec toute la classe dans un fichier rend beaucoup plus facile d'avoir une idée de ce que la classe fait, et 1000% moins ennuyeux quand il s'agit de refactoring (imaginez changer 8 fichiers après avoir changé un nom de variable).

j'utilise la méthode du fichier unique. Je trouve qu'il est un peu plus facile d'organiser le code quand il se compose d'un seul fichier, et les titres de cellules le rendent très facile de sauter autour entre les méthodes. Aussi, si je crée un nouveau @classe, je pourrais avoir besoin pour recréer le chemin d'accès avant de pouvoir l'utiliser, et je n'ai pas la patience pour cela.

ayant dit tout cela, je ne pense pas que le style de fichier simple est beaucoup mieux que le style de fichier multiple; ayant beaucoup de petits fichiers faciles à consulter peut être très utile.

l'avantage d'utiliser le répertoire @ClassName est que matlab vous force à effacer et recharger une classe si vous apportez des modifications au fichier classdef. Si vous mettez l'implémentation des fonctions dans des fichiers m séparés et que vous mettez simplement les signatures de la méthode dans le fichier classedef, vous pouvez vous faufiler avec l'implémentation sans avoir à effacer la classe.