Lemmings Boards > Tech & Research
Object-oriented design with Simon
Simon:
OO with Simon, part 4
The clone() pattern
How to copy lixes around?
Deep copies (create a new object) instead of shallow copies (make new reference to existing object) are handy to implement savestates. We don't want this:
class Lemming:
Job job
copyConstructor(Lemming l):
this.job = l.job
This would make a new reference to the old job, not what we want.
Now, a problem: How to make a deep copy of the old job? new is not polymorphic. The following code does not work.
class Lemming:
Job job
copyConstructor(Lemming l):
job = new Job(l.job) // error: Job is abstract, can't instantiate
abstract class Job:
abstract void perform()
copyConstructor(Job):
...
class Builder : Job:
copyConstructor(Builder b):
super(b)
...
Even if Lemming l is a builder, feeding l to Lemming.copyConstructor will fail to produce a new Builder job. There are languages with polymorphic new, but C++, Java, D are not among them. We're doing hard-ass 1990-style object-orientation here.
The standard solution is to write our own polymorphic method, which is idiomatically called clone().
class Lemming:
Job job
copyConstructor(Lemming l):
job = l.job.clone() // leave it to polymorphism to instantiate the correct Job subclass
abstract class Job:
abstract void perform()
abstract Job clone()
copyConstructor(Job): // if Job has any fields, we still need this
...
class Builder : Job:
copyConstructor(Builder b):
super(b) // initialize the fields of Job
... // initialize the fields of Builder
override Builder clone():
return new Builder(this)
This code produces the desired effect: The game can make copies of lixes, unconcerned of what jobs they have. A lix, upon copy-construction, will instantiate a copy of the correct Job sublcass.
If your langague forbids overriding Job clone() with method signature Builder clone(), then instead override as Job clone() in the subclass. The above code will keep its meaning. D has covariant return types, which means that I may override as Builder clone(), and instantly qualify as a nerd for sneaking that term into a social discussion.
A downside of the clone pattern is verbosity. You have to define both copy-constructor and clone method in each subclass. And you have to define an overridden clone method in each subclass. Even if your language assists you with powerful compile-time code generation, you have to do it in every subclass.
-- Simon
NaOH:
In C++, if Job is not stored as a pointer, won't the lemming be deep-copied automatically? The Job copy-constructor will be called implicitly and by default it will copy over each field.
Simon:
In C++, if the lemming's job field is Job instead of Job*, there would be no polymorphism possible. Such a field cannot hold a builder job. Even when Builder doesn't introduce new fields, and therefore sizeof(Job) == sizeof(Builder), the memory layout doesn't necessarily match, for each object carries its own vtbl. (wrong, will make extra post). If we do this in C++:
Lemming lem;
Job job;
job = Builder(lem);
...the Builder would be implicitly converted to Job, then assigned to the static field.
This is a reason why Delphi and D make a semantic difference between struct/record with value semantics, and classes with reference semantics.
Complete example:
#include <iostream>
class A {
public:
virtual void bark() { std::cout << "Hello from A\n"; }
};
class B : public A {
public:
virtual void bark() { std::cout << "Hello from B\n"; }
};
int main()
{
A val = B();
val.bark();
A* ptr = new B();
ptr->bark();
}
$ ./a.out
Hello from A
Hello from B
-- Simon
Simon:
OO with Simon, part 5
Virtual function tables, specific to C++
Here are some declarations in C++.
class A { };
class B { int field; };
class C { int field; void method() { } };
class D { int field; virtual void method() { } };
How long are the objects of type A, B, C, D in bytes each? On the workstation in my office here, g++ -v says: Target: i686-linux-gnu, gcc version 4.6.3. The sizes of the objects are 1, 4, 4, 8.
The interesting difference is that existence of at least one virtual method puts an extra pointer into the class. This is a vtbl pointer. It points into a static vtbl, where the function pointers sit who enable dynamic dispatch. The vtbl is static in the C++-class sense of static, i.e., there is one vtbl per class.
A statically dispatched method is hard-wired to call the same method every time. On dispatching a method call dynamically, the code doesn't jump into a function immediately; instead it dereferences the vtbl pointer and jumps into where the vtbl points. In a class hierarchy, different classes may point to different vtbls. That's C++'s implementation of polymorphism.
Now, fields with manual function pointers instead of using the static vtbl would enable the following:
class Lemming {
void (*jobMethod)(Lemming&);
void perform() { jobMethod(*this); }
};
void performWalking(Lemming&) { ... }
void performBuilding(Lemming&) { ... }
Lemming lem;
lem.jobMethod = &performBuilding;
Lemming another = lem;
This would value-copy the function pointer, as NaOH has suggested. This is a difference to vtbls: In the example right here, each object points to a method directly. With vtbls, we point to a static immutable vtbl, which points to a method.
Yes, this obviates the need for the clone pattern. I haven't thought about upsides or downsides much yet.
-- Simon
namida:
I don't quite follow the technical terms or C-type code here; but I believe something like what you're describing is already how NeoLemmix handles different actions.
--- Code: (LemGame.pas 1353~1379 (in TLemmingGame.Create)) ---// initialized once - this comment NOT present in actual LemGame.pas file, added for clarity here
LemmingMethods[baNone] := nil;
LemmingMethods[baWalking] := HandleWalking;
LemmingMethods[baJumping] := HandleJumping;
LemmingMethods[baDigging] := HandleDigging;
LemmingMethods[baClimbing] := HandleClimbing;
LemmingMethods[baDrowning] := HandleDrowning;
LemmingMethods[baHoisting] := HandleHoisting;
LemmingMethods[baBuilding] := HandleBuilding;
LemmingMethods[baBashing] := HandleBashing;
LemmingMethods[baMining] := HandleMining;
LemmingMethods[baFalling] := HandleFalling;
LemmingMethods[baFloating] := HandleFloating;
LemmingMethods[baSplatting] := HandleSplatting;
LemmingMethods[baExiting] := HandleExiting;
LemmingMethods[baVaporizing] := HandleVaporizing;
LemmingMethods[baBlocking] := HandleBlocking;
LemmingMethods[baShrugging] := HandleShrugging;
LemmingMethods[baOhnoing] := HandleOhNoing;
LemmingMethods[baExploding] := HandleExploding;
LemmingMethods[baToWalking] := HandleWalking; //should never happen anyway
LemmingMethods[baPlatforming] := HandlePlatforming;
LemmingMethods[baStacking] := HandleStacking;
LemmingMethods[baStoning] := HandleStoneOhNoing;
LemmingMethods[baStoneFinish] := HandleStoneFinish;
LemmingMethods[baSwimming] := HandleSwimming;
LemmingMethods[baGliding] := HandleGliding;
LemmingMethods[baFixing] := HandleFixing;
--- End code ---
--- Code: (LemGame.pas 6149~6150 (in TLemmingGame.HandleLemming)) --- Method := LemmingMethods[L.LemAction];
Result := Method(L);
--- End code ---
I'm not sure if there's a reason why the former actually initializes these values in the code, rather than using constants (it's like this in vanilla Lemmix too, and since it works, I never attempted to change it). Possibly Delphi doesn't allow referencing methods in constants.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version