I have a conceptual question, why does a Transform have a hierarchy (with children), but a GameObject doesn't? If I have a Capsule, with a Cube as a child -- so that when I drag the Capsule, the Cube tags along -- it seems more natural to think that the relationship is between Capsule and Cube (2 physical-ish objects), not Transform and Transform (2 mathematical concepts).
Any enlightenment would be greatly appreciated.
The GameObject act mostly as a container for components (such as the transform, or a renderer). It is the components that give shape to the game behaviour, not the game objects themselves really. While Unity requires each game object to have a transform component for some reasons, imagine a game that used this architecture might not require it. It would be a strange design decision to have the game object know about parents and children if they aren't needed (I can imagine having a component based design for a text mud game where parenting stuff might not be that useful). Parenting belongs to the transform (the position etc of objects) since it uses this information to calculate the position from local coordinate systems. Think of it, it becomes almost about useless to parent things unless you consider their position.
A game object is about as void as it can get. It is just a container for components. It is the components that are attached to it that make them "physical". The transform describe where an object is. A renderer makes use of a mesh filter to render the mesh at the position derived from the transform. A collider component describes its collision properties and a rigidbody makes use of the collider and transform to generate physical movement. All of the components then work in harmony, doing their job and their job alone.
If you were to create your own very basic component model game from scratch you'd probably get to the same conclusions. I have toyed about trying to "improve" (Well, in ways I thought unity lacked) this architecture but I came to realize that things are the way they are for a good reason. For one, even such a silly thing that having public member variables camelCased instead of PascalCased proved to be a good approach since it resolves the ambiguity of accessing member variables vs accessing class variables. You also get to appreciate that the transform deal with the parenting code and not have it hard coded into the game object. But I agree it could just as well be included in the interface of the game object since you can't create a game object without a transform in the approach Unity favor. Unity was meant to be a 3d game engine so it's a quite central piece to have. But boy, would I want to trade it for a transform2d sometimes when making 2d games... :)
A transform is a scale/rotate/translate operation. When one object is attached to another, it is "transformed" by its parent -- its own (local) scale/rotate/translate is combined with that of its parent. The chain of operations that transforms a specific object is actually the chain of transforms of its ancestors.
Just google "composition over inheritance" to find some interesting topics on the net. http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance
– StatementYou should also read some of the other concerns about the book though, in coding horror: http://www.codinghorror.com/blog/2005/09/head-first-design-patterns.html and I can agree with the authors concerns about "pattern fever". While I feel I had an extensive period of "flexibility gone extreme", I also feel now - when I am trying to restrain myself from overuse - that I have a very solid understanding about how to apply various schemes when it's needed. My biggest challenge is however to sense when it calls for flexibility and when it calls for something more "down to earth".
– Statement