| ←Older revision | Revision as of 19:40, 20 September 2011 | ||
| Line 1: | Line 1: | ||
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. | 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 [[APITypes|APIs]] not intended for consumption, but available are [[API]]s 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'' [[API]]s. 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]]. | ||
| + | |||
| + | --[[User:JaroslavTulach|JaroslavTulach]] 19:40, 20 September 2011 (UTC) | ||