To try to not write my own treatise, I thought I'd see what Wikipedia has to say:
I think that this sentence from that article expresses my own feelings on the subject just about perfectly:
Not all agree on the distinctions between the two though one can think of information hiding as being the principle and encapsulation being the technique.
So, now let's tackle your specific questions:
is encapsulation only about hiding data
No. It's also about data *safety*. Just for instance, suppose that you have a value that *must* be in the range of 0 through 9, integers only. In most languages, there's no good way to express that limitation (Pascal being a notable exception). So, instead, you do it via encapsulation:
Public Property rating( ) As Integer
Set( r As Integer )
If r < 0 OrElse r > 10 Then
Throw New RatingOutOfRangeException("Rating " & r & " is invalid")
mRating = rating
Also, No. It's about hiding of *implementation*. If the class wants to derive a "property" from various internal elements without disclosing how the elements are connected.
Public Property price() As Double
Return 100.0 + 200.0 * RND() ' random price from 100 to 300 dollars
You say you have a boolean data member of your class and it's fine for it to be either True or False and you don't care which? So why make it a property? Why not just make it a public data member?
Realistically, no good reason not to. Though certain OO purists would shoot me for saying so. <shrug>Let them.</shrug>
and is that the only reason why we use objects?
Oh, my goodness no! In fact, nobody even said you HAVE to use properties! You could just as easily use standard *METHODS* and forget all about properties, per se. (Though many would argue that I'm just changing the implementation; the hidden data is still the key to it all. Hard to say they are wrong.)
No, in my own mind, the strongest reason to use classes (objects) is Polymorphism. A completely different *KIND* of "hiding". The ability to hide the fact that two objects are COMPLETELY DIFFERENT under the covers and yet, from certain points of view, have all the same capabilities (including properties).
Don't get me wrong, there are tons of other reasons to use objects. Just the ability to have data and code tightly coupled is almost enough, alone, to make me want to use them. In non-OO languages, there's no easy way to say "this price value is associated with that invoice item" or "the profit on this item is ITS OWN price minus ITS OWN cost." That is, the data is grouped, the code is grouped, it's all a single unit.
Don't get all hung up on properties. As Wikipedia said, they are only *ONE* technique used in OO programming.
Also is the only reason why classes have properties is for data access?
First of all, remember that any public data member of a class *IS* a property of that class! (Technically, even the private ones are class properties; they just aren't accessible outside the class.)
So are you using the term "properties" here to mean *all* properties or only encapsulated properties??
Not that it matters, in the end.
Given that a property--either data member or a method encapsulating a property--either accepts or returns a data value, what else COULD they be used for? You can shove data in. You can pull data out.
But, to be fair, there's no reason that the implementation of an encapsulated property can't have "side effects". Just as a for instance, maybe the 137th time you ask for the score of a given football game, where the game is implemented as an object, the method sends an email to your boss telling him you are only playing games. Rotten OO design, no doubt, but perfectly legal.
So "only reason" may be too strong, but "general reason" would certainly be true.
I see that Imar has also answered you. I should have refreshed the page before posting. Still, you'll note that we both say pretty much the same thing.
My gut feeling is that you are concentrating on unimportant parts of OO programming. Oh, not that they don't have important uses and reasons for being and and and... But I think that understanding the makeup of classes, the whole reason for using them in the first place, is where you need to start.
I'm not sure what to point you at. My own learning experience began 17 or 18 years ago with a copy of the original C++ book from Stroustrup. His attitude was pretty much "well, if you don't see the point of doing OO programming, then why should I tell you?" So it's pretty much been a bunch of self-teaching from there.
Wait until you discover generic classes ("templated classes" in C++). They first appeared after I started learning C++. In my never as humble as it should be opinion, *THEY* are what makes a given OO language viable in the market. When VB
.NET and C# appeared without them, I wasn't convinced they would matter in the long run. Thankfully, we now have generics, and reasonbly well implemented, to boot. Generics and polymorphism. And go rule the world.