By adding the methods "string get_Name()" and "void set_Name(string name)" you are making _exactly_ the same contract as if you have "public string Name".
There is no extra dependency here - the dependencies are identical.
By adding the methods "string get_Name()" and "void set_Name(string name)" you are making _exactly_ the same contract as if you have "public string Name".
There is no extra dependency here - the dependencies are identical.
Suppose you need a stapler for some work. You don't have one, but you know a colleague who does and who is willing to happily share it with you. You could go to her office, open the second drawer in her desk, take the stapler and leave. Or you could just ask her to give it to you. In both case the result is the same: you will get the stapler.
But there is a major difference : in the first case, you had to know where the stapler was. Your colleague knows it - it's her desk, after all - but because you decide to ignore the service she can provide and do it yourself, you have to know it as well. That means that you are both dependent of the manner of accessing the stapler.
What if someday she decides to move the stapler into the third drawer ? Because of this dependency, you would have to be informed of this change and start behaving accordingly. Your implementation would be impacted by a change in her implementation. And this is bad.
On the contrary, if you just asked her to give you the stapler, it wouldn't matter at all where it's stored. As the owner of this item she would the sole responsible for its location, and your behavior would never be impacted.
This is the purpose of encapsulation: preventing objects implementations from being impacted by changes in other objets implementations. You should be applying this everywhere, every times. Even for such small services as "give me that value, please". In your example, you should not need to know if a field or anything else is used to store the value because it's an implementation concern. You should just ask the value to the object.
OOP works much better in teams and is a bit/lot of overhead when you are making contracts with yourself.
However if I'm working with someone and they tell me call this to get a name then ill do that, if later they realize they need to split out the name into first and last I can still use that old function to get the full name by them combining the strings and returning that in that old "getter".
PS that might be a very poor example, hopefully you get my point :)
(And that's where C#'s way of dealing with getters and setters is a big win, because they look like member variables, so there's no extra kludginess.)