I am sorry, but I have a lot of sympathy for the original poster. It can be easy to write an API that exposes enough about your implementation that it is very hard to later on change it. This can lead to much pain down the road.

If you want to have code which can be refactored, you want to from the beginning expose as little in your interfaces as you can. Your components should be very simple black boxes that are easy to understand, easy to code to, and which leave you with the flexibility to change your mind later about how that section works when (not if) you find out about your original implementation mistakes.

For more on this, pick up a good book on programming technique (my usual recommendation, Code Complete, would be a good choice) and read up on information hiding. For a couple of more data points, one of the best points that was made in The Mythical Man-Month is that the hardest class of bugs - and the one that causes the most trouble in large systems - occurs at interfaces. Also see Theo's comments on how poorly understood interfaces contribute to bugs and security holes.

The moral? Regard every interface you expose as a chain around your neck. Avoid dependencies. And the fact that you can reach into a library and abuse some piece of knowledge about the implementation does not change the fact that doing this is generally a horrible idea.