Timeline for Object updates, internal vs external?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 14, 2011 at 16:57 | comment | added | James | @Maik Semder Glad its more useful. I do not however feel that OO programming in the area of Encapsulation equates to good functional code. This is just a matter of opinion so not much to be gained by a discussion on that topic (Almost was going to flag this question as Opinionated when I first read it but it has spawned some good discussion). | |
| Sep 14, 2011 at 11:21 | comment | added | Maik Semder | @James, thanks for taking the time to edit the answer in response to my comment, very much appreciated. The proposed answer to "keep all logic that acts upon an object within that object" defeats a core feature of OO, namely encapsulation. As Joe's link shows, using non-friend non-member functions increases the level of encapsulation of an object. Moreover, it introduces a clear method as how to actually measure encapsulation. Putting the move-function into either world or actor decreases the encapsulation of the design, resulting in less flexible and harder to maintain code. | |
| Sep 14, 2011 at 0:18 | comment | added | James | @Maik Semder. Thanks for the feedback. I have rewritten the answer to try and draw the lines more clearly to the initial question and the overall drive for it in the first place as given at the end of the question. | |
| Sep 14, 2011 at 0:14 | history | edited | James | CC BY-SA 3.0 |
addressed concerns voiced over the clarity of my answer to the question.
|
| Sep 13, 2011 at 18:57 | comment | added | Maik Semder | @James, fair enough. I downvoted because entity-component systems do not answer the original question. A position component can still move itself or the world could iterate over all position components and move them. The same reason Kylotan down-voted pek's answer, so I thought the -1 reason was obvious. And even if it would be mandatory for a component system to move itsself (which is not the case) it would still not be an answer, just a use-case for 1 of the options. But the question was about the reasons to use one or the other, their pros and cons. The answer doesnn't cover that. | |
| Sep 13, 2011 at 18:24 | comment | added | James | For me I keep the logic in the objects, but I am actually doing a component system on top of Data Oriented Design meaning most of my objects are actually just the logic anyways that are mapped to locations inside of data for contiguous fast processing.... And at the end of the day, learn one design pattern at a time :D As for the -1, would appreciate knowing why that was tagged like that, even if its just 'I like my answer better' I would still like to know why. | |
| Sep 13, 2011 at 17:25 | comment | added | omgnoseat | I have been looking into the component pattern last couple of hours. (pek's links are very nice).But it still is not clear where the actual "behaviour" should take place. It's clear that an entity has different components for input,rendering,physics.But if I understood correctly, the components only contain the data needed to be able to function, but don't actually contain the implementation. Let's move back to the moving again;How should I make an entity move using the components?Should I extend the inputcomponent and code the implementation there?Or something else manage the implementation? | |
| Sep 13, 2011 at 8:18 | history | answered | James | CC BY-SA 3.0 |