|
This thread is locked; no one can reply to it. |
1
2
|
Component-driven design |
Indeterminatus
Member #737
November 2000
|
I read about this in one of the Game Programming Gems books, but I don't know which one from the top of my head (although I want to say the fifth volume). _______________________________ |
CGamesPlay
Member #2,559
July 2002
|
Now that we have established (I hope) that there is nothing that can be accomplished with MI but cannot be accomplished with Component-driven design (CDD) and vice versa, what are the relative benefits of using one system over the other, in concrete terms? Specifically, since there are no technical advantages when compared solely based on capacity, the advantages of one system over another are organization and ease of modification. So, help me compare the two designs.
Can anyone add to this list? References
-- Ryan Patterson - <http://cgamesplay.com/> |
Steve++
Member #1,816
January 2002
|
axilmar said: That's my opinion as well. Renaming something and then marketing it as new is silly. This isn't just about composition. It's about providing a component framework that happens to use composition. CGamesPlay said: CDD allows one to quickly change behaviors by assigning additional components to individual entities or to specialized templates. MI requires one create a specialized class to add additional behavior. Not just "quickly", but also at runtime. That's one of the big differences. Inheritance is nice to have in the toolkit and I'm sure that even among CDD components there would be a lot of inheritance happening, especially among components that implement the same interfaces. One of the biggest benefits of CDD is that it favours service driven architecture over multiple inheritance spaghetti. I personally favour loosely coupled code. |
axilmar
Member #1,204
April 2001
|
Steve++ said: This isn't just about composition. It's about providing a component framework that happens to use composition. I am ok with the framework, but I am not ok with presenting composition as something new. Quote: I personally favour loosely coupled code. I do as well. Here is something useful to read regarding multiple inheritance: C++ FQA Lite: Inheritance -- multiple and virtual inheritance |
Tobias Dammers
Member #2,604
August 2002
|
Personally, I avoid all occurrences of MI that do not follow the "one normal base class plus an arbitrary number of interfaces" pattern. In other words, when a class inherits from multiple base classes, then all but one must be interfaces (that is, they contain nothing but pure virtual methods). A Dog IS A Mammal. An Emu IS A Bird. A Mammal IS AN Animal. This doesn't work, obviously, because Dog tries to inherit from two classes that share a common base class. --- |
|
1
2
|