Jusqu'où pouvez-vous aller en utilisant la sous-classe dans l'objectif-c?

Question

Dans une application iPhone, j'ai besoin de personnaliser l'apparence d'une classe UINavigationController. Par exemple, augmentez la taille de la barre et de la police. Mon client a vraiment besoin de cela, et de plus gros boutons aussi. Donc, au lieu d'écrire la classe de zéro, j'ai décidé de sous-classer UINavigationController. Ma question est, puis-je personnaliser la valeur par défaut d'une méthode ou d'un attribut? Y a-t-il des restrictions lors du sous-classement d'une classe?

Answer 1

Cela dépend de ce que vous entendez par "restriction". L'exécution ne vous empêchera pas de sous-classer ce que vous voulez, mais il y a quelques pièges. (Bien que votre réponse est précisément sur UINavigationController, le titre et le concept sont plus grandes, donc je vais aborder les questions plus importantes.)

1. Il peut y avoir des variables dans la classe parente qui sont marqués @private et les classes d'enfants ne peuvent pas accéder, par rapport à la valeur par défaut de @protected, qui sont accessibles.
2. Certaines classes sont conçues pour la sous-classe (et la plupart des classes AppKit et UIKit le sont), mais pour d'autres, c'est extrêmement imprudent. Par exemple, les classes de base clés comme NSString, NSMutableArray, etc. sont en fait des clusters de classe, ce qui signifie qu'une instance de la classe peut en fait être l'une des classes privées.
3. Les classes conçues pour le sous-classement documentent généralement les principales méthodes qui doivent être remplacées. Par exemple, NSDictionary et NSMutableDictionary décrivent quelques méthodes "primitives" auxquelles toutes les autres méthodes appellent, donc le remplacement de 2 ou 3 dans chaque cas est suffisant pour changer le comportement sans ré-implémenter tout le reste.
4. Soyez extrêmement prudent d'appeler l'implémentation de la classe parent de votre méthode substituée si et quand cela est nécessaire. Cela peut être particulièrement important dans les classes d'interface utilisateur, qui ont souvent un comportement plus complexe que les simples classes de données get/set.

Dans ce cas, vous avez tout à fait raison de ne pas écrire la classe à partir de zéro - ce serait une mauvaise idée ™. Si vous souhaitez modifier la valeur par défaut d'un attribut (champ?), Vous pouvez définir la valeur souhaitée dans un initialiseur après en appelant l'initialiseur du parent. Cependant, si vous faites cela, assurez-vous de ne pas arroser quelque chose dans la classe parente, et testez toujours soigneusement.

Apple a réservé des méthodes qui commencent par "_" pour leur propre usage, donc je ferais écho à la prudence de Marc de ne pas les toucher du tout. Tout le reste est juste jeu, dans la raison bien sûr. :-)

Answer 2

Non, n'hésitez pas à devenir fou. De nombreuses classes Cocoa ne sont pas aussi conviviales que les autres (en particulier celles qui sont censées dépendre davantage du contrôle des délégués) et peuvent ne pas exposer les fonctionnalités dont vous avez besoin, mais vous pouvez sous-classer toute méthode qui n'est pas privée (commence par _ préfixe). Vous pourriez même les sous-classer si vous le vouliez vraiment, bien que sur iPhone il y ait des chances qu'Apple rejette votre application.