Re: AspectJ: solution to Java's repetitiveness?

Patricia Shanahan <pats@acm.org> writes:


  This mixes two views: The interface and the implementation.

  From the implementation view, there might be getters and
  setters for variables, but from the interface view, there
  are only operations with behavior - no variables. So, one
  can not refer to variables in the interface documentation,
  the best approximation would be to say that some operation
  behaves /as if/ the object would have a variable and the
  operation would return its value.

  Information hiding can be preserved better if request or
  report methods are used instead of setters. So instead of:

/* Sets the color of the object to BLUE. */
object.setColor( BLUE );

  one can use

/* Report to the object that the clients preferred
object color now is BLUE. */
object.reportColorPreference( BLUE );

  In the second case, we do not refer to a property, but
  report out own preferences. The object then /should/ fulfill
  the clients wish if possible. The implementation might be
  the same as for ?setColor?, but the documentation of the
  interface more closely reflects that the client does not
  have direct write access (because the object might deny
  the operation).

  Instead of getters, on can tell the object what to do.
  ?Tell, don't ask.?

/* Gets the color to print it. */
print( object.getColor() );

/* Tell the object to print the color. */
object.withColorDo
( new VoidMethod<Color>(){ public void m( final Color c ){ print( c ); }});

  Which, of course would be simplier to write if Java had
  literals for parameterized block objects like Smalltalk.