- edited description
Enhancement suggestions for getter/setter/equals/hash code generator
Scott - great stuff with the new code generator. The equals/hash stuff is especially welcomed. As I watched the video, I was immediately struck with two enhancement suggestions that I kindly offer
1 - Generate the getters and setters each as one line. eg.
public Integer getIdNumber() {return idNumber;}
public void setName(String name) {this.name = name;}
why? this boilerplate code need not take up vertical real estate
2 - (User-option) Generate setters as fluent/builder pattern rather than individual methods, e.g.
public Individual withName(String val) {this.name = val; return this;}
why?
- when using, the .withXXX pattern allows for more readable code (IMHO) as one gets auto-indents
Individual individual = new Individual()
.withName('foo')
.withDoB(System.today())
... ;
versus
Individual individual = new Individual();
individual.setName('foo');
individual.setDob(System.today());
Note rough analog to
Account account = new Account(
Name = 'foo',
Website = 'http://foo.com',
...
);
is nicer looking than
Account account = new Account();
account.name = 'foo';
account.Website = 'http://foo.com';
...
Note that generating a constructor with > 4 args runs into a PMD warning
Comments (9)
-
reporter -
reporter - edited description
-
repo owner Great recommendations, Eric. Thanks! Generating as single-line should be quite simple. Someone else asked if I could optionally generate ApexDoc header comments, so I think both of those can fit into the next iteration.
The second request is interesting because the Java analog offers pretty much that option:
The former option--Records style for getters--indicates that read methods should be named as
foo()
instead ofgetFoo()
, and the latter option--Builder for setters--indicates that write methods should follow the builder/fluent pattern, returningthis
after setting the value.Should be simple enough to add those enhancements as well. Not sure if they’ll fit into the next build along with the two above, but it seems like they should…
-
reporter Thanks Scott - I could tell you were proud of this feature by your tone on YouTube!
You could also consider adding an optional
toJson()
method - there are issues here as not every type is serializable but would work in most use cases -
repo owner Oh, regarding this:
Note that generating a constructor with > 4 args runs into a PMD warning
that’s all based on PMD Apex configuration:
<rule ref="category/apex/design.xml/ExcessiveParameterList" message="Avoid long parameter lists"> <priority>3</priority> <properties> <property name="minimum" value="4" /> </properties> </rule>
Set that value to whatever makes sense for your projects (or disable the rule), but the default ruleset starts warning at
4
(which seems a bit low to me). -
repo owner Okay, these are all implemented except for record-style getters for fields:
My take is that if you want record-style access to fields in Apex, you should probably be using properties anyway. We’ll see if others agree or disagree, but I’m not inclined to implement that until/unless I hear from folks that it would be used.
This should all be included in Thursday’s build.
-
repo owner - changed status to open
-
repo owner - changed status to resolved
Delivered in 2.2.8.2.
-
reporter Nice! -- My next custom ApexType will try this for sure!
- Log in to comment