Original Post
🔒 Locked
components
Advertisement
components (in the .NET sense) are reusable BINARY chunks. For instance a photoshop plugin could be called a component.
If I write an object-oriented game engine, I might have all sorts of cool polymorphic classes for stuff like the OpenGL rendering pipeline and the DirectX rendering pipeline, the OpenAL sound class wrappers and the DirectMusic class wrappers, and some cool configuration ability to pick between them and have some factory system construct the right objects.
If I write a COMPONENT oriented game engine I would have all sorts of cool subsystem INTERFACES, which could in theory be implemented by various other classes ... and then I might write a OpenGL rendering library as a component, and a DirectX one, an OpenAL sound component and a DirectMusic one.
The core arangement is almost the same, the usage is almost the same ... but the component-oriented systems focuses not on reusing implementation, but on defining good interfaces. And then usually packaging implementations up in a more plugable binary way.
So I might have one big monolithic app that had 500 classes, of which only 200 are used in any given configuration ... and call it OO.
But in a component oriented system I'd seperate those 500 classes into seperate assemblies ... and then other apps might reuse only the assemblies they need.
No need for the next project to recompile the OpenGL renderer, it can just reference it the same way you reference the .NET XML assemblies, or the .NET Web Controls.
Compiled chunks that are usable completely as is.
If I write an object-oriented game engine, I might have all sorts of cool polymorphic classes for stuff like the OpenGL rendering pipeline and the DirectX rendering pipeline, the OpenAL sound class wrappers and the DirectMusic class wrappers, and some cool configuration ability to pick between them and have some factory system construct the right objects.
If I write a COMPONENT oriented game engine I would have all sorts of cool subsystem INTERFACES, which could in theory be implemented by various other classes ... and then I might write a OpenGL rendering library as a component, and a DirectX one, an OpenAL sound component and a DirectMusic one.
The core arangement is almost the same, the usage is almost the same ... but the component-oriented systems focuses not on reusing implementation, but on defining good interfaces. And then usually packaging implementations up in a more plugable binary way.
So I might have one big monolithic app that had 500 classes, of which only 200 are used in any given configuration ... and call it OO.
But in a component oriented system I'd seperate those 500 classes into seperate assemblies ... and then other apps might reuse only the assemblies they need.
No need for the next project to recompile the OpenGL renderer, it can just reference it the same way you reference the .NET XML assemblies, or the .NET Web Controls.
Compiled chunks that are usable completely as is.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement