Re: Derived private interface

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

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:b6049447-8479-46ca-82e8-b6031a4b4d1a@q15g2000yqk.googlegroups.com...
On Aug 9, 11:35 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

>> 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!)
>
>The dependency inversion is in the fact that the web server does not
>have to know the modules it is calling. It is enough if the modules
>know the web server (and its registry, to be exact) - thanks to this
>new modules can be added without touching the web server itself
>(that's the open/close principle at work now). What is needed for the
>dependency inversion to work is a spec of something common - in the
>case of OOP this is an interface.

But adding new modules without somehow modifying the web server is simply 
not allowed in the problem statement that I had (that is, all code that the 
server can execute is statically compiled into the web server). So there can 
be no "inversion" here -- some piece of the server needs to know about all 
of the code that it possibly can execute. (Ada requires with clauses at a 
minimum.)

>> This sounds more like a case of trying to make
>> everything look like a nail (to the OOP hammer).
>
>No, this is trying to reduce the effort to maintain a heavy component
>that is tested and verified only once.

I have no idea what you are talking about; no part of my web server (other 
than the case statement) is modified to add a new capability. [Note that 
something list the case statement has to exist in the OOP model anyway - ,at 
a minimum for with clauses and a series of registration calls (there is 
insufficient control over elaboration in Ada to use elaboration for that 
purpose in a real system).]

I can explain the mechanism in a bit more detail. The web server has a data 
list of (normalized) URLs that require special handling, along with a 
special handling key. When the web server sees any of these, it calls the 
special handling interface routine (passing the record containing the GET 
parameters and the output socket). Otherwise, it tries to serve a normal web 
page.

The special handling interface contains a case statement on the special 
handling keys, and calls the appropriate handler for each one. Since the 
original requirement was for all of the code to be statically compiled, that 
code is also part of the web server executable, and of course the special 
handling interface needs to be modified to add a new module. But it (and the 
data table) are the only things that need modification in this scenario.

An OOP design would have been identical (the data table was intended to be 
modified "on the fly", although we never needed that capability and thus 
never implemented it - the data is just an Ada aggregate currently), with 
the exception that the case statement would be replaced by a registration 
routine that gathered all of the units together. I fail to see how that 
would have improved anything about the design.

It would, however, have provided an easier way to make the design far more 
complex (and less maintainable, IMHO), by adding interfaces to support 
dubious capabilities (and thus changing the behavior of the core web 
server), rather than funneling everything through the interface.

                                   Randy.