I am reading Algorithms 4th Edition by Robert Sedgewick and in chapter 1.2 it discusses API design. It says:

"The key to success in modular programming is to maintain independence between modules. We do so by insisting on the API being the only point of dependence among modules."

Now the book is based on Java. I am considering this in terms of C++ development (but I imagine concepts are similar).

Is this suggesting that if I have a library eg to do networking, that if a client #includes my net.hpp header (fictional name) and maybe sets to link with net.lib then no other includes or libraries should be required? Is that the jist of this? Or is there something else?


No, the point is that to use one specific library, all you need to know about it should be in its public interface (in C++, typically the header file). You should not have to know anything other than that, particularly not anything about what algorithms, data types, variables etc. exist within the library. If you did know, you might start relying on this information, and you would be burnt when the library implementation is changed one day.

It is quite common that using one library requires you to include more headers from other libraries - for instance, using a HTTP library might require you to import the definitions of request or packet definitions that the HTTP library itself uses in its API. But it shouldn't require you to import a LinearTrie data structure merely because the HTTP library uses one in its private code.


No, thats not it.

It means that the networking library consists of two parts. An API, that defines how your code should communicate with this library and an implementation part, that does the doing of the library. And that your code should only depend on the API part and should not depend, both directly and transitively on the implementation part. The advantage of this kind of design is that you can easily change the inner workings of the library, without having to worry about breaking the code that uses this library.

It is actually somehow difficult to do this in C++, because if you try to use header files as your API, then they have to contain the implementation details of the library in form of private members. And if you try to have two "sublibraries", then the compilation pipeline of the code that uses this this separated library becomes much more complicated. And lets not talk about how would memory management happen in this case.

  • Not sure I agree with your specific C++ comment about exposing private member data in a class in header file. Well true but isn't that the same for Java? And you could just make an API that hid all that.
    – user619818
    Jan 31 '14 at 14:56
  • @user619818 You don't have to agree with facts. And no such thing happens with Java, because Java doesn't have header files. This is primarily problem with header files.
    – Euphoric
    Jan 31 '14 at 14:58
  • OK, I see what mean.
    – user619818
    Jan 31 '14 at 15:00
  • The answer is ok (+1), but to be fair, one should add that in well designed C++ library APIs, private members can be avoided (for example, by the PIMPL idiom).
    – Doc Brown
    Jan 31 '14 at 17:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.