Prefijo de clase Objective-C

Question

¿Cuál es su preferencia al nombrar clases ObjC? No estoy seguro de cuál sería el enfoque más razonable sobre esto, así que sería bueno escuchar algunas otras opiniones.

Apple recomienda el prefijo de las clases de cacao, porque ObjC no admite espacios de nombres. La guía de estilo de Google ObjC (que principalmente intento) elimina, a menos que amplíe (categoría, extensión de clase, etc.) una NSClass.

Mi preferencia sería NO prefijar clases, porque también creo que es un desperdicio de letras y no contribuye a una causa. Solo se debe usar en el código de framework para indicar que esta clase pertenece a él y no a las clases de su aplicación, pero no lo usaría en el nivel de la aplicación.

¿Cuál es el tuyo y, sobre todo, POR QUÉ?

Mi conclusión (no dude en añadir sus comentarios al producir la decisión más informada) Las clases de nivel

---

de aplicación:

• decidí ir con 1 Prefijos de letras (como CMyClass). Las principales razones son para fines de organización de archivos (por ejemplo, una mejor agrupación en Finder) y aún utiliza menos letras de nombre de clase que prefijos con una longitud de 2 o más.
  • utilizar el prefijo 'C' para las clases de cacao (por ejemplo CAudioController.h)
  • utilizar el prefijo 'U' para las colecciones de servicios públicos (normal C, por ejemplo USystemAudio.h)

Clases de nivel de marco:

• Clases de prefijo con 2 o más letras personalizadas, preferiblemente únicas, ya que probablemente se compartirán con otras aplicaciones.

Categorías

• Las categorías se denominan de la siguiente: NSClassName+ExtensionPurpose

Answer 1

Mi enfoque general es prefijar los nombres de clase que forman parte de un marco o paquete cargable, es decir, clases que pueden compartirse entre varias aplicaciones y con otros marcos, pero no molestar con clases que aparecen como parte de una aplicación independiente.

Si Steve Jobs me concediera un deseo, sería tener espacios de nombre en Objective-C 3.0 (que estaría disponible mañana).

Answer 2

que sin duda debe anteponer ellos. si hay una colisión, el comportamiento no está definido.

lo que realmente sucede (la última vez que me encontré con esto) es que el binario está cargado, pero su clase no se carga si ya se ha cargado otra clase (objc) con ese nombre. te dejaré averiguar qué implementación obtendrás cuando crees una instancia de esta clase;) dicha colisión probablemente resultará en un bloqueo o en una gran cantidad de excepciones anuladas (y una aplicación no funcional). muchos desarrolladores usan 2 letras mayúsculas, lo que significa que (en igualdad de circunstancias) 26 * 26 es probable que usen el mismo prefijo. de nuevo, esto me ha pasado tan bien ... es mejor que lo hagas para evitar volver a escribir mucho código más adelante.

Answer 3

Hay una muy buena guía por Scott Stevenson sobre cómo debería ser el código objetivo-C. Consulte los siguientes enlaces.

http://cocoadevcentral.com/articles/000082.php
http://cocoadevcentral.com/articles/000083.php

Estos enlaces también responder a su pregunta cómo se debe asignar nombres a las clases y por qué.

Answer 4

Uso un prefijo, incluso en el código de la aplicación que no se va a compartir, en su mayoría consistentemente. Generalmente utilizo una abreviatura de 2 letras para la aplicación o el nombre del framework en el que se originó el código, a menos que un prefijo diferente (por ejemplo, 3 letras o una breve palabra descriptiva) tenga más sentido.