Avoiding redundancy in Info Builders

[Jarvx200]

Hello, I opened this thread to discuss possible solutions to avoid redundancy in builder creation.
As @yangxk1 mentioned (#764) , creating a Generic Abstract superclass might complicate the codebase and I would like to discuss alternative solutions.

[yangxk1]

Hey @Jarvx200 ,It's a question worth discussing. In the design of many systems, there is often a superclass, say ElementInfo, with VertexInfo and EdgeInfo extend it. General variables (e.g., Version, baseUri) are present in ElementInfo. However, such a design invariably introduces complexity, and we need to consider if it is worth implementing. Especially in the 'java-Info' module, where there is little logic to handle, we need to consider how much code can actually be consolidated by using a superclass abstraction, and how much it truly helps developers understand the code. What you think about that?

[Jarvx200]

Hey there, my suggestion to this problem is instead of abstracting we might actually find using composition a bit more helpful for the common fields. The main benefit would be not needing to merge the abstraction tree of the builders and than having to use generics. (#764 rollback)

We could create a simple proxy class that would contain those attributes and have them composited into the builders.

Another suggestion would actually be to use an interface with default methods for each of the fields, the only problem here being as far as I can see that it would still require some sort of state to handle transitional data states. That could be done like a pipeline but I suspect we might end up in a similar situation.

If you want, I can mock some code samples for each one of my proposal and continue discussing forward on the issue!

@Thespica @yangxk1

[yangxk1]

@Jarvx200 , I still have concerns about whether the complexity is worth it. If you strongly support the idea, you can show a simple demo