Comment Virtual Classes in Java, C++, etc. (Score 1) 523
While the author is quite correct that there is a need to move towards a higher layer of abstraction that simply "classes", he neglects to consider that such constructs already exist in many languages.
Consider his model/view example (which by the way neglects the importance of a third controller class). Suppose you wrote a framework that manipulated Models and Views, and you wanted to allow extension.
This is a perfect situation for applying the AbstractFactory design pattern. (See Design Patterns, Elements of Reusable Object Oriented Design for more information). Essentially, here is the solution in Java:
public interface ModelViewFactory {
public Model createModel();
public View createView();
}
public class SpreadsheetModelViewFactory {
public Model createModel() {
return new SpreadsheetModel();
}
public View createView() {
return new SpreadsheetView();
}
}
Now let's consider the DukeNukeEmEngine example in Java:
public class DukeNukeEmEngineFactory extends UnrealEngineFactory {
public Actor createActor() {
return new UnrealEngineActor() {
private Object newVariable;
};
}
}
Viola, we have now added a new variable to hundreds of thousands of actors in the system. Regarding persistence, it is very easy to develop frameworks using introspection to easily support forward/backward compatibility.
Now let me pose a challenge to Tim: suppose I wanted to write SuperEngine which took some of the best features of two different implementations of Engine? For example suppose I want DukeNukeEm.Actor, and Quake.Map? In Java, I can easily write:
public class SuperEngineFactory implements EngineFactory {
public Actor createActor() {
return _dukeNukeEm.createActor();
}
public Map createMap() {
return _quake.createMap();
}
private EngineFactory _dukeNukeEm = new DukeNukeEmFactory();
private EngineFactory _quake = new QuakeFactory();
}
While the article does raise some interesting points, it also shamelessly plugs UnrealScript, a vertical language particularly tailored towards a game engine, touting features that could easily be be built into many existing languages.
In truth, there is no such thing as a perfect language and new features will continue to evolve over time. However let's not forget that specialization comes at the cost of generalization. When was the last time you heard someone wanting to write a spreadsheet in UnrealScript?
My .012 cents...
Consider his model/view example (which by the way neglects the importance of a third controller class). Suppose you wrote a framework that manipulated Models and Views, and you wanted to allow extension.
This is a perfect situation for applying the AbstractFactory design pattern. (See Design Patterns, Elements of Reusable Object Oriented Design for more information). Essentially, here is the solution in Java:
public interface ModelViewFactory {
public Model createModel();
public View createView();
}
public class SpreadsheetModelViewFactory {
public Model createModel() {
return new SpreadsheetModel();
}
public View createView() {
return new SpreadsheetView();
}
}
Now let's consider the DukeNukeEmEngine example in Java:
public class DukeNukeEmEngineFactory extends UnrealEngineFactory {
public Actor createActor() {
return new UnrealEngineActor() {
private Object newVariable;
};
}
}
Viola, we have now added a new variable to hundreds of thousands of actors in the system. Regarding persistence, it is very easy to develop frameworks using introspection to easily support forward/backward compatibility.
Now let me pose a challenge to Tim: suppose I wanted to write SuperEngine which took some of the best features of two different implementations of Engine? For example suppose I want DukeNukeEm.Actor, and Quake.Map? In Java, I can easily write:
public class SuperEngineFactory implements EngineFactory {
public Actor createActor() {
return _dukeNukeEm.createActor();
}
public Map createMap() {
return _quake.createMap();
}
private EngineFactory _dukeNukeEm = new DukeNukeEmFactory();
private EngineFactory _quake = new QuakeFactory();
}
While the article does raise some interesting points, it also shamelessly plugs UnrealScript, a vertical language particularly tailored towards a game engine, touting features that could easily be be built into many existing languages.
In truth, there is no such thing as a perfect language and new features will continue to evolve over time. However let's not forget that specialization comes at the cost of generalization. When was the last time you heard someone wanting to write a spreadsheet in UnrealScript?
My