smartystreets / smartystreets-php-sdk

The official client libraries for accessing SmartyStreets APIs from the PHP Hypertext Processor.
https://smartystreets.com/docs/sdk/php
Apache License 2.0
28 stars 15 forks source link

Update PHP SDK to use POPOs #31

Closed alaskancode closed 5 months ago

alaskancode commented 2 years ago

This SDK returns a very antiquated object model reminiscent of the bad old XML/SOAP days. You have to call methods like getCities(), getCity(), etc in order to access nested objects.

Please clean this up and return plain old PHP objects (POPOs) instead. That way you can just access the cities array with myobject->Cities. Or you can access a member of that array with $myobject->Cities[0].

This is way cleaner and easier to use than what you are doing here. For compatibility reasons, you should obviously keep the option to keep doing it this way, but there should be a flag to go to this POPO model instead.

Also, why are the members of most of the returned objects private, necessitating the call to getCities, etc as discussed above? This is just annoying and unnecessary, and I can't think of a use case where this would be necessary.

smartyeric commented 5 months ago

Hi,

When implementing object oriented programming, as we are in this SDK, it is typically good practice to make all members private so long as they do not need to be public or protected, as is the case here. This improves code readability, and ensures that such members can only be changed and fetched deliberately and through the proper methods. I would recommend looking into OOP (object oriented programming) documentation for a more detailed explanation on the use of private as opposed to public. For these reasons, we are not planning on changing the SDK to use POPOs.

alaskancode commented 5 months ago

"When implementing object oriented programming, as we are in this SDK, it is typically good practice to make all members private so long as they do not need to be public or protected, as is the case here."

No, it's not. You have to understand the PURPOSE of this API, as opposed to spouting non-sense about object oriented programming. Users want to fetch data from your API, and access the information in a straightforward way. By making the returned objects private, you overcomplicate accessing the information. The PURPOSE of making objects private is to protect their information from manipulation by other objects in code. But the purpose of your API is to return information and make it easily accessible in code. If the users want to make methods or properties private, let them do that themselves. You are just overcomplicating the retrieval of data by making users access the data through specific public methods, which has no functional purpose in a system meant for easy data retrieval.