Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnews!cbnewsm!lfd From: lfd@cbnewsm.att.com (Lee Derbenwick) Newsgroups: comp.software-eng Subject: Re: Reusability considered harmful??(!!) Summary: All sizes, all prices! :-) Keywords: Reusability, Division of Labor Message-ID: <1991Feb18.222556.27749@cbnewsm.att.com> Date: 18 Feb 91 22:25:56 GMT References: <6108@stpstn.UUCP> <4842@cui.unige.ch> <318@smds.UUCP> Organization: AT&T Bell Laboratories Lines: 46 In article , jls@yoda.Rational.COM (Jim Showalter) writes: [I wrote:] > >In that scenario, you wouldn't buy a _stack_ from the > >Reusable Software Shop; you'd buy a _stack builder_. > > Disagree. A stack is not a sufficiently macro-scale abstraction to > require such overkill. That's likely, which is why I said a general-purpose list handler (generating numerous flavors of stacks, queues, dequeues, etc.) would be a more appropriate size. That _is_ still pretty small, but it's big enough to be useful. And much of this thread has dealt with reusable elements on the size of _a single stack implementation_, and then gotten into arguing about the exact features such a thing should have. Consider this small-to-medium scale integration. It won't become practical until the emergence of good tools for building X-builders. And even then, this is probably too small to _market_ separately; it would probably come bundled with a bunch of similar-sized component builders for different components. A library of component builders, just as you might today buy a library of statistical routines, or of graphical routines. > A much more appropriate component requiring > configurability might be an entire message passing layer: this is > a large scale chunk of a system, highly reusable if implemented > properly, and greatly in need of "strapable" options in order to > be flexible enough to meet many different networking protocols, > communication requirements, etc. In this case, yes, it makes sense > to provide lots and lots of configuration options, which could be > supplied as arguments (to subprograms and/or generics), read in from > configuration files, etc. This is the strategy taken by one of our > more successful customers. A good example of a larger-scale configurable component. Such a component is big enough on its own to justify a lot work on hand- crafted configuration capabilities. Smaller configurable components will need to reuse much of the configuration and "strapping" code before they are equally practical. -- Speaking strictly for myself, -- Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ -- lfd@cbnewsm.ATT.COM or !att!cbnewsm!lfd