If you've done any programming in other, non-object-oriented languages,
you may already be familiar with the following two situations:
1. You need a function ("method") just to do some number crunching or
housekeeping that is needed only by one tiny part of your code... maybe
only by one other function. You just want to break off a little chunk
of code and either give it a name, or put it in one spot as a function
to avoid duplicating it, because it's called in two or three places.
Nonetheless, what it does is so specific to the part of the code you're
working on that you would never consider it a "general-purpose
function".
2. You're writing a function because you expect it to be used from all
over your system.
The first of these situations is a "private" method; the second is
"public".
"public", "internal", "protected", "internal protected", and "private"
allow you to control who can call your methods (or see your
properties). The more restrictive the modifier you put on your class
member, the fewer other classes can see it, all the way from "public"
(anyone can see it and use it) down to "private" (only the class that
declares and defines the member can see it and use it).
In design there is always tension between wanting to limit scope as
much as possible (make lots of things private), because this makes it
easier to change code without worrying about who else is using it, and
making functionality available to the rest of the program (make lots of
thigns public). As a designer and programmer it's up to you to learn
how to resolve this tension.
Don't worry about "internal", "protected", and "protected internal" for
now. Those come in handy later, when you learn more about assemblies
and inheritance. For now, just use "private" and "public".