home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / object / 3498 < prev    next >
Encoding:
Internet Message Format  |  1992-09-10  |  2.6 KB
  1. Xref: sparky comp.object:3498 comp.lang.c++:13468
  2. Newsgroups: comp.object,comp.lang.c++
  3. Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!ux1.cso.uiuc.edu!m.cs.uiuc.edu!ernie.cs.uiuc.edu!opdyke
  4. From: opdyke@ernie.cs.uiuc.edu ()
  5. Subject: Refactoring Object-Oriented Frameworks
  6. Message-ID: <1992Sep10.132444.28214@m.cs.uiuc.edu>
  7. Sender: news@m.cs.uiuc.edu (News Database (admin-Mike Schwager))
  8. Organization: University of Illinois, Dept. of Comp. Sci., Urbana,  IL
  9. Date: Thu, 10 Sep 1992 13:24:44 GMT
  10. Lines: 45
  11.  
  12. Below is the abstract of my PhD thesis, recently completed at the
  13. University of Illinois at Urbana-Champaign, entitled ``Refactoring
  14. Object-Oriented Frameworks.''  My research was supervised by
  15. Professor Ralph Johnson, and builds upon research he did with
  16. Brian Foote on Designing Reusable Classes.
  17.  
  18. The thesis is available from the Department of Computer Science as Technical 
  19. Report No. UIUCDCS--R--92--1759.  Erna Amerman (erna@cs.uiuc.edu) is the 
  20. department's contact for technical reports.
  21.  
  22. If you have any questions regarding this research, please contact
  23. Ralph Johnson (johnson@cs.uiuc.edu) or myself.
  24.  
  25. Bill Opdyke
  26. opdyke@cs.uiuc.edu; opdyke@iexist.att.com
  27.  
  28. *****
  29.  
  30. This thesis defines a set of program restructuring operations
  31. (refactorings) that support the design, evolution and reuse
  32. of object-oriented application frameworks.
  33.  
  34. The focus of the thesis is on automating the refactorings in a way
  35. that preserves the behavior of a program.  The refactorings are
  36. defined to be behavior preserving, provided that their
  37. preconditions are met.  Most of the refactorings are simple to
  38. implement and it is almost trivial to show that they are behavior
  39. preserving.  However, for a few refactorings, one or more of their
  40. preconditions are in general undecidable.  Fortunately, for some cases
  41. it can be determined whether these refactorings can be applied
  42. safely.
  43.  
  44. Three of the most complex refactorings are defined in detail: generalizing
  45. the inheritance hierarchy, specializing the inheritance hierarchy
  46. and using aggregations to model the relationships among classes.  These 
  47. operations are decomposed into more primitive parts, and the power of these
  48. operations is discussed from the perspectives of automatability and
  49. usefulness in supporting design.
  50.  
  51. Two design constraints needed in refactoring are class invariants and
  52. exclusive components.  These constraints are needed to ensure that behavior
  53. is preserved across some refactorings.  This thesis gives some conservative
  54. algorithms for determining whether a program satisfies these constraints, 
  55. and describes how to use this design information to refactor a program.
  56.  
  57.