Whats the point in field encapsulation

Just working on an experimental bmax/c# project im playing with and i wondered whats the point in field encapsulation versus public assignment?

http://en.wikipedia.org/wiki/Encapsulate_Field

See advantages/disadvantages.

:-)

-"Additional overhead for subroutine"
Right-o public assignments it is.

Thx ;)

Missed the bit about that overhead being largely irrelevant on real computers and/or proper compilers did we?

One absolutely positive advantage is that making an accessor/mutator method threadsafe is generally speaking fairly easy, while doing the same for a public field can be an exercise in frustration. Whether this applies to you depends largely on necessity.

It's probably worth testing on BMax to see which is fastest though, especially for something like a particle where you want to set the x y coords say and you have 1000 of them...

I don't encapsulate as I "assumed" it was faster, and I also find it simple (yes I know SetBlah(x) is simple too.) However as soon as I add a second command (or more) then I always try to encapsulate.

You also keep a field private if you don't want it to be inherited.

Sometimes controlling data integrity is more important than a little extra speed.

Someone who doesn't really understand how useful good OO can be is likely to skip right over the "advantages". (actually, the topic title speaks for itself really)
As mentioned, it obviously depends what you are intending for the data.

Since BlitzMax is a procedural gaming language, there won't be much call for good OO design :-)

Its not a web project or anything like that, what i have done is write an irrlicht.net wrapper for mono/C# that has a familiarity with B3D.

eg:

Vector3D dest = new Vector3D((float)x,(float)y,(float)z);
Matrix4 mat= node.RelativeTransformation;
mat.TransformVect(ref dest);
node.Position=dest;

becomes just:

myentity.move(x,y,z)

likewise: myentity.color(r,g,b), myimage.draw(x,y), myentity.free() etc etc etc....

I am more interested in speed as the data is not really top secret or anything. I was just wondering if encapsulating all publics in my 'entity' and 'image' and 'sound' classes was worth it and why.

> I was just wondering if encapsulating all publics in my 'entity' and 'image' and 'sound' classes was worth it and why.

in VB you can always go back and encapsulate them later without needing to change any other code to do so, I'm pretty sure C# is the same. I often start out with many fields being public variables and then making them private with get and set added later on.

As soon as you get a variable that you wished could not be set till X happens - then you have found a good first use for get and set routines...

It's basically to avoid debugging sessions. If the range of a value needs restricted you can encapsulate it in methods.

Really its about writing cleaner, more robust software. By using properties, you can keep a syntax that looks to your users just like they're working with fields.

But internally you can change things later. For instance add safety checks transparently, or totally rewrite the implementation. They are also more flexible.

They are easy to abuse though. The syntax just screams at you that its going to be a simple variable access. But if you access SomeObject.X, you have no idea whether its really just accessing a field, or instead calling multiple expensive functions.

I've been burnt by that a few times.

In .NET( and I presume any compiler/runtime worth its salt ), stuff like simple properties should get inlined away anyways. But even so, the codegen may be different for simple properties vs fields...but thats really in the realm of micro optimization :)

Here's some very relevant( pertaining to gamedev ) c# stuff to chew on.
http://blogs.msdn.com/ricom/archive/2006/08/31/733887.aspx

Bit late this but it answers your question well.
http://en.wikipedia.org/wiki/C%2B%2B_(programming_language)#Objects