Groups | Search | Server Info | Login | Register

Groups > comp.lang.objective-c > #251

Re: A basic question on private/public variables and data encapsulation

Show all headers | View raw

Hi. Before I begin my rant, I would like to clarify some common misconceptions about information hiding.
First, it is not actually hiding anything. It is a design concept in computer science that is about back-end/front-end and api presentation, and the idea that an object carries with it data and methods of manipulating its data along with it.
Second, it has never been a security feature, it is an organization strategy.
So throw out any ideas you may have picked up about safety of security of data based on @public @protected and @private in Objc. They aren't there.
They are "hints" to the compiler at compile-time that accesses are occurring from outside the class but not errors. 
Any variable or method in the class implementation is available to be run or accessed directly during runtime. If it is not "advertised" in the .h file as part of the API then the idea is ordinary users of the class in programmming will avoid accessing it and probably will not know it is available. The protection aspect is the class designer just doesn't want people fooling around with some variable or using some method that should be internal to the class, but if you know about it you can access it, even if you get a warning from the compiler. Traditionally ObjC is very lax about letting programmers off with warnings.
If you ship a set of libraries with .h files, compiled library files, and no .m files you can see that "unadvertised" methods not in the header files will probably not get used by consumers (programmers using your library to program with). If you ship full source, they can look at it and it is all open to them to use if they want.
In some languages information hiding is enforced, and it is an error to access private variables by outside classes, but in ObjC it is just a warning. The warning is valid, however, in that you are probably doing it wrong if you have to run internal methods or bypass getter/setters to manipulate class data.
@public
@protected
@private
are hints for you the designer of the class to make your api appropriately for 
the consumer of the class.
We want to avoid stuff like this:

 struct 
{ int a; char* c; } 
x_struct;


@interface class A 
{
@private
 x_struct x;
}

then somewhere you write:
 xs->x.a = 42;  // direct access
 xs->x.c = "a string"; 
 char* mystr = xs->x.c;

This is all perfectly valid C and will compile and run and may even be what you
want, but it is a dangerous operation and can have all kinds of unintended consequences especially becuase it circumvents any data cleaning or verification before setting values that may destroy the class or lead to creating garbage data or even crashes. When this look like the way to go you know you have gone off the rails and need to redesign your interfaces or go through the task of writing some coherent accessor/setter code.
Objects produce, consume, and manipulate data and take up memory space to do so, so violating that memory space from without the class can cause damage to data and the system especially if pointers are involved. 
Direct assignment of pointers from outside of the class to inside of the class is the worst form of violation of information hiding and is a major reason
object oriented programming exists. Don't do that.
@interface class A
{
@public
 SomeClass * sc;
}

A->sc =  [SomeClass new]; // OK inside internal A method , not anywhere else, though. 
Trouble is this seem reasonable when inside of A.h but carries no protection at runtime that the running program will assign A.sc a good SomeClass object.
So a setter should be written for setting A.sc , preferrably one that validates it before assigning the pointer to the object.

The rub comes when the API provided is complicated and feels cumbersome like the old Foundation Classes or the 
inputstream->input-filter->input->reader->input-validator->input->consumer>input-data 
==> data-processing ==> 
output-data>output->writer>output-filter>outputstream 
paradigm is used. 
Seems shockingly bulky and inefficient, and takes a lot of coding time and debugging. It seems so much easier to just set a variable or assign a pointer. It is, but it is also a good way to crash programs, and write unmaintainable, hard to modify code, and to leak data or expose it to modification by accident.

Hey though, if you want transparency in your class you can do that. 
But You can not make a real private instance variable. 
it's always possible to access any variable (even @private ones). It may seem
like it from the documentation but that is just assuming good practices on your
part. 
The question then becomes: When should you violate information hiding?
Ah. Well. You can have up to one lifetime to figure that one out. 

Back to comp.lang.objective-c | Previous | Next — Previous in thread | Find similar

Thread

A basic question on private/public variables and data encapsulation Jon Rossen <jonr17@comcast.net> - 2016-01-30 17:01 -0800
  Re: A basic question on private/public variables and data encapsulation Louis Wu <louiswu@ringworld.net> - 2016-01-30 21:09 -0800
  Re: A basic question on private/public variables and data encapsulation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-31 15:37 +0000
  Re: A basic question on private/public variables and data encapsulation spikeysnack <spikeysnack@gmail.com> - 2016-01-31 14:18 -0800

csiph-web