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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,158ce2376534c35d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!hl8g2000vbb.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Derived private interface Date: Thu, 11 Aug 2011 06:50:29 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <27656578-65aa-48b9-9f89-4ebd4e0cb02a@glegroupsg2000goo.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> NNTP-Posting-Host: 83.3.40.82 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1313070629 14111 127.0.0.1 (11 Aug 2011 13:50:29 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 11 Aug 2011 13:50:29 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: hl8g2000vbb.googlegroups.com; posting-host=83.3.40.82; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HUALESNKRC X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13,gzip(gfe) Xref: g2news2.google.com comp.lang.ada:21508 Date: 2011-08-11T06:50:29-07:00 List-Id: On Aug 11, 12:21=A0am, "Randy Brukardt" wrote: > 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 t= he > server can execute is statically compiled into the web server). I see - but isn't it a special case? The advantage of OOP is in its run-time nature. That is, the registry can be modified at run-time according to anything from startup options to real-time data input. Modifying a giant case statement (or is it a chain of ifs? after all, URLs are not discrete in the Ada sense) might be acceptable between deployment cycles of the given system, but making this structure dependent on some run-time values would be too much. Of course, I don't claim that such run-time liberty is always required, but is certainly more general. This is an important point when designing reusable components. That is, if you implement the final web server you might be in a position to define your problem completely (or not - see the "fragile design" risk that Dmitry mentioned), but if you implement the web server component for reuse in potentially many future systems, then targeting the more general problem seems to be a way to go. This is why message delivery in YAMI4 is based on callbacks via interfaces and why the object registration is dynamic - new objects (they correspond to message targets or inboxes) can be added and removed on the fly. This still allows a completely static structure where all components are known statically and wired at program startup, so in this sense both approaches are addressed without unnecessary compromises. I think that web servers are not much different from this - in fact, they do exactly the same stuff, which is delivering external stimuli to some program handler. I would certainly use OOP for this part of any reusable web server component. -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com