Object oriented programming and object composition, how to put the composition properties?

Question

This is a question I always had, but now is the time to solve it:

I'm trying to implement the composition of objects using public attributes like:

Person {
 public Car car;
}

Owner {
  public Person person;
  public Car car;
}

Car {
  public Person person;
}

Really my question is: Is a good practice to set that composition properties public or private?

The difference:

a) Public: doing public, the access is fast and not complicated, because I only need to reference the property directly with the instance like:

$instancePerson.car.getNumberOfGearsGood()

The problem: the car propertie is available to be modified by anybody from anywhere.

b) Private: doing private, the access if slow and is necessary to use methods to get these properties like:

$instancePerson.getCar().getNumberOfGearsGood()

When I say slow is because you need to do a method two method call, while in the Public solution only you need to do one.

I know many developers and software engineers here will prefer Private solution, but can you explain the performance there?

Answer 1

the short answer is that, except for very few cases, you want those variables to be private, and often technologies in the JVM will make access faster than you think it would be (and sometimes even faster than in C/C++).
For a bit more detailed answer:

The main question is: who should be able to modify those variables? for example, you may want Car to be created passing a Person to its constructor, and never allow the person to change (in a world where there is no market for used vehicles). In this case, if the field is public another object can modify it and change the owner of the car. But if you make the field private, and provide a getOwner() method, nobody can modify it. If the get method is final, and therefore can't be overridden in a subclass, the JVM might even transform internally any invocation of x.getOwner() in the equivalent of x.owner. In your example however it's not possible to pass all elements in the constructor, as they reference each other. In fact, it seems to me your model has one too many classes. Let's try to write it a bit differently:

Person {
 public Car car;
}

Car {
  public Person owner;
}

Now, with assuming that every car has an owner, and every person own a car, this model is dangerous, because you could do something like this:

Person p = new Person()
Car c = new Car();
p.car = c;

As you can see, I forgot to set c.owner = p.

Let's see how we can fix this:

Person {
  private Car car;
  public void setCar(Car c) {
    if (car == c) 
      return;
    car = c;
    c.setOwner(this);
  }
}

Car {
  private Person owner;
  public void setOwner(Person o) {
    if (o == owner)
      return;
    owner = o;
    o.setCar(this);
  }
}

I can now do :

Person p = new Person();
Car c = new Car();
p.setCar(c);

or

Person p = new Person();
Car c = new Car();
c.setOwner(p);

and either way both relationship will be set correctly.

In other words, being forced to go through accessors allows to set more than just a simple field, which is useful to establish coherent state across model elements involved in a relationship.

Answer 2

If you are doing OO, there should be no such thing as a "public" attribute. All the attributes are implementation details of the object, therefore are hidden from everybody. Only the methods associated with the object's responsibility are public.

So to answer the question:

• All "attributes" should be private
• And there should be no getter on a private attribute

Yes, there should be no

person.getCar().getNumberOfGears();

This is sometimes called the Law of Demeter. The person should have methods that do stuff connected to the responsibility of the Person class, therefore there is no performance penalty accessing attributes, because this access is always internal to the class and direct.