-7

So I was told the other day that using public in c# is bad, so say I create a new class and inside that class I have a method, why is it better to declare it as 

private void nameOfMethod()

rather than

public void nameOfMethod()

I'm just curious and cant seem to find an answer anywhere, was the person that told me not to use public wrong? Any help would be appreciated

EDIT I understand the difference between public private and protected perfectly fine, i just want to know why i was told it was better to avoid public

Reece Hewitson
  • 91
  • 1
  • 10
  • 6
    It's not bad, it's just situational. if you write a class in the namespace `MyNamespace` and it's private, it cannot be accessed by namespace `MyNamespace2`, as such to access it, you'll want to make it public – Alfie Goodacre Dec 14 '16 at 16:04
  • 3
    Exact dup. http://stackoverflow.com/questions/614818/what-is-the-difference-between-public-private-protected-and-nothing – TheValyreanGroup Dec 14 '16 at 16:05
  • If a method is going to be called from a class in another assembly then it **must** be public. If it's only going to be called from within the current class then it **should** be private. – stuartd Dec 14 '16 at 16:05
  • I was told that you should use private whenever possible? not that you absolutely shouldn't use public just that it is better to use private – Reece Hewitson Dec 14 '16 at 16:06
  • 2
    They must have been talking about declaring public fields, not methods. Declaring public fields is universally bad, except when declaring public constants. – Sergey Kalinichenko Dec 14 '16 at 16:06
  • 1
    If you can make method private - do it. If you absolutely cannot (because it's method is used by another class) - then make it protected\internal\public. It's basically as simple as that. – Evk Dec 14 '16 at 16:10
  • 1
    A good term for additional research is *encapsulation*. – BJ Myers Dec 14 '16 at 16:10
  • okay, so why is it bad to declare fields as public? that is possibly what they said – Reece Hewitson Dec 14 '16 at 16:10
  • 2
    @TheValyreanGroup Disagree with that dup target. The linked answers describe the difference between them, but give no rationale for when one should be preferred. – BJ Myers Dec 14 '16 at 16:11
  • 1
    @ReeceHewitson see e.g. http://stackoverflow.com/questions/480627/why-wont-anyone-accept-public-fields-in-c , http://softwareengineering.stackexchange.com/questions/120497/why-are-public-and-private-accessors-considered-good-practice – stuartd Dec 14 '16 at 16:13
  • Are you asking about of methods or fields? Second link of @stuartd, comment is a good one: you should generally avoid having public fields (unless it's `readonly` one). Point is, to make something available from outside (that's what `public` does) - use property. Property gives you full control over what caller can do, while field doesn't. In public setter you can validate changes and refuse (`throw`), while in methods of the type you can set value of backing `private` or `protected` field directly. As for getter, compiler *may* optimize fields access, causing you troubles with cycles. – Sinatr Dec 14 '16 at 16:37

2 Answers2

6

The use of public vs. private refers to one of the key concepts of object oriented programming: Encapsulation or information hiding.

Encapsulation means that the internal representation of an object is generally hidden from view outside of the object’s definition. Typically, only the object’s own methods can directly inspect or manipulate its fields.

Hiding the internals of the object protects its integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state. A supposed benefit of encapsulation is that it can reduce system complexity, and thus increase robustness, by allowing the developer to limit the inter-dependencies between software components (see Encapsulation on Wikipedia).

In general, you make a method or property public, if it is intended to be used outside of the object, and private, if only is required by your object internally.

Dirk Vollmar
  • 172,527
  • 53
  • 255
  • 316
  • i already know that public is for use external of the class and private is internal, i was just wanting an explanation as to why ive been told public should only be used if absolutely necessary – Reece Hewitson Dec 14 '16 at 16:14
  • @ReeceHewitson: Using public/private to enforce encapsulation is good because it will give you a clean design with reduced complexity and dependencies and increased robustness and maintainability. As an introduction, also have a look at the Wikipedia article on [information hiding](https://en.wikipedia.org/wiki/Information_hiding). – Dirk Vollmar Dec 14 '16 at 16:17
  • 4
    @ReeceHewitson The idea the person may have been attempting to communicate is that you should only expose (make something public) that is intended to be used by other actors in the system. They may be attempting to help you write code that only has one responsibility. A class with 5 public methods is a good candidate to consider for having too many responsibilities. Classes with fewer responsibilities tend* to be more modular and pluggable into places in the system. – davidallyoung Dec 14 '16 at 16:19
  • Okay i see, so it basically just encourages encapsulation which is good practice? – Reece Hewitson Dec 14 '16 at 16:24
2

In general, it's a good idea to make types public only if they need to be public. The assumption for consumers of that assembly is that all public types contained within it are fair game to use. If you do not want consumers of the assembly to use a given type, make sure it is not public. By making it public, you're implicitly allowing consumers of the assembly to make use of the type and there's a general expectation that you support such a type and not make breaking changes to it without appropriate documentation.

Matt Thalman
  • 3,540
  • 17
  • 26