A simple kdevplatform design question ...

[Andreas Pakulat]

On 22.06.07 15:25:32, Sandro Andrade wrote:
> On 6/22/07, Alexander Dymo <dymo at ukrpost.ua> wrote:
> >
> >On 6/21/07, Sandro Andrade <sandro.andrade at gmail.com> wrote:
> >> Why there is a need for separating ICore from Core ?
> >As Andreas said, the plugins don't need to link to the application,
> >they need to link only to the small library with well-defined set of
> >interfaces (with BC guarantees).
> 
> As stated in http://accu.org/index.php/journals/269, the three main reasons
> for separating interface from implementation are:
> 
> 1) Reducing implementation detail exposed to the user
> 2) Reducing physical coupling
> 3) Allowing customised implementations
> 
> I guess the reason 3) does not apply to the kdevplatform, right ?

Wrong. It only doesn't apply to the interfaces that are implemented in
libkdevplatformshell. There are many more interfaces in the platform.
And those are pure interfaces (as opposed to partly-implemented
interfaces as IPlugin)

> So, in conclusion, the reason for this programming style is just to reduce
> compilation time and dependencies ?

No. It is to provide a proper API for plugins. The plugins don't need
and shouldn't know about certain parts of the API of Core, Project or
PluginController. And this is a way to force them to do so. Any plugin
that links against kdevplatformshell is considered broken.

> In despite of these reasons, BC issues
> could be handled by a d-pointer, leading us to forget about separating ICore
> >from Core ?

Thats not right. A dpointer certainly helps to keep BC, while being able
to add members and private functions. But the classes in
libkdevplatformshell can even change their public API in non-BC manner
(adding a virtual, implement a virtual from a base class and so on)
without any plugin ever noticing, because the plugins don't work with
ProjectController* but with IProjectController* whose API is defined and
will not change.

Andreas

-- 
Chicken Little only has to be right once.