CODEWITHSUNDEEP
oopclassencapsulation
John Smith
John Smith

Reputation: 12266

Public vs. Private?

I don't really understand why it's generally good practice to make member variables and member functions private.

Is it for the sake of preventing people from screwing with things/more of an organizational tool?

Upvotes: 5

Views: 1111

Answers (7)

Chester
Chester

Reputation: 1

It is useful to know how an object s 'put together' have a look at this video on YouTube

http://www.youtube.com/watch?v=RcZAkBVNYTA&list=PL3FEE93A664B3B2E7&index=11&feature=plpp_video

Upvotes: 0

paxdiablo
paxdiablo

Reputation: 882716

Basically, yes, it's to prevent people from screwing with things.

Encapsulation (information hiding) is the term you're looking for.

By only publishing the bare minimum of information to the outside world, you're free to change the internals as much as you want.

For example, let's say you implement your phone book as an array of entries and don't hide that fact.

Someone then comes along and writes code which searches or manipulates your array without going through your "normal" interface. That means that, when you want to start using a linked list or some other more efficient data structure, their code will break, because it's used that information.

And that's your fault for publishing that information, not theirs for using it :-)

Classic examples are the setters and getters. You might think that you could just expose the temperature variable itself in a class so that a user could just do:

Location here = new Location();
int currTemp = here.temp;

But, what if you wanted to later have it actually web-scrape information from the Bureau of Meteorology whenever you asked for the temperature. If you'd encapsulated the information in the first place, the caller would just be doing:

int currTemp = here.getTemp();

and you could change the implementation of that method as much as you want. The only thing you have to preserve is the API (function name, arguments, return type and so on).

Interestingly, it's not just in code. Certain large companies will pepper their documentation with phrases like:

This technical information is for instructional purposes only and may change in future releases.

That allows them to deliver what the customer wants (the extra information) but doesn't lock them in to supporting it for all eternity.

Upvotes: 19

Joseph Caruana
Joseph Caruana

Reputation: 2271

There is a scope for a lot of debate on this. For example ... If a lot of .Net Framework was private, then this would prevent developers from screwing things up but at the same time it prevents devs from using the funcionality.

In my personal opinion, I would give preference to making methods public. But I would suggest to make use of the Facade pattern. In simple terms, you have a class that encapsulates complex functionality. For example, in the .net framework, the WebClient is a Facade that hides the complex http request/response logic.

Also ... Keep classes simple ... and you should have few public methods. That is a better abstraction than having large classes with lots of private methods

Upvotes: 0

mindandmedia
mindandmedia

Reputation: 6825

take the typical example of a counter. the thing the bodyguard at your night club is holding in his hands to make his punch harder and to count the people entering and leaving the club.

now the thing is defined like this:

public class Counter{
   private int count = 0;
   public void increment()
   { 
      count++;
   }
   public void decrement()
   { 
      count--;
   }
}

As you can see, there are no setters/getters for count, because we don't want users (programmers) of this class, to be able to call myCounter.setCount(100), or even worse myCounter.Count -= 10; because that's not what this thing does, it goes up one for everyone entering and down for everyone leaving.

Upvotes: 1

Clockwork-Muse
Clockwork-Muse

Reputation: 13106

It's to prevent people from screwing with things - but not from a security perspective.

Instead, it's intended to allow users of your class to only care about the public sections, leaving you (the author) free to modify the implementation (private) without worrying about breaking someone else's code.

For instance, most programming languages seem to store Strings as a char[] (an array of characters). If for some reason it was discovered that a linked list of nodes (each containing a single character) performed better, the internal implementation using the array could be switched, without (theoretically) breaking any code using the String class.

Upvotes: 3

Kerrek SB
Kerrek SB

Reputation: 477640

The main reason is that you, the library developer, have insurance that nobody will be using parts of your code that you don't want to have to maintain.

Every public piece of your code can, and inevitably will get used by your customers. If you later discover that your design was actually terrible, and that version 2.0 should be written much better, then you realise that your paying customers actually want you to preserve all existing functionality, and you're locked in to maintaining backwards compatibility at the price of making better software.

By making as much of your code as possible private, you are unreservedly declaring that this code is nobody's business and that you can and will be able to rewrite it at any time.

Upvotes: 8

Eric J.
Eric J.

Reputation: 150228

It's to present a clear code contract to anyone (you, someone else) who is using your object... separate "how to use it" from "how it works". This is known as Encapsulation.

On a side note, at least on .NET (probably on other platforms as well), it's not very hard for someone who really wants access to get to private portions of an object (in .NET, using reflection).

Upvotes: 2

Related Questions