graphql-java-codegen icon indicating copy to clipboard operation
graphql-java-codegen copied to clipboard

Feature Request: Ability to define field visibility and turn off generating getters/setters.

Open bpossolo opened this issue 3 years ago • 5 comments

Is your feature request related to a problem? Please describe. It's frustrating having to use JavaBean getter methods to access properties of generated model classes. Also, since the model classes are often used simply for data transfer, I have no need for setters.

Describe the solution you'd like Ability to control field visibility for generated model classes. Ability to turn off generating getters/setters. I'd like to generate immutable model classes with public final properties and no getters/setters.

Describe alternatives you've considered I realize this goes against the common way in which people tend to use java. However, I think there is a valid case for not having getters/setters on "dumb" data transfer objects. In my client code (which is mostly presentational view layer using PlayFramework), I simply reference my model object properties as I would javascript object notation. i.e. product.brand.name as opposed to product.getBrand().getName() This makes my client code/templates much cleaner and easier to read.

Example ideal generated classes

public class Product {

  public final Brand brand;
  
  public Product(Brand brand) {
    this.brand = brand;
  }
}

public class Brand {

  public final String name;
  
  public Brand(String name) {
    this.name = name;
  }
}

bpossolo avatar Nov 14 '21 23:11 bpossolo

I'm a Scala/Java developer. I've used the playframework and akka for some time. Personally, It's really worth doing so. (Use Scala is better)

But this kind of immutability is different from the common immutability in Java and may have a large cost. Let's see what @kobylynskyi thinks.

jxnu-liguobin avatar Nov 19 '21 02:11 jxnu-liguobin

fwiw, immutability via final fields is not a hard requirement. I’d be happy just being able to generate public fields.

bpossolo avatar Nov 19 '21 04:11 bpossolo

in my opinion, It is mainly used to implement a concise "immutable model", it is necessary to set it to final.

jxnu-liguobin avatar Nov 19 '21 06:11 jxnu-liguobin

I am totally fine with introducing a new config generateImmutableModels (default = false). The only concern I have is that it is better to keep fields private and to generate getters as per Java standards. If you would still like to have fields public (and final) then maybe it's worth introducing another config for field visibility? In order not to mix it up with model immutability.

kobylynskyi avatar Dec 02 '21 03:12 kobylynskyi

The only concern I have is that it is better to keep fields private and to generate getters as per Java standards. If you would still like to have fields public (and final) then maybe it's worth introducing another config for field visibility? In order not to mix it up with model immutability.

generateFunctionalImmutableModels?

jxnu-liguobin avatar Dec 02 '21 11:12 jxnu-liguobin

Hello sir , I am new to open source contribution. I already know java , my tech stacks & tools includes C, C++ , Python , Java, JavaScript , HTML , CSS , SQL , Bootstrap, ReactJS, ExpressJS, NodeJS & Git . I need a little help from your side to contribute to these amazing projects.

ghost avatar Feb 01 '23 02:02 ghost

New config generateModelsWithPublicFields will be released in 5.7.0

kobylynskyi avatar Mar 19 '23 00:03 kobylynskyi