cloudinary / cloudinary_java

Cloudinary Java Client Library
MIT License
162 stars 108 forks source link

Replace Map usage with OOP design classes #86

Open djmj opened 7 years ago

djmj commented 7 years ago

I am currently testing your service and evaluating to be your customer. But i am dissapointedd from the Java integration you provide.

Everywhere you pass generic Map instances holding String key value pairs for configuration, upload options / results. That is not suitable for an object oriented programming language, and looks like 15 years ago programming style (including underscores).

Also enumeration classes could be used for fixed parameters like transformations and meaningfull exceptions shall be thrown. To detect a resource not found exception one must check the generic message like if (e.getMessage().contains("Resource not found")).

That key-value and error message approach is very error prone and really not developer friendly.

Example:

String publicId = (String) uploadResult.get("public_id");

Could be:

String publicId = uploadResult.getPublicId();
roeeba commented 7 years ago

Hi @djmj, thank you very much for the feedback. It's in our roadmap to make the Java library more structured. We'll update here on any progress made in this direction.

MateuszPluciennik commented 4 years ago

This issue is a bit old, but.. can someone tell what is current status? :)

aleksandar-cloudinary commented 4 years ago

Hi @MateuszPluciennik

We're in the process of rewriting all of our SDK code into a second iteration with shared code standards, consolidation of dependencies, with focus on easier extensibility through object orientation and more. The change outlined in this thread would be part of the SDK 2.0 project automatically.

For example, one of the first SDKs under this new SDK 2.0 project is our the PHP one which you can find here - https://cloudinary.com/documentation/php2_integration