   Understanding Composition
  Hello, I bought the book Head First - Design Patterns. After reading about the Strategy Pattern I tried to implement it in a OpenGL Window class. namespace bj{class GL{private:HWNDwindowHandle;HDCdeviceContext;HGLRCrenderContext;intexitCode;/* Sets the windows class to use with the window. Returnsa string containing the name of the window class*/std::tr1::function<std::wstring(GL &)> register_class; /* Function that adjusts the size of the window andcreates the window. This algorithm must set the GL's windowHandle and deviceContexts states.*/std::tr1::function<void(GL &, const std::wstring &, int &,int&)>create_window;/* This function describes the pixel format of the renderer and sets up a rendering context. The GL'srendering context state must be set. */std::tr1::function<void(GL &)> setup_gl;/* This function is called when the window is resized.It should reset the viewport and projection matrix. */std::tr1::function<void(double, double)> resize;/* Do any initialization here. */std::tr1::function<void(GL &)> initialize;// Main run loop. This functor must be setstd::tr1::function<int(GL &)> run_loop;public:// Get DCHDC get_dc(){return (deviceContext);}// Set DCvoid set_dc(HDC dc){deviceContext = dc;}// Get RCHGLRC get_rc(){return (renderContext);}// Set RCvoid set_rc(HGLRC rc){renderContext = rc;}// Get Window handleHWND get_window(){return (windowHandle);}// Set Window handlevoid set_window(HWND window){windowHandle = window;}// Reset the register_class functorvoid reset_register_class(std::tr1::function<std::wstring(GL &)> register_class){this->register_class = register_class;}// Reset the create_window functorvoid reset_create_window(std::tr1::function<void(GL &, const std::wstring &, int &,int&)> create_window){this->create_window = create_window;}// Reset the setup_gl functorvoid reset_setup_gl(std::tr1::function<void(GL &)> setup_gl){this->setup_gl = setup_gl;}// Reset the resize functorvoid reset_resize(std::tr1::function<void(double, double)> resize){this->resize = resize;}// Reset the initialize functorvoid reset_initialize(std::tr1::function<void(GL &)> initialize){this->initialize = initialize;}// Reset the run loopvoid reset_run_loop(std::tr1::function<int(GL &)> run_loop){this->run_loop = run_loop;}// Returns main loop exit codeint get_exit_code()const{return (exitCode);}// ConstructorsGL();explicit GL(std::tr1::function<int(GL &)> run_loop);// Destructor~GL();// Executes everythingint run();};// Standard function object for registering a window classclass DefRegisterClass{public:std::wstring operator()(GL &gl);DefRegisterClass();DefRegisterClass(WNDPROC win_proc_);private:WNDPROC win_proc;};class DefCreateWindow{public:void operator()(GL &gl, const std::wstring &className, int&width, int &height);};class DefSetupGL{public:void operator()(GL &gl);};class DefResize{public:void operator()(double width, double height);};class DefInitialize{public:void operator()(GL &gl);};// Standard class that contains a static function for handing// windows messages.class DefWinProc{public:static LRESULT CALLBACK WinProc(HWND, UINT, WPARAM, LPARAM);};// Converts win32 error messages to stringsstd::string format_message_win32(DWORD errorID);}// Namespace bj#endifGL_TEMPLATE_HPPI was wondering if this is the correct way to go about it using the strategy pattern. If anyone could point out anything I did wrong, it would be greatly appreciated. Also just to clear it up, the strategy pattern IS composition?   
  Design patterns are tricky. You don't want to fall into the trap of considering them to be rigid implementations that are applied to problems to yield solutions, and the nature and wording of your questions suggests you are edging towards that perspective. This would be detrimental.Patterns should be viewed as very abstract, generalized things. Aggregation of common useful concepts. You should not look to apply a pattern to a problem, but rather to find a solution to your problem, perhaps using your knowledge of patterns to guide the nomenclature of your solution, or the occasional implementation technique. All the strategy/policy pattern is about is selecting different configurable behavior at runtime. Composition is certainly one implementation detail that can be involved, but it would be wrong to say that the strategy pattern is composition -- inheritance could be used just as well in many languages.With that in mind, as long as your solution accomplishes the goal of providing configurable behavior, it is a "correct" strategy pattern. Which is not to say that there won't be issues with your implementation.In particular, with your implementation, I'm not seeing a whole lot of benefit to the extensive use of std::tr1::function for what should be member functions (public or private, depending). You're not actually providing an abstraction away from the underling windowing API (since you rigidly contain Win32 members and expose them in your public interface). Nor are you making the process of handling a window any easier via a layer of abstraction, you're requiring the user the implement a bunch of different functions to do the low-level window muckery on their own... granted you provide defaults, but that's just creating more work for you. There's little need for extensive customization of the code involved in registering a window class in Win32 -- the data, perhaps, but your class can do that via a simple and direct interface, not some delegated function pointer thing.This sort of object is a classical example of "you have a hammer, and everything looks like a nail." You're going way overboard in your attempt to "use" your shiny new strategy pattern and ending up with something that is the worse for it.Of all the extension points you have in this class, the one that handles the windows messages is the only one that is a real viable candidate for runtime behavior delegation. I would refactor away the rest.There are some other questionable implementation decisions in there, but they're not as related to the original topic.   ;Quote: Also just to clear it up, the strategy pattern IS composition?No, it typically involves composition. As in you have Joe he uses a strategy to accomplish his goals, but composition isn't necessary. Something along the lines of int main(){ FightStrat* fs ;if(noob){fs = new KindaSortaFight();}else{fs = new SuperMegaFight();} while(combat) {   fs->goFightWin(); }delete fs;}is a reasonable use of the strategy pattern that doesn't involve composition.The basis of the strategy pattern is that you have a behavior that can be specified at runtime. Like Low, medium, High AI settings the monsters aren't different they just act a little differently.  So we give them an AI class that they deffer to when doing AI things.  Are we using composition in this example, yes.  Is it necessary to the idea of "have to behave differently based on data at runtime", no.   ;  Thank you, jpetrie. You first paragraph definitely puts things into perspective. I definitely looking for a way to use my shiny new toy. I wrote many GL classes before. One with regular member functions and all state encapsulated. I wasn't happy with that solution. It was too immutable. I also tried inheritance. I wasn't too happy with that. There was this nagging voice saying "Don't use inheritance. Use composition." I got that from you gamedevers. But I think I got my definition of composition wrong. But are composition and the strategy pattern really different? One allows you to interchange state. The other allows you to interchange behavior. Are there any other differences besides that? If there is, then I don't have any understanding of this.   ;  Sorry, I was still typing my message. So composition is just combination of objects? It doesn't matter if they can be changed at run time or not. That's what the strategy pattern is for.   ;  Composition is simply referring to the state or technique wherein some object contains another. That's all. It's an extremely general idea; itself it has nothing to do with whether or not those contained objects can be manipulated at runtime or not, or whether they are even exposed from the public interface of the container, et cetera.   