Computed Properties or Setter/Getter methods what are the advantages of each over the other?

I have been using Setter/Getter methods to make my classes compatible with iOS, but that is going away so time to rethink. The reason for setter/getter is that I could have 2 setters for a string property - assigning either text or string to the member property.

What are your thoughts?

[quote=451414:@Wayne Golding]I have been using Setter/Getter methods to make my classes compatible with iOS, but that is going away so time to rethink. The reason for setter/getter is that I could have 2 setters for a string property - assigning either text or string to the member property.

What are your thoughts?[/quote]

I think you know that getter/setter method scan be overridden , while computed properties (as with regular properties) can not - though they can be shadowed.

Because Computed Properties are not virtual, in theory they should be slightly faster, but I don’t know if it ever makes enough difference to matter.

Why I like Computed properties better, when I don’t want to override is that they help make the Navigator more organized/tidy as unless you click the open widget, they are a single line.

So it is a matter of what makes most sense for you and your coding style I think.

  • karen

The other advantage to computed properties is that they show up in the debugger just like regular properties.

which may have side effects since the debugger actually calls the getter to show the value

I’d say it really depends on what you expect subclasses to be able to do
Should they be able to override your “property” setter ? then you need to use the method pair as a public property and computed arent overridable (although done properly you can effectively shadow things)
Do you need to accept multiple kinds of assigned values to set one property (ie/ text & string) ? Then you probably need get/set

After that I use computed a lot because there’s often some action that needs to take place when the value is set
I’ll even use them just because I can put a break point in the setter and then track back to some error / issue that occurs and seems to be related to “when this thing is set …”

The nice thing is you can swap between a bare public property, getter /setter and computed with almost no impact on other code

Thank you Lady & Gent’s. Something to ponder I think.

I like ComputedProperties for when I serialize/deserialize an object especially when converting between things like DBRow <-> Object <-> JsonItem