Talk:FriendDependencies

From APIDesign

I have no real objections to friend relationships, although in C++ I avoid using the friend keyword. Reading this article about a new kind of dependency, I'm wodering if it wouldn't be much simpler to reserve the term API to talk about public interfaces? After all, the whole point of requiring a friend declaration is to keep the public from using the interface, right? So for all intents and purposes it is an internal interface, is it not? Even if it crosses module boundaries. While I agree that we always have software interfaces at module boundaries, I'm not convinced that calling all these interfaces APIs is a good idea. The concept of friend dependecies is a good example why.

Thanks for your question. The Chapter 4 explains the API classification categories as used by NetBeans (and induced from Sun's architecture review). The basic presumption is that API is everything somebody else can depend on. The stress is on can. Even APIs not intended for consumption, but available are APIs from this point of view (probably developed because customers were using Sun's Solaris in unexpected ways and complained when something broke with new version). Thus it is important to realize all APITypes and classify them. Private for something that nobody else should rely on, Friend for those who obtain a written permit, Under development for not finished APITypes and stable for the real APIs. Obviously, this is not the only way to approach API design, but I found this one to be the most honest. Btw. as Incremental deployment story shows, one can break API for oneself (e.g. for the closest friend one has), so there is a reason to call it API.

--JaroslavTulach 19:40, 20 September 2011 (UTC)