When using composition, when should we favour wrapper methods? Let's say we have the classic car example.

public class Car {
   private Battery battery;
   //wrapper method
   public void load(float p) {

public class Battery {
   public void load(float percentage) {

The alternative would be to make a getter method that returns the battery so other code would load the battery like this car.getBattery().load(...), but then: should we return the reference or a clone? And what would be more future-proof?

2 Answers 2


Unless you have a really good reason to do otherwise, take the first approach. It's known as the "tell, don't ask" principle.

There are some underlying principles in object-oriented code:

  • You use method calls to tell an object what you want it to do.
  • Objects are responsible for managing their own data.
  • Callers shouldn't need to know about the internal data structures of an object they are calling.

If you allow a caller to fetch a reference to an internal data item, then:

  • The object no longer has control of the data it's supposed to be managing.
  • The caller now knows about the internals of the object it's fetching data from.

For long-term maintainability, the second approach is a mess, as it tightly couples the design of the object to its caller.


The principle of the least knowledge (law of Demeter) should be your friend:

An object a can request a service (call a method) of an object instance b, but object a should not "reach through" object b to access yet another object, c, to request its services. Doing so would mean that object a implicitly requires greater knowledge of object b's internal structure.

a being the caller, b the car, and c the battery, you should stick to your design and let b operate its components. This has the advantage that you could change the internals (e.g. add more batteries) without consequences to the externals.

If instead, you would return the battery, the caller would have to to know that there is one and only one battery and how to operate it. And if you'd add more batteries to the internals, you'd have to change the calling code to cope with the new design.

  • Also a very helpful design principle, thank you
    – Chryfi
    Jul 21, 2022 at 21:36
  • 1
    @Chryfi Thank you. Indeed, the principle of least knowledge dates from 1987 and is about minimising the need-to-know about internals to to reduce change propagation. The "tell don't ask" (2003? 1997?) is meant to encourage a behavior driven design rather than a data-oriented design. If you read about the origin of the tell don't ask and more specially in this foundational article, you will find out that "tell don't ask" builds in fact on the more general law of Demeter ;-)
    – Christophe
    Jul 21, 2022 at 22:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.