java - another - How would you access Object properties from within an object method?

object within object java (12)

What is the "purist" or "correct" way to access an object's properties from within an object method that is not a getter/setter method?

I know that from outside of the object you should use a getter/setter, but from within would you just do:


String property =;


$property = $this->property;

or would you do:


String property = this.getProperty();


$property = $this->getProperty();

Forgive me if my Java is a little off, it's been a year since I programmed in Java...


It seems people are assuming I am talking about private or protected variables/properties only. When I learned OO I was taught to use getters/setters for every single property even if it was public (and actually I was told never to make any variable/property public). So, I may be starting off from a false assumption from the get go. It appears that people answering this question are maybe saying that you should have public properties and that those don't need getters and setters, which goes against what I was taught, and what I was talking about, although maybe that needs to be discussed as well. That's probably a good topic for a different question though...

Am I just going overboard here?

Perhaps ;)

Another approach would be to utilize a private/protected method to actually do the getting (caching/db/etc), and a public wrapper for it that increments the count:


public function getName() {
    return $this->_getName();

protected function _getName() {
    return $this->name;

and then from within the object itself:


$name = $this->_getName();

This way you can still use that first argument for something else (like sending a flag for whether or not to used cached data here perhaps).

As stated in some of the comments: Sometimes you should, sometimes you shouldn't. The great part about private variables is that you are able to see all the places they are used when you change something. If your getter/setter does something you need, use it. If it doesn't matter you decide.

The opposite case could be made that if you use the getter/setter and somebody changes the getter/setter they have to analyze all the places the getter and setter is used internally to see if it messes something up.

I like the answer by cmcculloh , but it seems like the most correct is the answer by Greg Hurlman . Use getter/setters all the time if you started using them from the getgo and/or are used to working with them.

As an aside, I personally find that using getter/setters makes the code easier to read and to debug later on.

I must be missing the point here, why would you use a getter inside an object to access a property of that object?

Taking this to its conclusion the getter should call a getter, which should call a getter.

So I'd say inside an object method access a property directly, especially seeing as calling another method in that object (which will just access the property directly anyway then return it) is just a pointless, wasteful exercise (or have I misunderstood the question).

If I won't edit the property I'll use a get_property() public method unless it's a special occasion such as a MySQLi object inside another object in which case I'll just public the property and refer to it as $obj->object_property .

Inside the object it's always $this->property for me.

If by "purist" you mean "most encapsulation", then I typically declare all my fields as private and then use this.field from within the class itself, but all other classes, including subclasses, access instance state using the getters.

It depends. It's more a style issue than anything else, and there is no hard rule.

PHP offers a myriad of ways to handle this, including magic methods __get and __set , but I prefer explicit getters and setters. Here's why:

  1. Validation can be placed in setters (and getters for that matter)
  2. Intellisense works with explicit methods
  3. No question whether a property is read only, write only or read-write
  4. Retrieving virtual properties (ie, calculated values) looks the same as regular properties
  5. You can easily set an object property that is never actually defined anywhere, which then goes undocumented

Private fields with public or protected properties. Access to the values should go through the properties, and be copied to a local variable if they will be used more than once in a method. If and ONLY if you have the rest of your application so totally tweaked, rocked out, and otherwise optimized to where accessing values by going through their assosciated properties has become a bottleneck (And that will never EVER happen, I guarantee) should you even begin to consider letting anything other than the properties touch their backing variables directly.

.NET developers can use automatic properties to enforce this since you can't even see the backing variables at design time.

The purist OO way is to avoid both and follow the Law of Demeter by using the Tell Don't Ask approach.

Instead of getting the value of the object's property, which tightly couples the two class, use the object as a parameter e.g.

  doSomethingWithProperty() {
     doSomethingWith( ) ;

Where the property was a native type, e.g. int, use an access method, name it for problem domain not the programming domain.

  doSomethingWithProperty( this.daysPerWeek() ) ;

These will allow you to maintain encapsulation and any post-conditions or dependent invariants. You can also use the setter method to maintain any pre-conditions or dependent invariants, however don't fall into the trap of naming them setters, go back to the Hollywood Principle for naming when using the idiom.

Well, it seems with C# 3.0 properties' default implementation, the decision is taken for you; you HAVE to set the property using the (possibly private) property setter.

I personally only use the private member-behind when not doing so would cause the object to fall in an less than desirable state, such as when initializing or when caching/lazy loading is involved.

i would say its better to use the accessor methods even within the object. Here are the points that come to my mind immediately:

1) It should be done in the interest of maintaining consistency with accesses made outside the object.

2) In some cases, these accessor methods could be doing more than just accessing the field; they could be doing some additional processing (its rare though). If this is the case, by accessing the field directly you would missing out that additional processing and your program could go awry if this processing is always to be done during those accesses