Re: Derived private interface

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 10.08.11 12:07, Maciej Sobczak wrote:
> 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.

One example of this style of OOP web server at work is Google's
mainframe operating system called App Engine.

Programming for this web server, you will typically define
request handler types and override one or more of the
get/post/delete/... operations of a parent type.
Next, you indicate which of your types should handle requests
for which URL. The server software loads your programs,
inspects them for request handler types, and runs the
overridden subprograms (get/post/delete/...) when corresponding
HTTP requests (GET/POST/DELETE/...) come in. (Requests will be
from the web, or from the mainframe when it has been instructed
run task queues, cron jobs, or pipelines.)

I don't think Google will, or even could, change a rather
large case statement whenever some new request handler is
added to the system. The system is running large number of
app engine programs, each having a number of request handler
types.  They use a registry.