在我的一次面试中，有人问我:“我们是否可以实例化一个抽象类?”
我的回答是:“没有。我们不能”。但是，面试官告诉我:“错了，我们可以。”
我对此进行了一些争论。然后他让我自己在家试试。
abstract class my {
public void mymethod() {
System.out.print("Abstract");
}
}
class poly {
public static void main(String a[]) {
my m = new my() {};
m.mymethod();
}
}
在这里，我正在创建我的类的实例和调用抽象类的方法。有人能给我解释一下吗?我的面试真的错了吗?
当前回答
实例化一个抽象类是不可能的。 你真正能做的是，在一个抽象类中实现一些通用方法，而让其他方法未实现(将它们声明为抽象)，并让具体的派生程序根据需要实现它们。 然后您可以创建一个工厂，该工厂返回这个抽象类的实例(实际上是他的实现者)。然后在工厂中决定选择哪个实现者。这被称为工厂设计模式:
public abstract class AbstractGridManager {
private LifecicleAlgorithmIntrface lifecicleAlgorithm;
// ... more private fields
//Method implemented in concrete Manager implementors
abstract public Grid initGrid();
//Methods common to all implementors
public Grid calculateNextLifecicle(Grid grid){
return this.getLifecicleAlgorithm().calculateNextLifecicle(grid);
}
public LifecicleAlgorithmIntrface getLifecicleAlgorithm() {
return lifecicleAlgorithm;
}
public void setLifecicleAlgorithm(LifecicleAlgorithmIntrface lifecicleAlgorithm) {
this.lifecicleAlgorithm = lifecicleAlgorithm;
}
// ... more common logic and getters-setters pairs
}
具体实现者只需要实现声明为抽象的方法，但可以访问在抽象类中那些类中实现的逻辑，这些类不是声明为抽象的:
public class FileInputGridManager extends AbstractGridManager {
private String filePath;
//Method implemented in concrete Manager implementors
abstract public Grid initGrid();
public class FileInputGridManager extends AbstractGridManager {
private String filePath;
//Method implemented in concrete Manager implementors
abstract public Grid initGrid();
public Grid initGrid(String filePath) {
List<Cell> cells = new ArrayList<>();
char[] chars;
File file = new File(filePath); // for example foo.txt
// ... more logic
return grid;
}
}
最后，工厂看起来是这样的:
public class GridManagerFactory {
public static AbstractGridManager getGridManager(LifecicleAlgorithmIntrface lifecicleAlgorithm, String... args){
AbstractGridManager manager = null;
// input from the command line
if(args.length == 2){
CommandLineGridManager clManager = new CommandLineGridManager();
clManager.setWidth(Integer.parseInt(args[0]));
clManager.setHeight(Integer.parseInt(args[1]));
// possibly more configuration logic
...
manager = clManager;
}
// input from the file
else if(args.length == 1){
FileInputGridManager fiManager = new FileInputGridManager();
fiManager.setFilePath(args[0]);
// possibly more method calls from abstract class
...
manager = fiManager ;
}
//... more possible concrete implementors
else{
manager = new CommandLineGridManager();
}
manager.setLifecicleAlgorithm(lifecicleAlgorithm);
return manager;
}
}
AbstractGridManager的接收者将调用他身上的方法并获得在具体的下降器中实现的逻辑(部分在抽象类方法中实现)，而不知道他得到的具体实现是什么。这也称为控制反转或依赖注入。
其他回答
实际上，我们不能直接创建抽象类的对象。我们创建的是一个抽象调用的引用变量。引用变量用于引用继承抽象类的类的对象，即抽象类的子类。
抽象类不能被实例化，但可以被子类化。参见这个链接
最好的例子是
虽然Calendar类有一个抽象方法getInstance()，但是当你说Calendar calc=Calendar.getInstance();
calc引用类GregorianCalendar的类实例为“GregorianCalendar extends Calendar”
事实上，匿名内部类型允许您创建抽象类的一个无名称子类和它的一个实例。
实例化一个抽象类是不可能的。 你真正能做的是，在一个抽象类中实现一些通用方法，而让其他方法未实现(将它们声明为抽象)，并让具体的派生程序根据需要实现它们。 然后您可以创建一个工厂，该工厂返回这个抽象类的实例(实际上是他的实现者)。然后在工厂中决定选择哪个实现者。这被称为工厂设计模式:
public abstract class AbstractGridManager {
private LifecicleAlgorithmIntrface lifecicleAlgorithm;
// ... more private fields
//Method implemented in concrete Manager implementors
abstract public Grid initGrid();
//Methods common to all implementors
public Grid calculateNextLifecicle(Grid grid){
return this.getLifecicleAlgorithm().calculateNextLifecicle(grid);
}
public LifecicleAlgorithmIntrface getLifecicleAlgorithm() {
return lifecicleAlgorithm;
}
public void setLifecicleAlgorithm(LifecicleAlgorithmIntrface lifecicleAlgorithm) {
this.lifecicleAlgorithm = lifecicleAlgorithm;
}
// ... more common logic and getters-setters pairs
}
具体实现者只需要实现声明为抽象的方法，但可以访问在抽象类中那些类中实现的逻辑，这些类不是声明为抽象的:
public class FileInputGridManager extends AbstractGridManager {
private String filePath;
//Method implemented in concrete Manager implementors
abstract public Grid initGrid();
public class FileInputGridManager extends AbstractGridManager {
private String filePath;
//Method implemented in concrete Manager implementors
abstract public Grid initGrid();
public Grid initGrid(String filePath) {
List<Cell> cells = new ArrayList<>();
char[] chars;
File file = new File(filePath); // for example foo.txt
// ... more logic
return grid;
}
}
最后，工厂看起来是这样的:
public class GridManagerFactory {
public static AbstractGridManager getGridManager(LifecicleAlgorithmIntrface lifecicleAlgorithm, String... args){
AbstractGridManager manager = null;
// input from the command line
if(args.length == 2){
CommandLineGridManager clManager = new CommandLineGridManager();
clManager.setWidth(Integer.parseInt(args[0]));
clManager.setHeight(Integer.parseInt(args[1]));
// possibly more configuration logic
...
manager = clManager;
}
// input from the file
else if(args.length == 1){
FileInputGridManager fiManager = new FileInputGridManager();
fiManager.setFilePath(args[0]);
// possibly more method calls from abstract class
...
manager = fiManager ;
}
//... more possible concrete implementors
else{
manager = new CommandLineGridManager();
}
manager.setLifecicleAlgorithm(lifecicleAlgorithm);
return manager;
}
}
AbstractGridManager的接收者将调用他身上的方法并获得在具体的下降器中实现的逻辑(部分在抽象类方法中实现)，而不知道他得到的具体实现是什么。这也称为控制反转或依赖注入。
技术部分在其他答案中已经很好地涵盖了，它主要以: “他错了，他什么都不懂，让他加入SO，把一切都弄清楚:)”
我想说明一个事实(在其他回答中已经提到过)，这可能是一个压力问题，也是许多面试官更多了解你以及你如何应对困难和不寻常情况的重要工具。通过给你错误的密码，他可能想看看你是否会反驳。要知道在类似的情况下，你是否有信心站起来对抗你的前辈。
附注:我不知道为什么，但我有一种感觉，面试官已经读了这篇文章。
上面实例化了一个匿名的内部类，它是my抽象类的子类。严格来说，它并不等同于实例化抽象类本身。OTOH，每个子类实例都是其所有超类和接口的实例，因此大多数抽象类确实是通过实例化它们的一个具体子类来实例化的。
如果面试官只是说“错了!”而没有解释，并给出了这个例子作为一个独特的反例，我认为他不知道自己在说什么。
