Re: Derived private interface

[Maciej Sobczak <see.my.homepage@gmail.com>]

On Jul 29, 1:24 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> >Did you try that with web servers?
>
> Fasinating. While I agree with most of your points, it is interesting that
> the web server that runs the AdaIC archive site, [...]
> the specialty handlers (like the search engine) are all
> called from case statements driven from those data tables.

I assume that this particular web server was written from scratch and
on top of some lower-level primitives (sockets). That's OK, but very
likely an overkill. That's why I have mentioned the possibility to
integrate off-the-shelf components, in which case there is simply no
place to put your case statement.

> The design was driven by an extra-paranoid approach to security: if the
> server had any way for a URL to execute foreign code (a plug-in),

I don't see any conflict between OOP and security here. The complete
application can be statically bound, in which case the execution of
dynamically loaded code is excluded.

What I'm talking about is a kind of dependency inversion - instead of
the web server calling each particular module from some single giant
case statement (which has to with all packages, etc.), you might have
a set of modules that register themselves in a single registry, which
is later used to resolve the call. By doing this, the web server and
its registry do not have to with anything other than the common
interface specification. Of course, you might still need to do some
magic in order to force all those modules to elaborate/initialize (so
that they can register in the web server central module), which might
turn out to be a ladder of with clauses that we wanted to avoid in the
first place, but this has nothing to do with OOP - it is only a
peculiarity of Ada and I can imagine a language where this can be done
externally by a build script or even by a mere presence of source
files.

We can also think about the automated generation of the with
statements that are need to force the elaboration of all modules.
But then - the giant case statement can be also automatically
generated, which could in turn be taken as an argument against OOP.
Oh, dear... :-)

Still, I believe that the open/close principle and the dependency
inversion are two (only?) good use cases for dispatching and that when
this design approach is needed, the dispatching offers the cleanest
solution.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com