Before using Unity3d, I already knew the concept of component design, and one of our projects was actually component-based, although the underlying engine just designed the simplest component framework, unfortunately the rest, and didn't organize the code according to how many components it meant. This component fails, There is no way to provide a good communication between components. Our component systems use a interface class as a means of providing intrinsic functionality to a component. The advantage is that you don't need to include the details of a particular component (without the component header file) with the interface class. The downside is that The interface class itself is huge because he uses the functor function as a way to communicate with the component, and for every function that needs to be exposed to the component, You need to add a functor variable to the interface. Another problem with using the functor is that when you need to import the interface into the script, I'm sure the research can be found (the bottom line is to encapsulate the functor with a normal function or class function). Object-oriented design patterns that, most of all, can be translated into some form of map, meaning they are actually expressing a mapping relationship, and I was wondering why? I know this mapping is unavoidable in oo design, But there is no simple and beautiful explanation to let me go. Until I saw the Go language designer's San Francisco conference speech about went--"My late friend Alain Fournier told me that he thought the most basic requirement of academic work was the division of labor." Do you know? The type hierarchy is also just a taxonomy. "--Yes, object-oriented is a taxonomy, so the mapping relationship is bound to be reflected, so map is almost the necessary tool for object-oriented design patterns. Personally feel that the use of map to achieve classification relationship is not embarrassed, but sometimes it is necessary to use a layer of code to hide the map, It is simply the ulterior motives, originally no meaning in my opinion has become interesting, you are to hide the fact that you are only using the map? However, mapping relationships are really important in the program and are not related to using object-oriented design. Because a program is an abstraction of a logical relationship, Logical relationships are often limited to real entity relationships, and one of the intuition of human induction is both mapping. Back to our project, since the component uses a map to find specific interface classes, why bother using map to query internal methods? I think, Use a similar getcompoent ("Compoennt_name")->invoke ("Function_name"). Then reduce those branches and leaves of the template, design mode method, you can achieve 2 map query is over, do not need more. The go language actually has only built in an array (arrays), Map (map) Two data structures. Array is a very high-cohesion data structure, and map is quite the opposite, and is a very loosely structured structure. In addition to the essentials of some algorithms, map is often used in areas where decoupling is needed. One of the main goals of the design pattern is de-coupling, map Use is inevitable. But often some code, in order to understand the coupling, introduced too many encapsulation classes, which is actually contrary to the original intention. What I want to learn is to let the data behave as naturally as possible, and then stay where it's obvious. The above is no clue about the pattern of the map in the design of the relationship between the groove. Ignore it. Component design breaks down the more rigid inheritance relationships, while mapping relationships are used to represent entity relationships. Previously in < memo: C # interface and abstract class > said:-"and abstract class or class concept, is an embodiment of the specific code organization relationship in the program. The concern is the relationship between homogeneous entities. " The concept of "abstract class or class" is an implementation of the 2 coupling relationships between code reuse and code constraints in a language environment. One of the difficulties of the inheritance system is that the relationship between all things is not so simple, there are many gray areas. After all, it focuses more on the relationship between homogeneous entities. For 3d games, an entity may contain scripts, grids, physics, sounds, message objects, and so on. Whether you use single inheritance or multiple inheritance, Will encounter the inherent problems of the inheritance system, such as bloated interfaces, such as overloading problems, such as the multi-inheritance of the diamond problem, and so on, this is only a few semantic problems, blind eye may have passed, it is more uncomfortable for some actual operation, similar to the serialization to disk (archive), deserialization (read file), Inheritance systems face a high level of complexity, such as the multi-inheritance of the deserialization work, to see the blind. Some might say that a component is a combination of patterns in design mode. A component is simply a class member variable, and therefore a traditional method of class architecture. Component design is indeed a combination of patterns. The difference is that the traditional class-system combination model embodies an intrinsic, The internal cohesion of the system. And the component model embodies the loose, dynamic relationships. For example, to design a person class, the combination pattern can define Hand,foot,head,brain, which combines 4 member variables But they are indispensable. The component system is a person can dynamically add hand,foot,head,brain these 4 components, that is, there can be a lack of brain to appear. In this sense, the person is not a class, but a collection. It can be said that the component pattern is closer to the mathematical description, while the inheritance pattern is closer to the taxonomy interpretation. Component methods in object-oriented languages, are not completely left out of the inheritanceFor the underlying component, it may itself be a very high-poly class system, because it does not need to be modified dynamically, or it is very professional (physical), or very cumbersome (IO), once it is done, it is sufficient to provide functionality as a component. The concept of the component method itself is straightforward, There is nothing mysterious about it. The difficulty of component design also involves the implementation of the basic component. Component design is based on the need for a set of mapping mechanism, reflected in the algorithm is a map, the data structure of each language has a ready-made implementation, no need to worry. And the grammatical level is a reflection mechanism. Similar to C # and a large number of dynamic languages, both are native to this mechanism. In C + +, It has to be done by itself. In general, it is necessary to implement a perfect rtti system. Back to one of our projects, it is because the engine provides the concept of components, but also gives the implementation of the query component, but there is no rtti system to implement the reflection mechanism, so that the mapping relationship, resulting in a nondescript, So that the people behind have been in no way. In addition, we use the 3d engine is an open-source engine, the other common libraries are basically open source to get over. In addition to the logic layer, you will find that the material is not written according to the ideas of your component, It's going to be a very painful time. For example, you want to have a animaition component, which should have a clear position with the entity component, but in the 3d engine you use, animation, the skeleton is tightly bound to the entity, If you include the skeleton component in the entity component, there will be multiple entity containing the same skeleton problem, skeleton only need one copy. Does this mean that your entity needs to be divided into 2 components that can be animatin and not? or, The outer use component can contain both the skeleton component and the entity component, and the skeleton is queried when the entity component is added. There is no depth yet, but unity, even bone, exists as a component. Component design, in fact, requires full support of the entire program code, For a large number of external code-based situations, do not know what good method? The component approach is not a balm. Code organization cannot simply rely on mapping relationships. In unity, there will also be a base class like Gameobject,collider. Bone if it is also a component, The individual feels the need to consider (checked, bone is really not provided as a component). Disclaimer: This document is from the "Dog Planing Learning Network" community, is a self-published Unity3d learning articles, if anything violates your relevant interests, please communicate with the official, we will deal with the real-time. More Highlights: www.gopedu.com
Considerations for Unity3d Component design
