Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!husc6!bunny!jwg1 From: jwg1@gte.com (James W. Gish) Newsgroups: comp.software-eng Subject: Re: OOP and software reuse Message-ID: Date: 9 Jul 90 21:44:38 GMT References: <39400113@m.cs.uiuc.edu> <112789@linus.mitre.org> Sender: jwg1@GTE.COM Organization: GTE Laboratories Incorporated, Waltham, MA Lines: 73 In-reply-to: mitchell@community-chest.uucp's message of 9 Jul 90 15:07:02 GMT In article <112789@linus.mitre.org> mitchell@community-chest.uucp (George Mitchell) writes: > > This emphasis on programming and building reflects much of what I think is > wrong about the way we usually view reuse. The major cost of software is in > maintenance, not development. The major cost of development is not in coding. > To gain the greatest benefit from reuse, we need to have components that can > be incorporated without alteration, without unit test, and without subsequent > maintenance. What needs to be available in the component market place is not > only code, but test data, warranties, and life cycle support. This may be what we need, but with the possible exception of very general pieces of code, I don't think we're going to get very much of it. It is far too difficult as a designer/coder to envision how your code is going to be used in the future, either its context or the exact requirements imposed on it. When we write code, we usually do it with a particular context or application domain and framework (for example, error handling/reporting) in mind. However, when we go looking for code to use/reuse, unless the intended context and framework meet our requirements, we will have to adapt that code to our needs. We may want more or less functionality than the code provides, we may not be able to satisfy its requirements in one way or another. I have done a fair amount of programming in Eiffel over the past year or so. I like the language a lot. ISE, the suppliers of the Eiffel compiler, claim to provide a library of reusable classes. The folks at ISE have put a lot of work into the classes in an attempt to make them reusable. I've put a lot of hours into trying to use many of these classes. In many cases, in particular the graphics classes, it has been a difficult and time-consuming experience. Part of the problem is with the documentation, but even if the documentation were perfect, a fundamental problem exists: the designers had a particular model of computation, a particular style, a particular context, a particular application in mind when they put together these classes. Unfortunately, my model, my style, my context and specifically my use of these classes didn't exactly match what was provided. The question is, how do you overcome these differences? In some of the cases I found that changes in the language would have helped me make the adaptations necessary to the existing classes, even if I hadn't had the code - which Eiffel requires. However, no changes to the language/documentation could help me come to grips with some of the differences. In order to make use of these classes, I needed to make changes to the existing code. Failing that, I simply would have had to start from scratch (which, BTW, in retrospect would have saved me many painful hours). It's easy to say make it right, provide the test cases, documentation and everything I need to use it as is, but the reality is that none of us is omniscient enough to foresee how our code is going to be used, especially in the ever-changing world of computers and their expanding domains. So, for the foreseeable future I believe our best hope is in providing intelligent tools for assisting us in adapting code and associated artifacts including, for example, documentation and test cases, to new uses. -- Jim Gish (jgish@gte.com) Principal Investigator Software Reusability Project GTE Laboratories Inc.