There are good reasons for the whole using methods/member functions to set/get the values of an object but its not really explained properly or the reasons for them at all and people just think they should be adding get/setters for all attributes just because its OO or something. There are two reasons for setters/getters. One is an object has a state and performs actions, when you design a new type you think about what attributes this type has and the valid range of values these attributes can have, this is called the state invariant, your setters maintain the state invariant keeping the object in a valid state for example think about the type integer it has a state invariant which (depending on platform) is
between -2147483648 to +2147483647. The operations such as assignment which is like a setter maintain this state, never puts it above or below which would be illegal.

I got a better example, lets design a new type called "ByteBuffer" which is just a container of byte values you can fill regions in for buffering. The attributes i think this type has are:

byte buffer[]
int capacity,
int limit,
int position,
int mark;

the state invariant for this type is:

Invariants: mark <= position <= limit <= capacity

The only way i can maintain this state invariant is through the operations i give this type, thats why your told its best to make attributes private because if it wasn''t it would be easy to put the object of that type in an invalid state
and may cause undefined behaviour. So lets give it an operation that shows an example of maintaining a valid state call it "get" which is just a getter:

public byte get(int index) throws out_of_range {
if ((index < 0) || index >= _limit){
throw new out_of_range("Index out of bounds");
}
return buffer[index];
}

So there you go, the object will never be in an invalid state and not cause undefined/unexpected behaviour and makes finding bugs easier to find.

The other reason for making attributes private is do with module coupling, some types can have more than one data representation, at some point you may decide to change its representation and if you allowed direct access to it in other modules you''ll have to update everything to reflect this change, imagine if another team was using your module bad news this is known as "tight coupling".

Well this is where "Abstract Data Types" ADTs come in, you design a new type by describing its operations regardless of what data representation to use thus creating an "interface" between that new type and other modules using it that almost never changes. You can always change its data representation and you''ll almost never need to update everything else your creating a "loose coupling" which is good. The best example of that is java''s List type, its an interface has no data representation it only describes it operations which is the only thing you need to be concerned about, people passing around List could use arrays, single/double link list to represent it but thats no concern of anyone.

The thing about the keyword static in all languages have different meanings depending on there context, like in C i think when you declare a function prototype static it just means it becomes private in that module scope you can''t use in another file, when you declare a variable static in a function defination it persists through out all invocations, in C++ its used for other meanings aswell. In java when you flag a class attributes/methods static you do not need to create an instance of that class to use it but if you want to use a non static method inside a static one there needs to be a instance of that class in there to use that operation.

I hope that makes abit more sense i''m not very good at explaining things well.