-
Notifications
You must be signed in to change notification settings - Fork 1
Conflict & Dependence Logic
Naming Conflict:
-
If the original method signatures are the same in the same class and the new signatures are different, then there is a naming conflict.
-
If the original method signatures are different and the new signatures are the same inside of the same class, then there is a naming conflict.
Accidental Overload Conflict:
- If the original names and signatures are different, and the new names are the same in the same class or classes with an inheritance relationship, then there is accidental overloading.
Accidental Override Conflict:
- If the methods originally do not override but override after the refactorings, this can be an accidental override.
Dependence
- There can be dependence if one refactoring type is rename method specifically, while the other is move method. In this case, if the original method signatures are the same and in the same class, then there is dependence (C1.m1 -> C2.m2 & C3.m3 -> C4.m4 & equalSignature(C1.m1, C3.m3)).
Dependence
- If the original class of the method refactoring is the same as the original class of the class refactoring, this is a case of ordering dependence. (For m1->m2 & c1->c2, if sameClass(classOf(m1),c1) then classOf(m2) = c2).
Naming Conflict:
-
If the original classes are the same and the new classes differ, either by name or location, then two conflicting refactorings were performed to the class that result in a naming conflict. (For c1->c2 and c3->c4, if sameClass(c1,c3) & !sameClass(c2,c4), then conflict).
-
If the original classes differ but are the same class after the refactorings, then there is a naming conflict. (For c1->c2 and c3->c4, if !sameClass(c1,c3) & sameClass(c2,c4), then conflict).
Dependence
- If the original class is the same (has the same name and package) and one class refactoring is a rename class and the other is a move class, then there is dependence.
Naming Conflict:
- If the refactored method and extracted method are in the same class and have the same signature, then there is a naming conflict.
Accidental Overload Conflict:
- If the refactored method and extracted method are in the same class, have the same name, but have different signatures, then there is accidental overloading. Additionally, if they have the same name and different signatures in classes that have an inheritance relationship, this is an example of accidental inheritance overloading.
Accidental Override Conflict:
- If the refactored method and extracted method are in classes that inherit each other and the method signatures are the same, then htere is accidental overriding.
Dependence
- If the original method has the same signature as the source method and they exist in the same class, then there is ordering dependence.
Dependence
-
If the class of the source method is the same as the original class in the class refactoring, then there is ordering dependence. (For s->e and c1->c2, if sameClass(classOf(s),c1), then classOf(e) = c2).
-
If the class of the extracted method is the same as the original class in the class refactoring, then there is ordering dependence. (For s->e and c1->c2, if sameClass(classOf(e),c1), then classOf(e) = c2).
Naming Conflict:
- If the extracted methods are in the same class and have the same signature, then there is a naming conflict.
Accidental Overload Conflict:
-
If the extracted Methods are in the same class and have the same name but have different signatures, then there is an accidental overload conflict.
-
If the extracted methods have the same name and are in different classes that have an inheritance relation but have different signatures, then there is an accidental inheritance overload conflict.
Accidental Override Conflict:
- If the extracted methods are in different classes and have the same signature, then there is an accidental override conflict.
Overlapping Fragments Conflict:
- If the extract method refactorings have the same source method, we need to check for overlapping code fragments. If any code fragment in one extracted method equals a code fragment in the other, then there are overlapping code fragments and performing both refactorings will result in a conflict.
Naming Conflict:
- If the original methods are the same, then this has to be a conflict because the same method is being deleted on one branch while being moved or renamed on the other branch. (For m1 inlined to m2 & m3 -> m4, if sameMethod(m1,m3), then conflict).
Dependence
- If the destination method of the inline method refactoring is moved or renamed by the other branch, then this is a dependence relationship. (For m1 inlined to m2 & m3 -> m4, if sameMethod(m2,m3), then m1 inlined to m3 & m3 -> m4).
Dependence
- If the destination method of the inline method refactoring's class is renamed, moved, or both, then there is a dependence relationship. (For m1 inlined to m2 & c1 -> c2, if sameClass(classOf(m2),c1), then m1 in c1 inlined to m2 in c2).
- No interaction.
Dependence
- If the destination method on one branch is the source method on the other, then there is a dependence relationship. (For m1 inlined to m2 & m3 inlined to m4, if sameMethod(m2,m3), then we need to replay m1 inlined to m2 before m3 inlined to m4).
Naming Conflict:
-
If the name of the fields are the same in the same class and after being refactored, the field names are different or in different classes, a naming conflict occurred (c1.f1 -> c1.f2 & c1.f1 -> c1.f3 OR c1.f1 -> c2.f1 & c1.f1 -> c1.f2).
-
If two different fields are refactored to the same name in the same class, a naming conflict occurred (c1.f1 -> c2.f2 & c3.f3 -> c2.f2).
Accidental Shadowing Conflict:
- If two fields in two different classes that have an inheritance relationship are refactored to the same name, it is possible that accidental shadowing has happened (c1.f1 -> c1.f2 & c2.f3 -> c2.f2 Where isSubSuperClass(c1,c2)).
Dependence
- If the refactorings are exclusively move field and rename field and they are the same original field, then they can be combined (c1.f1 -> c1.f2 & c1.f1 -> c2.f1, then c1.f1 -> c2.f2).
- No interaction.
Naming Conflict
-
If the original method involved in the pull up method refactoring is moved to a separate location or renamed (C1.m1 pulled up to C2.m1 & C1.m1 -> C3.m3).
-
If a pull up method refactoring results in the same method signature as a move + rename method refactoring (C1.m1 pulled up to C2.m1 & C3.m2 -> C2.m1).
Accidental Overload Conflict
- If a pull up method refactoring and move + rename method refactoring result in two methods in the same class with the same name but different signatures.
Accidental Override Conflict
- If a pull up method refactoring and move + rename method refactoring occur in two classes in an inheritance relationship and result in an override relationship that did not previously exist.
Naming Conflict
- If a pull up method refactoring and extract method refactoring result in the same method signature in the same class (C1.m1 pulled up to C2.m1 & C2.m1 extracted from C2.m2).
Accidental Overload Conflict
- If a pull up method refactoring and extract method refactoring result in the same method name in the same class with different signatures (C1.m1 pulled up to C2.m2 & C2.m3 extracted from C2.m4 & !equalSignatures(C2.m2, C2.m3)).
Accidental Override Conflict
- If a pull up method refactoring and extract method refactoring result in two methods having the same signature in different classes that have an inheritance relationship (C1.m1 pulled up to C2.m2 & C3.m3 extracted from C3.m4 & equalSignatures(C2.m2, C3.m3) & isSuperClass(C2,C3)).
Naming Conflict
-
If a method is pulled up and inlined (C1.m1 pulled up to C2.m2 & C1.m1 inlined to C1.m3).
-
Note: This is the only conflict because inline method deletes the original method being inlined, so it cannot result in an override or overload conflict.
- No interaction.
Naming Conflict
-
If the original method involved in the push down method refactoring is moved to a separate location or renamed (C1.m1 pushed down to C2.m2 & C1.m3 -> C3.m4 & equalSignature(m1, m3)).
-
If a push down method refactoring results in the same method signature as a move + rename method refactoring (C1.m1 pushed down to C2.m2 & C3.m3 -> C4.m4 & C2 = C4 & equalSignature(m2, m4)).
Accidental Overload Conflict
- If a push down method refactoring and move + rename method refactoring result in two methods in the same class with the same name but different signatures (C1.m1 pushed down to C2.m2 & C3.m3 -> C4.m4 & C2 = C4 & !equalSignature(m2, m4) & sameName(m2, m4)).
Accidental Override Conflict
- If a push down method refactoring and move + rename method refactoring occur in two classes in an inheritance relationship and result in an override relationship that did not previously exist (C1.m1 pushed down to C2.m2 & C3.m3 -> C4.m4 & isSuperClass(C2, C4) & equalSignature(m2, m4)).
Naming Conflict
- If a push down method refactoring and extract method refactoring result in the same method signature in the same class (C1.m1 pushed down to C2.m2 & C3.m3 extracted from C4.m4 & equalSignature(C2.m2, C3.m3).
Accidental Overload Conflict
- If a push down method refactoring and extract method refactoring result in the same method name in the same class with different signatures (C1.m1 pushed down to C2.m2 & C3.m3 extracted from C4.m4 & C2 = C3 & !equalSignatures(m2, m3) & sameName(m2, m3)).
Accidental Override Conflict
- If a push down method refactoring and extract method refactoring result in two methods having the same signature in different classes that have an inheritance relationship (C1.m1 pushed down to C2.m2 & C3.m3 extracted from C4.m4 & equalSignatures(m2, m3) & isSuperClass(C2,C3)).
Naming Conflict
-
If a method is pushed down and inlined (C1.m1 pushed down to C2.m2 & C1.m1 inlined to C1.m3).
-
Note: This is the only conflict because inline method deletes the original method being inlined, so it cannot result in an override or overload conflict.
- No interaction.
Naming Conflict
-
If the same method is pushed down on one branch and pulled up on the other branch (C1.m1 pulled up to C2.m2 & C3.m3 pushed down to C4.m4 & equalSignature(C1.m1, C3.m3) & !equalSignature(C2.m2, C4.m4)).
-
If a method is pushed down on one branch and a method is pushed up on the other branch and result in the same signature in the same class (C1.m1 pulled up to C2.m2 & C3.m3 pushed down to C4.m4 & !equalSignature(C1.m1, C3.m3) & equalSignature(C2.m2, C4.m4)).
Naming Conflict
-
If the original field involved in the pull up field refactoring is moved to a separate location or renamed (C1.f1 pulled up to C2.f1 & C1.f1 -> C3.f3).
-
If a pull up field refactoring results in the same field signature as a move + rename field refactoring (C1.f1 pulled up to C2.f1 & C3.f2 -> C2.f1).
Accidental Shadowing Conflict
- If a pull up field refactoring and move + rename field refactoring result in classes that have an inheritance relationship and a shadow relationship that originally wasn't there (C1.f1 pulled up to C2.f1 & C3.f2 -> C4.f3 & isSuperClass(C2,C4)).
- No interaction.
- No interaction.
- No interaction.
Naming Conflict
-
If the same field is pushed down on one branch and pulled up on the other branch (C1.f1 pulled up to C2.f2 & C3.f3 pushed down to C4.f4 & equalSignature(C1.f1, C3.f3) & !equalSignature(C2.f2, C4.f4)).
-
If a field is pushed down on one branch and a field is pushed up on the other branch and result in the same field in the same class (C1.f1 pulled up to C2.f2 & C3.f3 pushed down to C4.f4 & !equalSignature(C1.f1, C3.f3) & equalSignature(C2.f2, C4.f4)).
Naming Conflict
-
If the rename package refactorings rename the original package to two different names (p1 -> p2 & p1 -> p3).
-
If the rename package refactorings rename two packages to the same name (p1 -> p3 & p2 -> p3).
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
- No interaction.
-
If two different parameters are renamed to the same parameter in the same method (C1.m1.p1 -> C2.m2.p2 & C3.m3.p3 -> C4.m4.p4 & equalSignature(C1.m1, C3.m3) & p1 != p3 & p2 = p4).
-
If the same parameter is renamed to two different names (C1.m1.p1 -> C2.m2.p2 & C3.m3.p3 -> C4.m4.p4 & equalSignature(C1.m1, C3.m3) & p1 = p3 & p2 != p4).