Rendre les classes Objective-C jolies

Question

Je voulais vous demander à tous pour vos opinions sur les odeurs de code en Objective C, plus particulièrement Cocoa Touch. Je suis en train de travailler sur un jeu assez complexe, et sur le point de lancer la Grande décembre Refactoring.

Un bon nombre de mes classes, les modèles en particulier, sont plein de méthodes qui traitent les affaires internes de la logique; je vais cacher ces privé, catégorie, dans ma guerre contre les énormes fichiers d'en-tête. Ces catégories privées qui contiennent un grand nombre de déclarations, et cela me rend mal à l'aise... presque comme Objective-C est pour me faire sentir coupable à propos de toutes ces méthodes.

Plus je refactoriser (une bonne chose!), plus j'ai de maintenir toute cette duplication (pas très bon). Il se sent juste mal.

Dans une langue comme le Rubis, la communauté met BEAUCOUP l'accent sur très court, clair, beau méthodes. Ma question est, pour Objective C (Cocoa Touch en particulier), combien de temps sont vos méthodes, de quelle taille sont vos contrôleurs, et de combien de méthodes par classe que vous trouverez tous les devient typique dans vos projets? Sont-il particulièrement agréable, de beaux exemples de Classes constituées de courtes méthodes en Objective-C, ou est-ce tout simplement pas une partie importante de la langue de la culture?

DIVULGATION: je suis en train de lire "Le Petit Intrigant", ce qui doit expliquer ma tristesse, re: Objective C.

Answer 1

La beauté est subjective. Pour moi, un Objectif-la classe C est belle si elle est lisible (je sais ce que c'est censé le faire) et maintenable (je peux voir ce que les parties sont responsables de faire quoi). Je n'aime pas à être jeté à la lecture du code par un nouvel idiome. Un peu comme lorsque vous lisez un livre et que vous lisez quelque chose qui vous emmène de l'immersion et vous rappelle que vous êtes la lecture.

Vous aurez probablement beaucoup de différents, mutuellement exclusives, des conseils, mais voici mes pensées.

• Rien de mal avec les méthodes privées d'être privé de la catégorie. C'est ce qu'il est là pour ça. Si vous n'aimez pas les déclarations qui encombrent le fichier soit utiliser un code de pliage dans l'IDE, ou des extensions de la catégorie dans un fichier différent.
• Les méthodes et les marquer avec des #pragma mark des déclarations
• Quelle que soit la disposition du code que vous utilisez, la cohérence est importante. Prenez quelques minutes et d'écrire vos propres règles (voici le mien), donc si vous oubliez ce que vous êtes censé faire de vous une référence.
• Le contrôleur n'a pas à être le délégué et la source de données, vous pouvez toujours vous d'autres classes pour ces.
• Utiliser des noms descriptifs pour les méthodes et propriétés. Oui, vous pouvez le document, mais vous ne pouvez pas voir la documentation lors de Xcode s'applique la complétion de code, où le bien nommé les méthodes et les propriétés de payer. Aussi, les commentaires de code sont bloquées si elles ne sont pas mis à jour alors que le code lui-même des modifications.
• N'essayez pas de les écrire intelligente de code. Vous pourriez penser que c'est mieux de la chaîne d'une séquence d'appels de méthode sur une ligne, mais le compilateur est mieux optimiser que vous ne le pensez. Il est normal d'utiliser des variables pour stocker des valeurs (pour la plupart ce sont juste des pointeurs de toute façon, donc relativement faible) si elle améliore la lisibilité. Écrire du code pour les humains à lire.
• SEC s'applique à Objective-C en tant que bien que d'autres langues. Ne soyez pas inquiet à propos de refactoring de code en plus de méthodes. Il n'y a rien de mal à avoir beaucoup de méthodes tant qu'ils sont utiles.

Answer 2

La première chose que je fais avant même la mise en œuvre de la classe ou de la méthode est de se demander: "Comment aurais-je envie de l'utiliser depuis l'extérieur?"

J'ai jamais, jamais, jamais, jamais de commencer par l'écriture de l'intérieur de mes classes et les méthodes de la première. En commençant avec un élégant API publique de l'intérieur ont tendance à devenir élégant pour gratuit, et si ils ne le font pas alors la laideur est au moins pour une méthode ou une classe, et pas le droit de polluer le reste du code, c'est l'odeur.

Il existe de nombreux modèles de conception de là, deux décennies de codage, qui m'ont appris que le seul modèle qui résistent à l'épreuve du temps: BAISER. Keep It Simple Stupid.

Quelques règles de base à respecter, pour n'importe quelle langue ou de l'environnement:

• Suivez votre intuition en plus de tous les conseils que vous avez lu ou entendu!
• Renflouer tôt!
  • Si nécessaire, vérifier les entrées de début et de renflouer rapidement! Moins de nettoyage à faire.
• Ne jamais ajouter quelque chose à votre code que vous n'utilisez pas.
  • Une option pour "inverser" pourrait se sentir comme quelque chose d'agréable à avoir en bas de la route.
  • Dans ce cas, l'ajouter en bas de la route! Ne perdez pas de temps en ajoutant de la complexité que vous n'avez pas besoin.
• Les noms de méthode doit décrire ce qui est fait, jamais comment il est fait.
  • Les méthodes devraient être autorisés à changer leur mise en œuvre sans modification de leur nom, tant que le résultat est le même.
  • Si vous ne pouvez pas comprendre ce qu'est une méthode ne de son nom, puis modifier le nom!
  • Si la façon de procéder est assez complexe, puis utilisez les commentaires pour décrire votre mise en œuvre.
• Ne craignez pas les singletons!
  • Si votre application n'ont seulement qu'un modèle de données, alors il est un singleton!
  • Passant autour d'une seule variable tout plus de l'endroit est tout simplement semblant que c'est quelque chose d'autre, mais un singleton, et en ajoutant de la complexité en tant que bonus.
• Plan de défaillances à partir du début.
  • Toujours utiliser pour doFoo:error au lieu de doFoo: depuis le début.
  • Créer nice, NSError des cas avec l'utilisateur final lisible descriptions localisées depuis le début.
  • C'est une grande douleur de modernisation de la gestion des erreurs/messages à un grand application existante.
  • Et il y aura toujours des erreurs, si vous avez des utilisateurs et IO impliqué!
• Cocoa/Objective-C est un Objet* Orientée, pas **Classe Orientée comme la plupart des enfants populaires là-bas qui prétendent être de la programmation orientée objet.
  • Ne pas introduire un muet valeur classe avec seulement des propriétés, une classe sans les méthodes de l'exécution réelle de travail pourrait tout aussi bien être une struct.
  • Laissez vos objets intelligents! Pourquoi ajouter une toute nouvelle FooParser classe, si un fooFromString: méthode Foo est tout ce dont vous avez besoin?
• Dans le Cacao, ce que vous pouvez faire est toujours plus important que ce que vous êtes.
  • Ne pas introduire un protocole si une cible/action peut faire.
  • Ne pas vérifier que les instances se conforme aux protocoles, est une sorte de classe, c'est pour le compilateur.

Answer 3

Mes 2 cents:

1. Les propriétés sont généralement mieux que l'ancien style de lecture+setter. Même si vous utilisez @propriétés dynamiques - les déclarer avec @bien, c'est beaucoup plus instructif et de plus courte durée.
2. Personnellement, je ne pas simuler "privé" des méthodes pour les classes. Oui, je peux écrire une catégorie quelque part dans l' .m(m) de fichiers, mais depuis l'Obj-C n'a pas de pure façon de déclarer une méthode privée - pourquoi devrais-je en inventer un? De toute façon, même si vous avez vraiment besoin de quelque chose comme ça - de déclarer un "MyClassPrivate.h" avec une catégorie et l'inclure dans le .m(m) des fichiers pour éviter de dupliquer les déclarations.
3. De liaison. De liaison pour la plupart Contrôleur de <-> de l'INTERFACE utilisateur de relations, d'utiliser des transformateurs, des formateurs, il suffit de ne pas écrire des méthodes pour lire/écrire des contrôles valeurs manuellement. Il rend le code ressembler à quelque chose de MFC ère.
4. C++, beaucoup de code à l'air beaucoup mieux et plus court lorsqu'il est écrit en C++. Depuis compilateur comprend les classes C++ c'est un bon point pour le refactoring, surtout lorsque l'on travaille un faible niveau code.
5. J'ai l'habitude de diviser de gros contrôleurs. Quelque chose de plus de 500 lignes de code est un bon candidat pour la refactorisation pour moi. Par exemple, j'ai une fenêtre de document controller, depuis une certaine version de l'application, elle s'étend avec l'image de l'importation/exportation d'options. Contrôleur de pousse jusqu'à 1.000 lignes 1/2 est à l'image de "trucs". C'est un "déclencheur" pour moi de faire un ImageStuffController, l'instancier dans la PLUME et de mettre tous d'image par rapport code n'.

Tous les ci-dessus, il est plus facile pour moi de maintenir mon code. Pour des projets d'envergure, où le fractionnement des contrôleurs et des classes de garder 'em petits résultats grand nombre de fichiers, j'ai l'habitude d'essayer d'extraire une partie du code dans un cadre. Par exemple, si une grande partie de l'application est en communication avec externe les services web, il est généralement un moyen direct pour extraire un MyWebServices.cadre de l'application principale.