Re: Derived private interface

["Randy Brukardt" <randy@rrsoftware.com>]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:4a4f185d-5268-4d73-a5df-8149bd117e0f@h9g2000vbr.googlegroups.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).

The Claw sockets and HTTP packages, to be specific.

> 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.

What off-the-shelf components? We're talking about Ada here, and the only 
components I know of are procedural libraries. After all, the only part of 
the core web server not covered by the Claw components was the URL parser 
(completely procedural, basic string to string transformations), and the 
code to stream in files (predefined Ada components).

The interesting parts are in the specialized handlers, and those were also 
built out of existing components (various proto-containers originated by Tom 
Moran, the crawler skelton that Tom created early on as a Claw sockets 
sample program, etc.) And none of those components use much OOP (or could).

>> 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.

It's less of a conflict than a need; once the application is statically 
bound, most of the value of OOP vanishes (particularly when the requirements 
aren't likely to change much, as in this case).

>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.

I mentioned all of that in one of my previous messages. The point is that in 
Ada, OOP doesn't help unless you have multiple interfaces associated with an 
object. That's not unusual, but it isn't always the case (and it isn't the 
case in the web server).

>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... :-)

Now you get it: the two organizations are equivalent in Ada if there is only 
a single interface. In which case, the simpler organization is probably 
better, especially if the lead designer was programming long before OOP was 
mainstream. :-)

>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.

I don't see any dependency inversion in the web server. (The web server 
calls packages to evaluate particular commands or operations -- that's how 
almost all programs work!) This sounds more like a case of trying to make 
everything look like a nail (to the OOP hammer).

I understand the value of the Open/Close principle, but it only is a win in 
Ada if there are multiple interfaces associated with an object. Otherwise, 
the amount of change is the same (or even less) for the non-OOP solution.

                                    Randy.