alphavantage-java icon indicating copy to clipboard operation
alphavantage-java copied to clipboard

Provide Default Constructors on Request/Response Classes

Open ra-lukas opened this issue 2 years ago • 7 comments

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?

ra-lukas avatar Jan 31 '24 11:01 ra-lukas

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

Gupta-Suruchi avatar Feb 08 '24 07:02 Gupta-Suruchi

@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/

ra-lukas avatar Feb 08 '24 09:02 ra-lukas

@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.

crazzyghost avatar Feb 19 '24 21:02 crazzyghost

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.

ra-lukas avatar Feb 20 '24 09:02 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.

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?

irodzik avatar Sep 26 '24 16:09 irodzik

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 https://github.com/crazzyghost/alphavantage-java/issues/31#issuecomment-2377461037, or unsubscribe https://github.com/notifications/unsubscribe-auth/APPJP3FB72TEAVVNO72CUFTZYQ3DZAVCNFSM6AAAAABCS35H52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZXGQ3DCMBTG4 . You are receiving this because you were mentioned.Message ID: @.***>

ra-lukas avatar Sep 26 '24 17:09 ra-lukas

Best wishes and good luck to you too!

irodzik avatar Sep 26 '24 18:09 irodzik