Provide Default Constructors on Request/Response Classes

[ra-lukas]

We would love to serialize the response objects to JSON for microservice integration. However, this is difficult given the response classes do not have default constructors.

Would you be interested in a pull request that integrates Lombok to provide no-args contructors and builders?

Or, would you be amenable to a pull request that simply provided no-args, default constructors?

[Gupta-Suruchi]

Hi, I'm working on a similar project, I would love to fix it.

[ra-lukas]

@protonpluss For the time being, this is what we did, using Lombok.

@Data
public class QuoteResponse {
    private String symbol;

    private double open;

    private double high;

Then used MapStruct to copy over the data. https://mapstruct.org/

[crazzyghost]

@ra-lukas @protonpluss
By design, these response classes are intended to be accessed through standard getter methods. There are no publicly accessible constructors for clients to use, as the library handles data retrieval and class instantiation.

Serialization of the responses does not necessitate public constructors. You should be able to perform serialization tasks using and object mapper from an industry standard library (e.g https://github.com/FasterXML/jackson)

For deserialization I would recommend a similar approach to what you have taken but by managing app/service specific response classes decoupled from the library in your downstream services. This eliminates the need to include the library in any service that doesn't require calls to the AlphaVantage API, saves you some jar bytes, and provides greater control over the needed fields.

[ra-lukas]

Serialization of the responses does not necessitate public constructors.

For deserialization I would recommend a similar approach to what you have taken but by managing app/service specific response classes decoupled from the library in your downstream services.

ROFL.

Because public constructors are THAT BIG OF A DEAL TO ADD.

[irodzik]

Serialization of the responses does not necessitate public constructors.

For deserialization I would recommend a similar approach to what you have taken but by managing app/service specific response classes decoupled from the library in your downstream services.

ROFL.

Because public constructors are THAT BIG OF A DEAL TO ADD.

Just doing some review of alphavantage libs and found this comment. Couldn't not answer to this ignorant comment. Loosening API by adding public constructors means extra place to maintain contract with API consumer. Also assuming on your response tone, that you are an expert, could you please explain why you do use library classes and tight coupling with library code instead of separating it from your application domain?

[ra-lukas]

tight coupling with library code

Here, have a gander at one of the most basic design elements of Java over the past 20+ years. ***@***.***/understanding-java-beans-a-comprehensive-guide-for-beginners-684163011c82 Best wishes to you Igor!

…

On Thu, Sep 26, 2024 at 12:47 PM Igor Rodzik ***@***.***> wrote: Serialization of the responses does not necessitate public constructors. For deserialization I would recommend a similar approach to what you have taken but by managing app/service specific response classes decoupled from the library in your downstream services. ROFL. Because public constructors are THAT BIG OF A DEAL TO ADD. Just doing some review of alphavantage libs and found this comment. Couldn't not answer to this ignorant comment. Loosening API by adding public constructors means extra place to maintain contract with API consumer. Also assuming on your response tone, that you are an expert, could you please explain why you do use library classes and tight coupling with library code instead of separating it from your application domain? — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APPJP3FB72TEAVVNO72CUFTZYQ3DZAVCNFSM6AAAAABCS35H52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZXGQ3DCMBTG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[irodzik]

Best wishes and good luck to you too!