-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Require constructor parameters to avoid temporal coupling #97
Comments
@janoszen I think currently supported has validations for the required parameters. If I misunderstood your suggestion, could you please provide some code snippet to explain the idea? |
For example: class Droplet {
public Droplet(
String name,
String region,
String size,
String image
) {
//...
}
} This would make it easier to use the API. More about temporal coupling: https://hackernoon.com/api-design-temporal-coupling-2c1687173c7c |
@janoszen Thank you for sharing your suggestion. It is helpful to define a constructor in the respective POJOs. I'm not sure when I can get to this suggestion; there are feature(s) should be added is in pending state. FYI, the library already has validations in almost all methods I believe, for example - digitalocean-api-java/src/main/java/com/myjeeva/digitalocean/impl/DigitalOceanClient.java Lines 300 to 307 in 479d227
|
@jeevatkm the point of not having temporal coupling is that you don't find out runtime that something is missing, the compiler tells you immediately that you are missing something. It reduces friction and the possibility of making a mistake. Anyway, it's just a suggestion because I ran into this issue. |
At this time the POJOs do not require any specific details on creation. However, the API calls require certain values to be present.
My suggestion would be to request the values required in the constructor to avoid temporal coupling and runtime errors.
The text was updated successfully, but these errors were encountered: