2011-03-13 19 views
9

¿Cuál es el enfoque de mejores prácticas para los métodos privados en el objetivo c. Ese es un método que solo se usará como clase de ayuda.objetivo-c métodos privados y públicos y declaración en el encabezado o no?

En particular, lo que no está claro para mí es:

  1. ¿Hay una necesidad de contar con el método especificado en el archivo de cabecera como privada en absoluto? es decir, ¿por qué no lo deja fuera del archivo de cabecera, y
  2. Si se puede dejar fuera del archivo de cabecera, entonces ¿cuál es el punto de tener métodos privados?
  3. O es el caso en Objective-C no hay tal cosa como los métodos privados reales, en cuyo caso es mejor sólo para especificar todo en el archivo de cabecera y no se molesta que marca el privado en absoluto?

gracias

+1

Solo recuerda que no existe el método "privado", en la medida en que no se puede llamar desde otras clases. Ponerlo en una Categoría * ofusca * la existencia del método, pero si su clase implementa un método, responderá a él. –

+0

oh ... vale ... la mayoría de las personas todavía se molestan en tratar de marcarlas como privadas, o simplemente hacerlas públicas y enumerarlas en el *.h archivo junto con los verdaderos métodos públicos – Greg

+0

Si desea presentar a los usuarios una interfaz clara, no debe enumerar los métodos en el encabezado que no desea que utilicen. Sin embargo, si no los declaras en una extensión de clase (ver mi respuesta), perderás todas las sutilezas de la comprobación de sintaxis en tiempo de compilación. La respuesta de Anomie está bien, pero es la forma "C" de hacer las cosas. Las extensiones de clase son la nueva forma de "Objetivo C" de lograr esto. – DougW

Respuesta

7

No hay necesidad de especificar el método en el archivo de cabecera pública. Es posible que desee un archivo de encabezado "privado" para su uso por otras clases en su módulo, si se supone que las clases en su módulo son "amigos". Incluso podría tener un archivo de encabezado "protegido", como lo hace Apple con UIGestureRecognizerSubclass.h, por ejemplo. Sin embargo, todo es simplemente una convención, nada respaldado por el lenguaje en sí.

Un método privado en Objective-C es sólo uno que no está documentado públicamente; aún se puede llamar a cualquier método desde cualquier lugar, siempre que la persona que llama sepa el nombre del mismo para crear el selector apropiado. La ventaja de no documentar públicamente un método es que usted es libre de cambiarlo o eliminarlo sin preocuparse por la compatibilidad con versiones anteriores. Dejarlos fuera del archivo de encabezado es una forma de no documentarlos públicamente.

+1

No hay argumento con su respuesta: es técnicamente correcto. Sin embargo, simplemente se omite una declaración de la antigua forma C de hacer las cosas. Usar una extensión de clase para declarar su método dentro del archivo de implementación es realmente la mejor práctica nueva para administrar esto en el objetivo c 2.0. Solo quiero asegurarme de que las personas que lean esto aprecien eso. Aclamaciones. – DougW

6

Lo que es probable que desee utilizar se llama "Extensiones de clase". Se ven similares, pero no deben confundirse con Categorías. Esto le permitirá declarar métodos privados en su archivo .m, y obtendrá todas las bonitas correcciones y sugerencias de IDE.

Here's a decent article on it
And a related SO question

+0

estos no parecen cubrir la opción de simplemente implementar un método en el archivo "implementation"/*. M y usarlo dentro de - ¿hay algo de malo en hacer esto? – Greg

+0

@Greg: no hay nada más incorrecto con eso que con la definición de una función en C sin declararla en algún lugar primero. Existen las mismas advertencias que el orden WTF en el archivo fuente y demás. – Anomie

+0

@Greg Eso también funcionará, solo date cuenta de que tienes problemas de orden. De todos modos, recibirá una advertencia si la implementación se realiza después de un uso dentro de la fuente, por ejemplo. Use una extensión para casi todo lo interno: facilita el análisis de implementación en un solo paso. – bbum

2

La mejor práctica (y es incluso una opción de compilador para comprobar) es que todos los métodos de ser declaradas de un modo u otro. 'Ocultar' métodos auxiliares de miradas indiscretas, declararlo como tal en el archivo .m aplicación, como en:

#import Client; 

@interface myClass (Private) 
- (void) privateMethod; 
- (float) bankAccountBalanceForClient:(Client *)client; 
@end 

@implementation myClass 
- (void) privateMethod; 
{ 
    //foo here 
} 

y así sucesivamente. los métodos privados son una Categoría llamada Métodos privados de myClass. Esta categoría se puede declarar en cualquier lugar, incluso en un archivo .h principal denominado métodos privados, aunque eso sería una pesadilla de mantenimiento.

Por lo tanto, utilizando el archivo .h público por métodos públicos, y el archivo .m para declarar métodos privados, que tiene todos sus métodos declarados en alguna parte. Utilizo esta opción del compilador para asegurarlo y forzarlo, de modo que cualquier método utilizado sea realmente declarado en alguna parte (o obtengo un error de sintaxis) y, por lo tanto, no recibo ningún fallo en el tiempo de ejecución debido a un método no encontrado.

Cuestiones relacionadas