I have an abstract class, which I decided to delete, since it did nothing but add boilerplate and needless complexity to the code:
abstract class AbstractClassToDelete {
fun someFun() {...}
}
Unfortunately, it happenes so that several hundred of classes (almost 500 classes), are inheriting this abstract class, so in a nutshell they all look like this:
import com.example.AbstractClassToDelete
class SomeClass: AbstractClassToDelete {
override fun someFun() {...}
...
}
After I delete the abstract class, I'd like the override functions to become normal (public) functions instead, without any changes to the insides:
// delete the import
class SomeClass { // delete inheritence
fun someFun() {...} // delete override keyword
...
}
Doing this by hand will take days, I wish this could be automated. I'm using Android Studio, but I guess this task could be done elsewhere. After all, it's just a bunch of text files.
CodePudding user response:
IntelliJ IDEA and Android Studio can do the function part of this.
Put the cursor in your abstract class somewhere. Then Right Click -> Refactor -> Push Members Down...
Check the boxes next to all your abstract functions and press OK. This deletes the abstract function from the superclass and the override
keyword from all the children.
I don't know of any way to do the classes. But if your class is in the same package as its subclasses, you could refactor-rename it (Shift F6) to "Any" and then simply delete the code of the class. Now all your classes will be subclasses of the standard library Any. They will be unnecessarily calling the superconstructor of Any, but that won't harm anything. This is already implicitly done anyway.
If it bothers you, you could write a script to remove that part by processing the kt files as text. Probably simpler than the script necessary to remove the override
from the appropriate places.
CodePudding user response:
I haven't tried this, but here's an idea that might work:
- Take a copy of the code in your concrete subclass.
- Delete it from your IDE. (Any references to it will then give an error.)
- Refactor your abstract superclass, renaming and moving it so that it has the same name and package as the concrete subclass. (This should update all references in the rest of your codebase.)
- Edit the moved class, pasting in the code of the concrete subclass. (You may be able to do this via a rollback in our source-control system.)
You should then end up with the same concrete subclass you started with, but the rest of the codebase referring to it rather than the no-longer-existing abstract superclass.
(One potential issue is that if you're using a source-code control system such as git, that may show an unnecessary deletion and move/rename. But you should be able to fix that by doing a rollback before committing anything.)