objective c - tutorial - Objetivo-C: Privado vs Protegido vs Público

objective c vs c++

Question

Espero algunas aclaraciones sobre cómo funciona Privado vs Protegido vs Público con respecto a los miembros de la clase cuando se programa en Objective-C: pensé que sabía la diferencia (he agregado algunos comentarios a mi clase padre Persona con respecto a la misma) , pero el hecho de que el compilador no se quejara cuando intenté acceder a un ivar / miembro privado de una clase padre a través de la subclase ahora me tiene confundido.

Aquí está mi clase para padres:

/*
 Person.h
*/

#import <Foundation/Foundation.h>

@interface Person : NSObject 
{
    //We can also define class members/iVars that are of type private
    //This means they can only be accessed by the member functions
    //of the class defining them and not subclasses
    @private
    int yob;    

    //We can also define class members/iVars that are of type public
    //Public members can be accessed directly
    @public
    bool alive;

    //By default class members/iVars are of type protected
    //This means they can only be accessed by a class''s own
    //member functions and subclasses of the class and typically
    //also by friend functions of the class and the subclass
    //We can explicitly define members to be protected using the
    //@protected keyword

    @protected
    int age;
    float height;   

}
@property int age;
@property float height;
@property int yob;
@property bool alive;

@end

Aquí está mi clase derivada Hombre:

    /*
     Man - Subclass of Person
    */

    #import <Foundation/Foundation.h>
    #import "Person.h"

    @interface Man : Person
    {
        //iVar for Man
        float mWeight;
    }
    @property float mWeight;

    @end

Y finalmente, aquí está el principal:

#import <Foundation/Foundation.h>
#import "Person.h"
#import "Man.h"

    int main (int argc, const char * argv[]) 
        {
            NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

            //Create a Person object
            Person * aPerson = [[Person alloc]init];

            //Create a Man object
            Man * aMan = [[Man alloc]init];

            //Let''s attempt to modify our Person class members
            aPerson.height = 5.11; //Protected
            aPerson.age = 21; //Protected
            aPerson.yob = 2010; //Private
            aPerson.alive = YES; //Public

            //Let''s now attempt to modify the same members via our
            //derived class Man - in theory, the private members should
            //not be accessible by the derived class man
            aMan.height = 6; //Protected
            aMan.age = 26; //Protected
            aMan.yob = 2011; //Private
            aMan.alive = YES; //Public
            aMan.mWeight = 190; //Protected member of Man Class

            [pool drain];
            return 0;
        }

¿No debería el compilador quejarse por qué trato de acceder a aMan.yob arriba? O al usar @property & @synthesize (es decir, los métodos setter y getter), ¿he hecho que ese miembro esté protegido y, por lo tanto, accesible para la subclase?

Answer 1

El truco habitual es crear una extensión de clase dentro del archivo .m y poner allí su propiedad privada / protegida en lugar de en el encabezado.

//Person.m

@interface Person()

@property float height

@end

esto oculta la propiedad ''altura''

Otro truco es si quieres crear una propiedad de solo lectura declararla en el encabezado como

@property(readonly) int myproperty

pero en la extensión de clase como readwrite que le permite a su .m modificar el valor usando el getter / setter

@property(readwrite) int myproperty

Answer 2

Está configurando las visibilidades de los ivars, no las propiedades. Sus propiedades generan métodos public getter y setter.

Para crear propiedades privadas, puede colocar las propiedades en una categoría privada en el archivo .m.

Answer 3

No está accediendo a los miembros: está accediendo a la propiedad en Person que no tiene el nivel de acceso especificado.

Answer 4

la visibilidad no afecta los métodos. los métodos son tan buenos como públicos cuando son visibles para los clientes (y posibles peligros / errores cuando son invisibles para los clientes). en cambio, la visibilidad afecta las variables de instancia. prueba esto:

#import <Foundation/Foundation.h>
#import "Person.h"
#import "Man.h"


    int main (int argc, const char * argv[]) 
        {
            NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

            //Create a Person object
            Person * aPerson = [[Person alloc]init];

            //Create a Man object
            Man * aMan = [[Man alloc]init];


            //Let''s attempt to modify our Person class members
            aPerson->height = 5.11; //Protected
            aPerson->age = 21; //Protected
            aPerson->yob = 2010; //Private
            aPerson->alive = YES; //Public


            //Let''s now attempt to modify the same members via our
            //derived class Man - in theory, the private members should
            //not be accessible by the derived class man
            aMan->height = 6; //Protected
            aMan->age = 26; //Protected
            aMan->yob = 2011; //Private
            aMan->alive = YES; //Public
            aMan->mWeight = 190; //Protected member of Man Class



            [pool drain];
            return 0;
        }

esto impide que las subclases accedan directamente a los ivars, lo que los obliga a ellos y a los clientes a usar los accessors (si se proporcionan).

todo esto es un poco débil porque las categorías permiten a los clientes superar esto.

Además, los programas anteriores objc de 32 bits realmente no verificaron que la visibilidad se haya declarado correctamente. afortunadamente, eso ha quedado obsoleto en 32 y un error en 64.

si realmente desea que algo sea privado para las subclases y categorías, use PIMPL con un tipo no publicado / opaco.

la visibilidad del método (como se encuentra en Java, C ++, etc.) es una característica que usaría en objc.