Don’t use internal APIs while integrating 3rd party Libraries

While coding in a hurry, you sometimes use internal API’s either willingly –since you don’t want to spend more time– or unwillingly instead of public equivalents. I am saying don’t use them because they meant to change, as the name implies they are for internal use.

Just today, I spent three hours just to replace these kind of codes after upgrading Alfresco to 3.3 from 3.2 for a project I am working on. Those who know Alfresco will understand me. Alfresco is full of internal and public APIs, there is no clear distinction, just an annotation that specifies that a service is public. –and it is enough for decent developers, I agree :)–

However we had used a helper class somehow and we had used it extensively. It is called DictionaryHelper, it contains utility methods for querying information about your data model. There are also two other services which are public and provide the same functionality collaboratively named; DictionaryHelper and NamespaceResolverService.

Anyway, shit happens we had used it somehow and I spent the last three hours just to replace them with proper code. I am not saying that using internal API’s is prohibited sometimes you can use them intentionally, even in that case, be clever enough put an abstraction on top. This way it is much more easy to change the code when the internal API changes.

But at least even coding in the quickest fashion, we are always writing tests –we are right? :)– and it becomes easier to update the existing code and be sure that everything works as supposed to.

READ  Writing, building, and running your C++ on a Mac

Leave a Reply

Your email address will not be published. Required fields are marked *