Clean Code: Should Objects have public properties?

Question

I\'m reading the book \"Clean Code\" and am struggling with a concept. When discussing Objects and Data Structures, it states the following:

• Objects hide thei

Answer 1

In pure OO "a real object" has to completely hide the data it uses to fulfill its responsibility. So exposing internal data has to be avoided, no matter if this is done by a public field, a public property or public getter/setter functions.

Internal data IS NOR HIDDEN NEITHER ABSTRACTED just by routing access to it through a property!

To answer your question: - Avoid public properties if you are writing an object - Use public propertiers if you are writing data structures (a public field would do the job, too)

Answer 2

Public properties are fine. Not having to write explicit GetHeight() and SetHeight() methods is what properties are all about. A property in C# is not data; it is best viewed as a pair of getter/setter methods. (Properties are actually compiled down into methods in the generated IL.)

The data hiding is possible because you can change the implementation without changing the interface. For example, you could change

public int Height { get; set; }

into

public int Height { get { return m_width; } set { m_width = value; } }

if you decided that your object should always be square. The code using your class would not need any modifications.

So if your object exposes public properties, it still "hides it data behind abstractions and exposes functions that operate on that data", as the book recommends.

Answer 3

Actually by using a Property e.g.

public class Temp
{
   public int SomeValue{get;set;}
   public void SomeMethod()
   {
     ... some work
   }
}

You are hiding its data as there is an implicit variable to store the value set and returned by the SomeValue property.

If you have

public class Temp
{
   private int someValue;
   public int SomeValue
   {
     get{ return this.someValue;}
     set{ this.someValue = value;}
   }
   public void SomeMethod()
   {
     this.someValue++;
   }
}

Then you'll see what I mean. You're hiding the object's data someValue and restricting access to it using the SomeValue proiperty.

Answer 4

Indeed a C# property is not data, is an accessor, so it's a function operating on data.

You should avoid public fields, not public properties.

Answer 5

Here's the deal.

Although public variables may be useful on occasion, it is often best to keep them private.

It's easy to keep your code organized if the object is the only one with control over its variable.

Imagine that you want to maintain a height between 0 and 200. If you have a method to set your height, you can monitor this easily.

For example (I'll be using Java for speed sake):

public void setHeight(int newHeight)
{
    if (newHeight < 0)
        height = 0;
    else if (newHeight > 200)
        height = 200;
    else
        height = newHeight
}

As you can see, this approach is very structured and controlled.

Now imagine that we have a line of code that edits this height externally because you choose to make it public. Unless you control it outside the code, you may get a height that doesn't behave well with your program. Even if you did want to control it, you'd be repeating code.

Very basic example, but I think it gets the point across.

Answer 6

Properties are essentially short hand for Getter and Setter methods. The point of Getter and Setter methods is to have the object handle any operations on variables so that you can do any extra operations (such as data-validation) without causing undesirably consequences.

I think that you may be hung up on automatic properties, which have no backing variables and, as a result, look like variables themselves.