Check out this quick tutorial to learn more about generating setters and getters using the Java::Geci framework, specifically with the accessor generator.
Let’s be friends:
Comment (0)
Join the DZone community and get the full member experience.
In this article, we created very simple hello-world generators to introduce the framework and how to generate generators generally. In this article, we will look at the accessor generator, which is defined in the core module of Java::Geci and is a commercial-grade and not a demo-only generator. Even though the generator is a commercial grade, using the services of the framework, it has simple code so that it can be represented in an article.
Accessors are setters and getters. When a class has many fields and we want to help encapsulation, we declare these fields to be private and create setters and getters, a pair for each field that can set the value for the field (the setter) and can get the value of the field (the getter). Note that contrary to what many juniors think, creating setters and getters is not encapsulation by itself, but it may be a tool to do proper encapsulation. And at the same time, note that it also may NOT be a tool for proper encapsulation. You can read more about it in Joshua Bloch’s Effective Java: 3rd Edition, Item 16.
Read it with a bit of caution, though. The book says that it was updated for Java 9. That version of Java contains the module system. The chapter Item 16 does not mention it, and even this edition still says to use private members with setters and getters for public classes, which, in the case of Java 9, may also mean classes in packages that the module does not export.
Many developers argue that setters and getters are inherently evil and a sign of bad design. Don’t make a mistake! They do not advocate to use the raw fields directly. That would even be worse. They argue that you should program with a more object-oriented mindset. In my opinion, they are right, and still in my professional practice, I have to use a lot of classes maintaining legacy applications using legacy frameworks that contain setters and getters, which are needed by the programming tools around the application. Theory is one thing; real life is another. Different integrated development environments and many other tools generate setters and getters for us, unless we forget to execute them when a new field was added.
A setter is a method that has an argument of the same type as the field and returns void. (A.k.a. does not return any value.) The name of the setter, by convention, is set and the name of the field with the first letter capitalized. For the field businessOwner, the setter is usually setBusinessOwner. The setter sets the value of the field to that of the argument of the setter.
The getter is also a method that does not have any argument but returns the argument value, and hence, it has the same return type as the type of the field. The name of the getter, by convention, is get, and again, the name of the field is capitalized. That way, the getter will be getBusinessOwner.
In the case of boolean or Boolean type fields, the getter may have the is prefix, so isBusinessOwnercould also be a valid name in case the field is some boolean type.
An accessor generates setter and getter for all the fields it has to.
The accessor generator has to generate code for some of the fields of the class. This generator is the ideal candidate for a filtered field generator in Java::Geci. A filtered field generator extends the AbstractFilteredFieldsGenerator class and its process() method is invoked once for each filtered field. The method also gets the Field as a third parameter in addition to the usual Source and CompoundParams parameter that we already saw in the article a few weeks ago.
The class AbstractFilteredFieldsGenerator uses the configuration parameter filter to filter the fields. That way the selection of which field to take into account is the same for each generator that extends this class and the generators should not care about field filtering: it is done for them.