• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Simple question about generated bean setX method

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A bean gen app we used in the past generated set methods in the following form:


Is there any point to this? When you get down to the byte code, does this impact performance one way or another (versus just setting the memberField regardless if it's already been set).
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I can't think of any reason why this makes sense, especially given the "==" comparison.
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I dithered over setters/getts versus direct field access way back when C++ was new. I finally decided that despite the nuisance value, setters and getters were better. Not all debuggers have a good, easy-to-use way of detecting changed fields. Also a setter allows the flexibility to add validation, logging, breakpoints, etc. And, occasionally, I end up changing the underlying data type, so the abstraction of set/get methods minimizes the impact on other parts of the program. I do a lot of datatype changes, which is why I have an especial antipathy for Hungarian Notation.

As far as overhead goes, I expect that the optimizer can detect simple set/get operations and inline them to direct access where feasible, so the ultimate generated code would potentially be identical using either approach, with the edge on flexibility going to the set/get methods.

Why test-before-set? This mostly makes sense in an ORM or remoting environment. Setting a value can cause a "dirty" flag to be set in the underlying metacode in cases where the metacode is naive and doesn't itself check for changes that don't actually change anything. So doing this can reduce the overhead in remote transmissions and result in tighter SQL code generation in an ORM system.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic