How do you remember encapsulation types for effective use?

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.