Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been attempting to learn C#.NET for the past month or so, and the array of ideas that seems to always trip me up is encapsulation. As this is one of the three pillars of OOP, I feel that I am operating at a loss for not understanding their use and implementations more clearly. When learning, though, it is often useful to develop or assimilate mnemonics to assist in maintaining all this knowledge. Having a good reference manual on hand is one thing, but keeping a functioning base of understanding is another entirely.

When keeping track of whether a type/method is public, private, protected, static, or sealed, I find myself wondering what and why all at the same time.

My question, then is how do you go about remembering encapsulation keywords and when to use them? Trial and error is what is working for me now as a student, but I would hope to move beyond that before making professional use of this skill.

share|improve this question
1  
It would be better if we go get a beer so I could explain it to you. –  DavRob60 Apr 15 '11 at 18:47
    
@DavRob60 That's my biggest complaint about book-learning. Something about human interaction just makes swallowing these huge pills easier. –  Nathanus Apr 15 '11 at 18:52
    
And beer help to digest it. –  DavRob60 Apr 15 '11 at 19:07

4 Answers 4

up vote 4 down vote accepted

When I started programming encapsulation was a difficult concept to swallow. Possibly because I focused on working alone rather than in a team. Covering all the modifiers is too much for this forum. So I'll focus on encapsulation, private and public.

While, this is not the only reason to encapsulate...I can illustrate with an example.

Encapsulation really started to make more sense when I started working in a team. When you are working with another developer you want to divide up tasks. Say you are given the task of creating an Email tool. First, you and the dev2 get together and discuss what you will need:

  • An Emailer needs data and functionality to work correctly.
  • data: From, To, Subject, Body, Message, Attachments
  • functionality: Send(), GetSmtpServer()

The task becomes the class or "object". The data becomes properties. The functionality becomes functions.

public class Emailer
    {
      public string From
      public string To
      public string Subject
      public string Body
      public string Message
      public string[] Attachments
      public Email(){}
      public Send()
      {
          //functionality
      }
      private GetSmtpServer()
      {
         //functionality
      }
    }

You may ask, "Why did I make GetSmtpServer() private?"
Because the other developer wants to know how to use Email. He doesn't need to know about all my nitty-gritty details. So, he doesn't need to see GetSmtpServer(). This is why I made it private.

Finally, encapsulation groups similar items together into one unit. This makes your code self-documenting. In other words I can look at class called "Emailer" and have a good idea of what it should do. When I see "Send()" I can guess that will send an email.

On the other hand, if I added a method called "CreateInventory()" to Emailer, it really wouldn't be obvious what this function does. No more details on this, besides that this is abuse of encapsulation and another topic.

share|improve this answer
    
"[E]ncapsulation groups similar items together into one unit." I agree to that, and would like to add (1) that encapsulation, as a technique, is guided by an abstraction; and (2) that it might have been a more logical abstraction to make not one, but three classes: one representing an e-mail message (a piece of data), another for attachments (a different, less specific kind of data), and the last for sending e-mail (a service). –  stakx Jan 1 '12 at 19:36

imagine that Classes are members of family. They have different stuff

  • Public it's something accessible to others, from other families as well

  • Protected it something that belongs to father/mother and only he/she or his/her children can access it

  • Private it is something that belong only to one family members

  • static - it's something common between of fathers or mothers, or children. For instance: How many wifes/husbands can have one man/woman according the law

share|improve this answer

Where to start? It look like you messed up some concept.

First public, private and protected are access modifier, you forgot internal. They specify at which level you could access what you have declared. The idea is to only show want you need to show. but here some guideline for the 3 'p' :

  • Private are for thing you want to keep "secret"
  • Protected is when you want to tell the "secrets" when someone derived from your code
  • Public is your interface.

Static has nothing to do with encapsulation.
sealed forbid Derivation.

The idea of encapsulation is to keep as much secret as you can without breaking feature. Outside a class, you don't need to know how it work. those thing are encapsulated.

share|improve this answer

When designing the class, ask yourself 'What is the bare minimum I want it to do' the most basic thing. Then, ask 'What will it need to do that one thing?' and 'Is the user going to provide those needs, or will the class do it internally?'. If internally, what additional info will it need to do that?

Start building the class with the constructor taking the things it needs, and the verb/function taking additional info for the use case. As you progress in the design, adding more functionality, remember to keep the public interface as simple as possible- minimalistic.

Here is the trick to OOP -- while designing, you will be tempted to say Oh! it would be real easy to enhance this class by doing X right now. Who knows, we might like to have X later on, I might as well do it now since I can see what it takes...

Depending on what it is, that is a temptation you should resist. You have a program to build, and the YAGNI principle comes into play. Do only what you know you need.

Your public interface is your job description, who wants to add unnecessary stuff to their job description?

Once public and private become second nature to you, then you can start pondering the world of protected, where the real fun begins.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.