| William F. Opdyke and Ralph E. Johnson. Creating abstract superclasses by refactoring, 1993. |
....by introducing lower level abstractions, and by proving the associated invariant. For more details regarding the refinement scheme incorporated in the formalism, the user is referred to [10] When the above procedure is applied in a recursive fashion, a hierarchy of abstractions is obtained [14]. Each level of the hierarchy describes the system with its own concepts. These concepts can be mapped to more concrete ones when advancing towards implementation, or traced back to higher level concepts where more abstract descriptions of the system can be found. The top level of the hierarchy is ....
....X, pages 1 11, IOS Press, 1999. 12] L. Lamport. The temporal logic of actions. ACM Transactions on Programming Languages and Systems, 16(3) 872 923, May 1994. 13] L. Lamport. Composition: A way to make proofs harder. Digital Systems Research Center, Technical Note 1997 030a, December 1997. [14] T. Mikkonen and H. M. J arvinen. Specifying for releases. International Workshop on Principles of Software Evolution, pages 118 122. April 20 21, Kyoto, Japan, 1998. 15] T. Mikkonen, E. L ahde, M. Siiskonen, and J. Niemi. Managing software evolution with the service concept. Proceedings of ....
[Article contains additional citation context not shown here]
W.F. Opdyke, R.E. Johnson. Creating abstract superclasses by refactoring, Proc. ACM Computer Science Conference, pp. 66-73, ACM Press, 1993.
....a lot of attention in the last years. Automatic reorganization takes its place in the process of re engineering of object oriented systems initially build without concern for generalization, and of large and long lived applications. It can bring to the fore factorization and abstract classes [OJ93] or help to merge hierarchies representing different applications . The more the classes to be structured multiply and become intricate, the more the structuring process can benefit from automation. This paper deals with automation of the insertion of a class (defined by a set of properties) ....
....of the algorithm. We also plan to extend the number of handled cases of automatic comparison of generic properties. Code comparison can be extended to the cases where a code is included in another and where two codes have common subsets. In this, we will not exactly follow the refactoring school ([OJ93] and [Moo96] since we plan to limit ourselves to refactoring sub parts of occurrences of same generic properties. This study is in progress. Another difficult issue would be to combine this work with linearization algorithms [DHHM94] used to solve conflicts in hierarchies with multiple ....
William F. Opdyke and Ralph E. Jonhson. Creating Abstract Superclasses by Refactoring. Proceedings of the 21st Annual Conference on Computer Science, pages 66--72, February 1993.
....components of existing patterns in use. Additionally, there is ongoing philosophical interest in the very nature of coding abstractions, such as patterns and their relationships. 2. 1 Refactoring approaches Attempts to formalize refactoring [12] exist, and have met with fairly good success to date[8, 16, 19]. The primary motivation is to facilitate tool support for, and validation of, the transformation of code from one form to another while preserving behaviour. This is an important step in the maintenance and alteration of existing systems, and patterns are seen as the logical next abstraction upon ....
....process. Several key pieces, however, may benefit from the work outlined in this paper. Our isotope example in Section 4. 4 indicates that it may be possible to support verification of Fowler s refactoring transforms through use of the # calculus, as well as various other approaches currently in use[12, 19, 16]. O Cinn eide s minitransformations likewise could be formally verified and applied not only to existing patterns, but also perhaps to code that is not yet considered pattern ready, as key relationships are deduced from a formal analysis[17, 18] Furthermore, we believe the fragments based ....
W. F. Opdyke and R. E. Johnson. Creating abstract superclasses by refactoring. In Proc. of the Conf. on 1993.
....language abstractions. Refactorings behavior preserving program transformations have become an important topic in the object oriented reengineering community [21, 26, 25] Research on refactoring originates from the seminal work of Opdyke [19] in which he defined refactorings for C [16, 20]. In this context, Tokuda and Batory [26] evaluate the impact of using a refactoring engine in C . Fanta and Rajlich report on a reengineering experience where dedicated tools for the refactoring of C were developed [11] However, they do not analyze the two versions of their code to compare ....
William F. Opdyke and Ralph E. Johnson. Creating abstract superclasses by refactoring. In Proceedings of the 1993.
....can be defined by combining the lower level ones. Such higher level refactorings are also guaranteed to preserve the behavior, since they are composed of lower level refactorings, that preserve the behavior. Examples of high level refactorings are introducing abstract classes into the framework [OR93] and turning inheritance relationships into aggregation relationships [JO93] Based on Opdyke s ideas, tool support for refactoring in the Smalltalk programming language was provided by means of the Refactoring Browser [RBJ97] This browser is tightly integrated with the Smalltalk development ....
....we will not consider each and every possible refactoring. Instead, we will consider the low level refactorings defined in [Opd92, Rob99, Tic01] These refactorings are formally defined, so we know their e#ect upon the implementation, and can be combined to form higher level refactorings [Opd92, OR93, JO93] that can be used to evolve a framework in many di#erent ways. What follows is a list of these low level refactorings. addClass(className, superclass, subclasses) this refactoring adds a new class named className as a subclass of class superclass. Furthermore, it changes the ....
[Article contains additional citation context not shown here]
W.F. Opdyke and Johnson R.E. Creating Abstract Superclasses by Refactoring. In In Proceedings of Computer Science Conference, pages 66--73. ACM Press, 1993.
....components of existing patterns in use. Additionally, there is ongoing philosophical interest in the very nature of coding abstractions, such as patterns and their relationships. 3. 1 Refactoring approaches Attempts to formalize refactoring [16] exist, and have met with fairly good success to date[12, 28, 31]. The primary motivation is to facilitate tool support for, and validation of, the transformation of code from one form to another while preserving behaviour. This is an important step in the maintenance and alteration of existing systems, and patterns are seen as the logical next abstraction upon ....
....another. Several key pieces, however, may benefit from the work outlined in this paper. Our isotope example in Section 5. 4 indicates that it may be possible to support verification of Fowler s refactoring transforms through use of the # calculus, as well as various other approaches currently in use[16, 31, 28]. O Cinneide s minitransformations likewise could be formally verified and applied not only to existing patterns, but also perhaps to code that is not yet considered pattern ready, as key relationships are deduced from a formal analysis[29, 30] Furthermore, we believe the fragments based systems ....
William F. Opdyke and Ralph E. Johnson. Creating abstract superclasses by refactoring. In Proc. of the Conf. on 1993.
....abstractions. Refactorings behaviour preserving code transformations have become an important topic in the object oriented reengineering community [RBJ97,TB99,TDDN00] Research on refactoring originates from the seminal work of Opdyke [Opd92] in which he defined refactorings for C [JO93,OJ93] In this context, Tokuda and Batory [TB99] evaluate the impact of using a refactoring engine in C . Fanta and Rajlich report on a reengineering experience where dedicated tools for the refactoring of C were developed [FR98] However, they do not analyse the two versions of their code to ....
William F. Opdyke and Ralph E. Johnson. Creating abstract superclasses by refactoring. In Proceedings of the 1993 ACM Conference on Computer Science, pages 66--73. ACM Press, 1993.
....of existing patterns in use. Additionally, there is ongoing philosophical interest in the very nature of coding abstractions, such as patterns and their relationships. 3.1. Refactoring approaches Attempts to formalize refactoring [10] exist, and have met with fairly good success to date[7, 15, 17]. The primary motivation is to facilitate tool support for, and validation of, transformation of code from one form to another while preserving behaviour. This is an important step in the maintenance and alteration of existing systems, and patterns are seen as the logical next abstraction upon ....
W. F. Opdyke and R. E. Johnson. Creating abstract superclasses by refactoring. In Proc. of the Conf. on 1993.
....[GKL94, Sj93] about how persistent or transient types change during maintenance. Researchers studying maintenance of object oriented hierarchies, which are not necessarily persistent, cite modifying types in the hierarchy and reorganizing the hierarchy as frequently desirable activities [JO93, OJ93, LBSL91, OJ90, Cas90, MS92a] One can expect, however, that maintainers are reluctant to make radical changes to an object oriented hierarchy or any other persistent type or schema definitions if those changes make it difficult or impossible to access existing data. As a result, the maintainers ....
William F. Opdyke and Ralph E. Johnson. Creating abstract superclasses by refactoring. In Proceedings of CSC '93: The ACM 1993 Computer Science Conference, February 1993.
....classes, factor implementation differences into subcomponents, separate methods that do not communicate, send messages to components instead of self, and reduce implicit parameter passing. Refactoring of object oriented frameworks is described in [30] refactoring of aggregation hierarchies) and [46] (refactoring of inheritance hierarchies) An updated account of refactoring of object oriented software in general is described in [16] 10.2 Architecture and Change Figure 10.2(a) illustrates the dependencies between, one one hand, the requirement and platform domains and, on the other hand, ....
William F. Opdyke and Ralph E. Johnson. Creating Abstract Superclasses by Refactoring. In Proceedings of the ACM 1993.
....a desire to perform refactoring of existing code, while others have attempted the more pragmatic approach of identifying core components of existing patterns in use. 2. 1 Refactoring Approaches Refactoring[13] has been a frequent target of formalization techniques, with fairly good success to date[10, 24, 27]. The primary motivation is to facilitate tool support for, and validation of, transformation of code from one form to another while preserving behaviour. This is an important step in the maintenance and alteration of existing systems, and patterns are seen as the logical next abstraction upon ....
....key pieces, however, may benefit from the work outlined in this paper. Our isotope example in Section 7. 4 indicates that it may be possible to support verification of Fowler s refactoring transforms through use of the combined # # # calculus, as well as various other approaches currently in use[13, 27, 24]. O Cinneide s minitransformations likewise could be formally verified and applied to not only existing patterns, but perhaps to code that is not yet considered pattern ready, as key relationships are deduced from a formal analysis[25, 26] Furthermore, we believe the fragmentsbased systems such ....
W. F. Opdyke and R. E. Johnson. Creating abstract superclasses by refactoring. In Proc. of the Conf. on
....inheritance Several research groups [5,17,7,13,18] have investigated methods for discovering classes in programs written in procedural languages, like C, Cobol, etc. This paper builds on this effort and presents the next step, i.e. restructuring into classes. The third issue was investigated in [14,15] and is dealt with briefly in the conclusions section of this paper. Class encapsulation requires substantial effort because variables and code fragments belonging to a domain concept are often scattered throughout the code. As they are brought together into one class, ripple effects impact other ....
....of entities have their similarity measure below a preset threshold. A study in [9] shows none of the approaches is truly satisfactory. In our case study we identified classes intuitively based on personal object oriented expertise. Other related work deals with restructuring. Johnson and Opdyke [14,15] study class restructuring of classes related by composition and inheritance. Their transformation set includes the creation of an abstract superclass, subclassing, and refactoring to capture aggregations and components. Among the transformations they propose in [14,15] there are transformations ....
[Article contains additional citation context not shown here]
Opdyke W.F., Johnson R.E., "Creating Abstract Superclasses by Refactoring", In Proceedings of Computer Science Conference, ACM Press, New York NY, 1993, pp. 66-73.
....[Tich98m] 6. Related Work Refactoring as a technique to reorganise object oriented constructs has been investigated for quite some years now. The Ph.D. work of Opdyke resulted in a number of papers describing incremental redesign performed by humans supported by refactoring tools [Opdy92b] [Opdy93a], John93b] This line of work resulted in the Refactoring Browser, a tool that represents the state of the art in the field [Robe97a] In contrast, both Casais and Moore report on tools that optimise class hierarchies without human intervention [Casa92a] Moor96a] More recently, Schulz et al. ....
William F. Opdyke and Ralph E. Johnson, "Creating Abstract Superclasses by Refactoring," Proceedings of the 1993 ACM Conference on Computer Science, ACM Press, 1993, pp. 66-73.
....[Deme99d] 6. RELATED WORK Refactoring as a technique to reorganise object oriented constructs has been investigated for quite some years now. The Ph.D. work of Opdyke resulted in a number of papers describing incremental redesign performed by humans supported by refactoring tools [Opdy92b] [Opdy93a], John93b] This line of work resulted in the Refactoring Browser, a tool that represents the state of the art in the field [Robe97a] In contrast, both Casais and Moore report on tools that optimise class hierarchies without human intervention [Casa92a] Moor96a] More recently, Schulz et al. ....
William F. Opdyke and Ralph E. Johnson, "Creating Abstract Superclasses by Refactoring," Proceedings CSC'93, ACM Press, 1993.
....stations. This obviously poses an additional range of problems concerning evolution and iterative development. After each customization, redesigns of the framework are considered. These redesigns can range from introducing new abstractions (introduction of new abstract classes) and factorizations [5] (e.g. making complex classes more reusable) up to more advanced refactorings such as applying design patterns [2] Even after the initial iterations, modifications to the framework still occur. Although these latter changes occur less frequently, their consequences are the hardest to assess. Most ....
Opdyke, W.F. and Johnson, R.E. Creating Abstract Superclasses by Refactoring. In Proceedings of CSC `93, ACM Press, New York, 1993, pp. 66-72.
....by our algorithm can be used for the same program understanding applications as those mentioned in [12] A third category of related work is that of techniques for restructuring class hierarchies for the sake of improving design, improving code reuse, and enabling reuse. Opdyke and Johnson [13, 14] present a number of behaviorpreserving transformations on class hierarchies, which they refer to as refactorings. The goal of refactoring is to improve design and enable reuse by factoring out common abstractions. This involves steps such as the creation of new superclasses, moving around ....
OPDYKE, W., AND JOHNSON, R. Creating abstract superclasses by refactoring. In ACM 1993 Computer Science Conference (1993).
....1993] about how persistent or transient types change during maintenance. Researchers studying maintenance of object oriented hierarchies, which are not necessarily persistent, cite modifying types in the hierarchy and reorganizing the hierarchy as frequently desirable activities [Johnson and Opdyke 1993; Opdyke and Johnson 1993; Lieberherr et al. 1991; Opdyke and Johnson 1990; Casais 1990; Mellor and Shlaer 1992] One can expect, however, that maintainers are reluctant to make radical changes to an object oriented hierarchy or any other persistent type or schema de nitions if those changes make ....
....how persistent or transient types change during maintenance. Researchers studying maintenance of object oriented hierarchies, which are not necessarily persistent, cite modifying types in the hierarchy and reorganizing the hierarchy as frequently desirable activities [Johnson and Opdyke 1993; Opdyke and Johnson 1993; Lieberherr et al. 1991; Opdyke and Johnson 1990; Casais 1990; Mellor and Shlaer 1992] One can expect, however, that maintainers are reluctant to make radical changes to an object oriented hierarchy or any other persistent type or schema de nitions if those changes make it dicult or impossible ....
Opdyke, W. F. and Johnson, R. E. 1993. Creating abstract superclasses by refactoring. In Proceedings of CSC '93: The ACM 1993 Computer Science Conference (February 1993).
....of a Magnet Code duplication is a well known problem in software maintenance, bloating up source code and complicating the extermination of errors. Tool support exists that helps to identify the duplicated code [JP93, Bak92, BYM 98, DRD99] Refactorings are a way to transform an application [OJ92] in a behavior preserving manner. Refactoring tools [RBJ97] support the elementary operations to transform code. Duplication is one important aspect of code where refactorings can be used to improve the source code. Very few tools, however, support corrections of systems plagued by duplicated ....
William F. Opdyke and Ralph E. Johnson. Creating abstract superclasses by refactoring. 1992.
....class hierarchies for the sake of improving design, improving code reuse, and enabling reuse. The overview article [7] presents 18 di erent methods, many of them process centered or dynamic analyses. The probably most well known method for static restructuring was introduced by Opdyke and Johnson [21, 20]. They present a number of behavior preserving transformations on class hierarchies, which they refer to as refactorings. The goal of refactoring is to improve design and enable reuse by factoring out common abstractions. This involves steps such as the creation of new superclasses, moving ....
....abstractions. This involves steps such as the creation of new superclasses, moving around methods and classes in a hierarchy, and a number of similar steps. Our techniques for analyzing the usage of a class hierarchy to nd design problems is in our opinion complimentary to the techniques of [21, 20]. Moore [19] presents a tool that automatically restructures inheritance hierarchies and refactors methods in Self programs. The goal of this restructuring is to maximize the sharing of expressions between methods, and the sharing of methods between objects in order to obtain smaller programs ....
W. Opdyke and R. Johnson. Creating abstract superclasses by refactoring. In ACM 1993 Computer Science Conference, 1993.
....for a program transformation tool. One criteria which also applied to C software is that users should be allowed to name new entities introduced through transformations. Opdyke first claimed that a series of refactorings could be used to create abstract classes and part whole relationships [Opd92, Opd93]. This was demonstrated for abstract classes [Tok95] and for part whole relationships in the CIM Works example from Chapter 6. Scherlis proposed refactorings which were shown to support a hypothetical derivation of the Java String and StringBuffer classes from an original null terminated string ....
....of incompatible interfaces. Section 4.2.1 Bridge Bridge decouples an abstraction from its implementation so that the two can vary independently. Sch98] a , Section 4.2.2 a. The example from [Sch98] is only partially automated because they were limited to the original refactorings from [Opd93]. A fully automated example is provided in Section 4.2.2. Builder Builder separates the construction of a complex object from its representation so that the same construction process can create different representations. Appendix B Strategy Strategy lets algorithms vary independently from the ....
[Article contains additional citation context not shown here]
W. F. Opdyke and R. E. Johnson. Creating abstract superclasses by refactoring. In ACM 1993 Computer Science Conference. February 1993. 135
....In Figure 2 the above formula is depicted in a commuting diagram. Lots of similar techniques have been defined and quite successfully used for structural notations, namely the normalization guidelines in relational database design [15] or re factoring functionality in class diagrams [16]. Also a refinement calculus for object structures has been defined in [17] And indeed we can find lots of rather simple rules that allow us to constructively modify a HMA document A 1 into A 2 and that ensure the formula given above. Almost all such rules come along with appropriate context ....
....but it is probably better to give them detailed descriptions of what to handle if documents are iteratively changed. This includes simple rules for adding, removing and adapting elements of the notation, as e.g. in [21] or refinement and transformation calculi for them as given in [11] 15] or [16]. Strictly spoken, tool vendors are not interested in what a notation means, but in how its symbols can be modified, and how code can be generated from it. However, tool vendors should not forget that the latter two depend on the first. The intended audience and their particular background ....
W. Opdyke, R. Johnson. Creating Abstract Superclasses by Refactoring. Technical report. University of Illinois and AT&T Bell Laboratories, 1993.
....hot spot is identified, extra methods and classes are introduced. 3.3.1 Data Hot Spots When the instance variables between applications are likely to differ, Pree prescribed the creation of abstract classes. Refactorings have repeatedly demonstrated the ability to create abstract classes [Opd93, Tok95, Rob97]. As an example, Pree and Sikora provide a Mailing System case study [Pre95] Figure 3.15 displays the initial state of its software architecture. In this system, Folder cannot be nested, and only TextDocument can be mailed. Their suggested architecture is displayed in Figure 3.16. Under the ....
W. F. Opdyke and R. E. Johnson. Creating Abstract Superclasses by Refactoring. In ACM 1993 Computer Science Conference. February 1993.
....types of transformations is to make sure that new objects are created of all introduced classes. Figure 22(c) shows a variant of class insertion, called false refactoring. Refactoring is a (sometimes automatic) technique for restructuring object oriented programs whose structure has deteriorated [22]. Refactoring is a two step process. First, it is detected that two, apparently independent classes, in fact implement similar behavior. Secondly, features common to both classes are moved into a new (possibly abstract) parent class. False refactoring is a similar operation, only it is performed ....
William F. Opdyke and Ralph E. Johnson. Creating abstract superclasses by refactoring. In Stan C. Kwasny and John F. Buck, editors, Proceedings of the 21st Annual Conference on Computer Science, pages 66--73, New York, NY, USA, February 1993. ACM Press. ftp://st.cs.uiuc.edu/pub/papers/ refactoring/refactoring-superclass% es.ps. 32
....the existing hierarchy. In fact, an extensive restructuring effort might be necessary to keep the hierarchy manageable after new leaves were added. This is usually called refactoring and has been identified as one of the major maintenance problems in object oriented modeling (for example, see [OJ93]) 22 Section D in the appendix discusses the fact that (dynamic) polymorphism and type specialization are strongly coupled in various programming languages. In particular, the first general goal in Section 5.1 can be achieved by type spezialization. Moreover, the second general goal can also be ....
William F. Opdyke and Ralph E. Johnson. Creating abstract superclasses by refactoring. ACM Computer Science Conference, 66--73, 1993.
....framework and identify the short comings. In [Opdyke 92] a set of behaviour preserving transformations, refactorings, has been identified that characterizes the code and low level design changes that may occur in the iterations. Especially, changes refactorings related to inheritance hierarchies [Opdyke Johnson 93] and component hierarchies [Johnson Opdyke 93] are of relevance for framework iteration just before releasing the first version of the framework. This iteration between the phases is very frequent and it involves a considerable amount of simple but tedious work that would benefit from tool ....
. W.F Opdyke, R.E Johnson, `Creating Abstract SuperClasses by Refactoring,' Proceedings of CSC'93: The ACM 1993 Computer Science Conference, February 1993.
....to the existing hierarchy. In fact, an extensive restructing effort might be necessary to keep the hierarchy manageable after new leaves were added. This is usually called refactoring and has been identified as one of the major maintenance problems in object oriented modeling (for example, see [OJ93]) 21 Section C in the appendix discusses the fact that (dynamic) polymorphism and type specialization are strongly coupled in various programming languages. In particular, the first general goal in Section 5.1 can be achieved by type spezialization. Moreover, the second general goal can also be ....
William F. Opdyke and Ralph E. Johnson. Creating abstract superclasses by refactoring. ACM Computer Science Conference, pages 66--73, 1993.
....statement pif (P F ) x=new C 1 q appears to create an instance of class C 1 . False refactoring. Figure 2(c) shows a variant of class insertion, called false refactoring. Refactoring is a (sometimes automatic) technique for restructuring objectoriented programs whose structure has deteriorated [15]. Refactoring is a two step process. First, it is detected Root C1 = V1 ; M1 ) C2 = V2 ; M2 ) V1 M1 V2 M2 C 1 C2 Root V1 M 1 C 1 = V 1 ; M 1 ) C2 = C1 Phi (V2 ; M2 ) Root V M Root M = M 1 Phi M 2 V = V 1 Phi V 2 (a) C = V; M) V 1 M 1 V2 M2 C 1 C2 C 2 = C 1 Phi (V 2 ; M 2 ) C ....
William F. Opdyke and Ralph E. Johnson. Creating abstract superclasses by refactoring. In Stan C. Kwasny and John F. Buck, editors, Proceedings of the 21st Annual Conference on Computer Science, pages 66--73, New York, NY, USA, February 1993. ACM Press. ftp://st.cs.uiuc.edu/pub/papers/ refactoring/refactoring-superclasses.ps.
....hot spot is identified, extra methods and classes are introduced. 3.3.1 Data Hot Spots When the instance variables between applications are likely to differ, Pree prescribed the creation of abstract classes. Refactorings have repeatedly demonstrated the ability to create abstract classes [Opd93, Tok95, Rob97]. As an example, Pree and Sikora provide a Mailing System case study [Pre95] Figure 3.15 displays the initial state of its software architecture. In this system, Folder cannot be nested, and only TextDocument can be mailed. Their suggested architecture is displayed in Figure 3.16. Under the ....
W. F. Opdyke and R. E. Johnson. Creating Abstract Superclasses by Refactoring. In ACM 1993 Computer Science Conference. February 1993.
.... Sons 1. Introduction Class organizations (schemas) evolve over the life cycle of object oriented systems for a variety of reasons. This issue has recently been a subject of increasing attention in the literature of both object oriented languages and especially object oriented database systems: [22, 19, 29, 8, 5, 10, 11, 12, 4, 21, 1, 3, 30, 34]. One of the most common forms of evolution involves the extension of an existing schema by addition of new classes of objects or the addition of attributes to the original objects. Sometimes class structures are reorganized even when the set of objects is unchanged. In this case the reorganiza ....
....if we note that it is not possible to find a solution by bringing two vertices THEORY AND PRACTICE OF OBJECT SYSTEMS (Year) into congruence that have different sets of reachable syntax vertices. 9. Related Work 9.1. Software Refactoring In their software refactory project, Opdyke and Johnson [28, 27, 29, 19] have worked on building a tool to support various aspects of object oriented program transformation, including the maintenance of behavioral consistency during schema evolution. Many of the code transformation issues they address are similar to the issues addressed here, and their solutions are ....
William F. Opdyke and Ralph E. Johnson. Creating abstract superclasses by refactoring. In Proceedings of CSC '93: The ACM 1993 Computer Science Conference, February 1993.
No context found.
William F. Opdyke and Ralph E. Johnson. "Creating Abstract Superclasses By Refactoring." In Proceedings of CSC `93: 1993 ACM Computer Science Conference, Indianapolis, Indiana, February 1993. Postscript: /pub/papers/refactoring/refactoring-superclasses.ps on st.cs.uiuc.edu.
....assume that operations will not change their name or be rewritten in any way, so the problem is one of deciding on a class hierarchy and where operations and variables are placed in it. If operations have to be renamed, split into pieces, or rewritten, then the problem becomes much harder[OJ93], and that is what happens when abstract superclasses are discovered in practice. This paper describes high level refactorings based on aggregations. These include how to reorganize an aggregate component hierarchy just as one might reorganize a class inheritance hierarchy and how to convert from ....
.... to be able to change software so that responsibility is shifted from one object (like the engine) to another (like the car) Previous work on refactorings for object oriented programs focused on reorganizing inheritance hierarchies and moving variables and functions within inheritance hierarchies [Ber91, Cas91, Cas92, OJ93]. But it is possible to move variables and functions between aggregates and components just like they can be moved between subclasses and superclasses. This paper not only describes refactorings that refine aggregations by moving variables and functions between aggregate and component classes, it ....
[Article contains additional citation context not shown here]
William F. Opdyke and Ralph E. Johnson. Creating abstract superclasses by refactoring. In Proceedings of CSC '93: The ACM 1993 Computer Science Conference, February 1993.
....applied in some cases to reduce or eliminate redundant parts of a program. The need for refactoring grew out of early experiences in reusing object oriented software, particularly in the Smalltalk community, as discussed by Johnson and Foote in [1] My research focused on refactoring C programs [2,3,4,5,6]. Currently, research is underway at the University of Illinois into refactoring Smalltalk programs [7,9] Don Roberts and I presented a tutorial on refactoring at the OOPSLA 95 [8] and OOPSLA 96 [10] conferences. Related research includes [12,13,14,15] 2.1 Legacy Constraints Must Be Addressed ....
William F. Opdyke and Ralph E. Johnson. "Creating Abstract Superclasses By Refactoring." In Proceedings of CSC '93: 1993 ACM Computer Science Conference, Indianapolis, Indiana, February 1993. Postscript: /pub/papers/refactoring/refactoring-superclasses.ps on st.cs.uiuc.edu.
....patterns, in sections three through five. Then, we define (in sections six and seven) two patterns that apply during the consolidation phase. The consolidation aspects of program evolution have been a focus of our research on object evolution [13] life cycles [14] reuse [16] and refactoring [17, 21, 22]. 1 Design guidelines for the consolidation phase have also been documented by others in, for example, 3, 7, 18, 23] Evolve Aggregations From Inheritance Hierarchies, also examined in this paper, is one of the third layer patterns that resolves the forces associated with the consolidation ....
....are defined. Suppose that DenseMatrix was define first, then later SparseMatrix was defined by copying DenseMatrix and modifying it. These two classes contain common behavior and duplicated code. An abstract superclass Matrix could be defined that captures the behavior common to these two classes [22]. 7.3 Solution Factor abstractions common to two or more classes into a common abstract superclass. Perform these changes in such a way as to ensure that the program will still work as it did before. Suppose that classes C1 and C2 share a common abstraction. An abstract superclass can be ....
[Article contains additional citation context not shown here]
William F. Opdyke and Ralph E. Johnson. Creating abstract superclasses by refactoring. In Proceedings of CSC '93: The ACM 1993 Computer Science Conference, February 1993.
No context found.
William F. Opdyke and Ralph E. Johnson. Creating abstract superclasses by refactoring, 1993.
No context found.
Opdyke, W., Johnson, R.: Creating abstract superclasses by refactoring. In: Proc. ACM Computer Science Conference, ACM Press (1993) 66--73
No context found.
W.F. Opdyke, R.E. Johnson. Creating abstract superclasses by refactoring, Proc. ACM Computer Science Conference, pp. 66-73, ACM Press, 1993.
No context found.
W. Opdyke and R. Johnson. Creating abstract superclasses by refactoring. In ACM 1993.
No context found.
W. F. Opdyke and R. E. Johnson. Creating Abstract Superclasses by Refactoring. Technical report, Department of Computer Science, University of Illinois and AT&T Bell Laboratories, 1993.
No context found.
William F. Opdyke and Ralph E. Johnson. Creating Abstract Superclasses By Refactoring. In Proceedings of CSC '93: 1993 ACM Computer Science Conference, Indianapolis, Indiana, February 1993.
No context found.
Opdyke W., Johnson R. Creating Abstract Superclasses by Refactoring. Technical Report. Dept. of Computer Science, University of Illinois and AT&T Bell Laboratories. 1993
No context found.
W. F. Opdyke and R. E. Johnson. Creating abstract superclasses by refactoring. In Proc. of the Conf. on 1993.
No context found.
W. Opdyke and R. Johnson. Creating abstract superclasses by refactoring. In Proc. ACM Computer Science Conference, pages 66--73. ACM Press, 1993.
No context found.
W. Opdyke, R. Johnson. Creating Abstract Superclasses by Refactoring. Technical Report. Dept. of Computer Science, University of Illinois and AT&T Bell Laboratories. 1993.
No context found.
W. F. Opdyke and R. E. Johnson. Creating Abstract Superclasses by Refactoring. Technical report, Department of Computer Science, University of Illinois and AT&T Bell Laboratories, 1993.
No context found.
W. Opdyke, R. Johnson. Creating Abstract Superclasses by Refactoring. Technical Report. Dept. of Computer Science, University of Illinois and AT&T Bell Laboratories. 1993
No context found.
R. E Johnson, W. F. Opdyke. "Creating Abstract Superclasses by Refactoring", In Proceedings of CSC'93, The ACM Computer Science Conference, February 1993.
No context found.
OpJ93 Opdyke, W.F., Johnson, R.E., Creating abstract superclasses by refactoring. In Kwasny, S.C., Buck, J.F. (eds): 1993 ACM Computer Science Conference (Indianapolis, Indiana, February, 16-18), ACM Press, 1993, pp.66-73.
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC