Tag Archives: Setter

And Another Thing … (About Setters)

When I wrote about Getters and Setters, I had not yet discovered a serious performance enhancement:

  • A GUI setter should always check whether the setting is already correct, and if so, not re-set.

This applies especially to textboxes and select lists.

Getters and Setters

Some test automation I “inherited” a while back had a textbox whose getter method was called GetCurrentBrick (not quite its real name).

Take just a moment to try to guess what the setter was called. The answer here is white text on white background, so select between the arrows to view: > Brk <

[Just discovered that it’s not obvious how to highlight text on some mobile devices, so will say here that Brk is the name given to the setter.]

Nice, huh?

If there is going to be a getter/setter method pair (and we'll get to that question in a minute), they should have consistent naming. A start would be GetCurrentBrick and SetCurrentBrick. Actually, though, a textbox doesn’t have any content but the “current” one, so it would be better to say just GetBrick and SetBrick.

But why have two methods at all? The setter should return the previous state, in case the caller needs to restore the previous value. Therefore it’s simple and useful to have a single method that always gets and can, optionally, set.

Thus a call to method Brick() with no value parameter is a pure getter, while a call with a value parameter Brick("in the Wall") is a setter that returns the previous value. This means there’s only one method name to learn, and it’s pretty intuitive that the value-less call is a getter, while the value-bearing call is a setter.

The exact implementation of this method would depend on the programming language at hand. In C#, which is what I’m using at the moment, the signature for a method of type String would be:

  • public String Brick(Locator locator, String value=null)

where the method tests value for nullity and acts accordingly. (The locator is something that tells CUIT how to find the control. I’ll be writing about class Locator in a future post.)

There will be text that’s displayed but can’t be set, and for that we’d need:

  • public String Brick(Locator locator)

And text that can be set but not got (password, for example):

  • public void Brick(Locator locator, String irretrievable)

Of course none of this is new. But as the anecdote at the beginning of this post demonstrates, Dr. Johnson’s famous observation remains all too true: People more frequently require to be reminded than informed.

Burdette Lamar