From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,158ce2376534c35d X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.71.MISMATCH!xlned.com!feeder3.xlned.com!feeder.news-service.com!87.79.20.101.MISMATCH!newsreader4.netcologne.de!news.netcologne.de!newsfeed01.chello.at!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Wed, 10 Aug 2011 13:26:24 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Derived private interface References: <27656578-65aa-48b9-9f89-4ebd4e0cb02a@glegroupsg2000goo.googlegroups.com> <0fe3b0f8-c064-444d-899d-640e891b58c3@w4g2000yqm.googlegroups.com> <128d8eb5-1cc6-47e3-a09b-b53a5ef289ce@m10g2000yqd.googlegroups.com> <4e141501$0$6629$9b4e6d93@newsspool2.arcor-online.net> <4b2728fc-6127-45d8-a314-9fc491701c26@g12g2000yqd.googlegroups.com> <82vcve4bqx.fsf@stephe-leake.org> <4e15b223$0$6541$9b4e6d93@newsspool4.arcor-online.net> <4a4f185d-5268-4d73-a5df-8149bd117e0f@h9g2000vbr.googlegroups.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4e426ae0$0$6584$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 10 Aug 2011 13:26:25 CEST NNTP-Posting-Host: ecb8fe31.newsspool3.arcor-online.net X-Trace: DXC=8K[>EXmd>FO@Y=h<_c3PkHMcF=Q^Z^V3H4Fo<]lROoRA8kFJLh>_cHTX3jM7emAfS8W6lF X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:20507 Date: 2011-08-10T13:26:25+02:00 List-Id: On 10.08.11 12:07, Maciej Sobczak wrote: > On Aug 9, 11:35 pm, "Randy Brukardt" 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.