Re: [Housebot-developers] SF.net SVN: housebot: [466]trunk/housebot/src

[Jason H. <jas...@gm...>]

Phil G wrote:
> > I'll accept all the hits as to how horrible 
> GTPFunctionObjectTemplate.hpp is, but I'll
> > also argue that it's as elegant as you can get with respect to the 
> C++ language
> > and this type of feature.  Repetitively typing the same code over and 
> over again
> > is error prone and tough to maintain.  I guess it's possible to add 
> more extensive
> > commentary to it?  I looked at the implementation of boost::function 
> and the
> > macro based thing is the way that they did it.
>  
> The root of the problem is mapping varying number of and 
> differently typed arguments to C++
> function method calls.  Since we both admit that C++ is not built for 
> this, I would suggest
> we approached the problem in a different way by simply passing whole 
> argument
> list as a single parameter to the function and let the function do the 
> parsing with helper
> methods. Similar to my 2nd iteration of GTP for HouseBot, except we 
> add boost functions.
> I think this helps get around the object base to derived class 
> convertion.
>  
> And I still think it's a good idea to always pass the "interface" to 
> the "GoBoard" to every
> GTP function, regardless if it used or not. In essence, I'm arguing to 
> use the "Facade"
> structural design pattern to reduce complexity between components. 

You're arguing to use "GoBoard" as a facade which is more or less 
distinct from the argument as to if the GTP library should use the 
facade or not.

PS: For those (like me) who didn't know the facade design pattern, see:
http://en.wikipedia.org/wiki/Fa%C3%A7ade_pattern

The biggest question in my mind is if the GoBoard is more like the 
adapter pattern described briefly on wikipedia as "'adapts' one 
interface for a class into one that a client expects"

The reason I like my GTP design so much (despite ugly internal C++ code) 
is that it has extremely low coupling.  The only coupling of GTP to 
housebot would be it's conversion of string input to fundamental data 
types unique to housebot (eg. color_t, position).  Similarly, the 
reverse coupling will eventually be a single function call.  Right now 
it's a sequence of a few (identical) object creation steps and then the 
final function call.  I should be able to encapsulate that.