Even people with big brains have reservations about components, so to finish off the section on component oriented design in the upcoming data-oriented design book, I'd really like some negative experiences so they can be solved in a troubleshooting like section.

I've noticed that there are some points where people get things a bit wrong in implementing components, and it causes things to tie together badly. Once they've started coupling things together, they don't see any benefit to components, and it becomes a bad example and part of their opinion on components. This negative experience spreads around by word of mouth, and that's just as bad as gossip.

There are probably some guidelines or guiding principles that can be distilled from these negative experiences that might help when trying to ensure people don't get lost. Troubleshooting is a good match as there are likely a number of similar negative experiences that can all be solved in a similar way.

For example, in my experience the thing that trips people up most is expecting components to talk to each other for some reason, like they are objects that can message each other in some two directional way. But in practice, I've found that's not necessary.

So I think we need some examples of cases where it might seem like components don't work, or are inefficient, and follow them with how you diagnose what's wrong with those assumptions.

If you've had any bad experiences with components, they're probably going to be more beneficial than positive ones, as helping people out of messes is a lot more positive than just announcing how cool something is.

send any experiences to support@dataorienteddesign.com

DATA-ORIENTED DESIGN The hardware will thank you.

Chinese translation provided by KouZhe / Martin Cole

Component-architecture and Entity-systems development 04/03/2013:16:09:23