Wave,
Your idea can no doubt be made to work after a fashion. One complication is that the INavigate type held as a field can't access other fields and methods of the host type except by getting it as a parameter and again having to incorporate code to determine the type and treat it specially.
You should want all of the type specific code to be implemented within the type rather than in other types.
Another approach is to type the parameter as just an object. Then have a big test for each type that you want to implement the psuedo interface, cast to that type and then invoke the method.
Although the types implement methods with the same name and parameter types they are not the same in terms of the method signature because they belong to unrelated types.
Can sort of work but has a lot of drawbacks compared to properly supported interfaces:
- More code to write
- Less 'type safety'. With an interface you don't need the testing and default exception because only types that implement the interface can be passed as a parameter. The checking is at compile time rather than run time.
- Doesn't help with external modules where you can't add code to support your additional types
As complexity rises in a project, I've found that interfaces become increasingly important to keep the design clean and flexible while also keeping code size down immensely.
There are basic OO things that I'd give higher priority to than interfaces as BM matures (see my reply to Mark on 2005-06-18). I do hope though that interfaces could be implemented somewhere along the track.
TNet sounds good. At a guess, something like the Smooth Sync feature would be ideal to implement as an interface. You might say have to implement a method in objects to predict their near term position and another to resolve differences between the local and remote copies.
Your idea can no doubt be made to work after a fashion. One complication is that the INavigate type held as a field can't access other fields and methods of the host type except by getting it as a parameter and again having to incorporate code to determine the type and treat it specially.
You should want all of the type specific code to be implemented within the type rather than in other types.
Another approach is to type the parameter as just an object. Then have a big test for each type that you want to implement the psuedo interface, cast to that type and then invoke the method.
Type TPilot Method PlanCourse:TCourse(object ride) Local ship:TShip = TShip(ride) if (ship) if (ship.Aggressive) return ship.TakeShortestRoute(from, to) return ship.TakeSafestRoute(from, to) endif Local tank:TTank = TTank(ride) if (tank) return tank.TakeShortestRoute(from, to) Local road:TRoadBuilder = TRoadBuilder(ride) if (road) return road.TakeScenicRoute(from, via, to) throw "Type not supported by TPilot" end method
Although the types implement methods with the same name and parameter types they are not the same in terms of the method signature because they belong to unrelated types.
Can sort of work but has a lot of drawbacks compared to properly supported interfaces:
- More code to write
- Less 'type safety'. With an interface you don't need the testing and default exception because only types that implement the interface can be passed as a parameter. The checking is at compile time rather than run time.
- Doesn't help with external modules where you can't add code to support your additional types
As complexity rises in a project, I've found that interfaces become increasingly important to keep the design clean and flexible while also keeping code size down immensely.
There are basic OO things that I'd give higher priority to than interfaces as BM matures (see my reply to Mark on 2005-06-18). I do hope though that interfaces could be implemented somewhere along the track.
TNet sounds good. At a guess, something like the Smooth Sync feature would be ideal to implement as an interface. You might say have to implement a method in objects to predict their near term position and another to resolve differences between the local and remote copies.