|
3 | 3 |
|
4 | 4 | ## Definitions |
5 | 5 |
|
6 | | -"Allow a single entity to span multiple domains without coupling the domains to each other." |
7 | | - |
8 | | -"Composite is a structural design pattern that lets you compose objects into tree structures and then work with these structures as if they were individual objects." |
9 | | - |
10 | | -"Compose objects into tree structures to represent whole-part hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly." |
| 6 | +"Let you split a large class or a set of closely related classes into two separate hierarchies—abstraction and implementation—which can be developed independently of each other." |
11 | 7 |
|
12 | 8 | When to use: |
13 | | -1. You have a class that touches multiple domains which you want to keep decoupled from each other. |
14 | | -2. A class is getting massive and hard to work with. |
15 | | -3. You want to be able to define a variety of objects that share different capabilities, but using inheritance doesn’t |
16 | | -let you pick the parts you want to reuse precisely enough. |
17 | | -4. It is an alternative to inheritence. Composition vs Inheritence? |
| 9 | +1. Decouple an abstraction from the implementation therefore both can vary independently. |
| 10 | +2. Share same implementation for multiple objects |
| 11 | +3. Hide details from clients |
| 12 | +4. Brings more flexibility, Cartesian Product see: [Christopher Okhravi](https://youtu.be/F1YQ7YRjttI?list=PLrhzvIcii6GNjpARdnO4ueTUAVR9eMBpc) |
18 | 13 |
|
19 | 14 | Notes: |
20 | | -1. The Component pattern adds a good bit of complexity over simply making a class and putting code in it. |
21 | | -2. Given the container object, first you have to get the component you want, then you can do what you need. |
22 | | -In performance-critical inner loops, this pointer following may lead to poor performance. |
23 | | - |
24 | | - |
25 | | -### Structure |
26 | | - |
27 | | -The *Component* interface describes operations that are common to both simple and complex elements of the tree. |
28 | | -``` |
29 | | - public interface IComponent |
30 | | - { |
31 | | - void Operate(); |
32 | | - } |
33 | | -``` |
34 | | -The *Sub-Component* Subcomponents are basic elements of a tree that doesn’t have sub-elements. Also called leaf, |
35 | | -they end up doing most of the real work, since they don’t have anyone to delegate the work to. |
36 | | -``` |
37 | | - public class SubComponent : IComponent |
38 | | - { |
39 | | - public void Operate() |
40 | | - { |
41 | | - //Do some work. |
42 | | - } |
43 | | - } |
44 | | -``` |
45 | | -The *Component* The Container is an element that has sub-elements: leaves or other containers. |
46 | | -A container doesn’t know the concrete classes of its children. It works with all sub-elements only via the component interface. |
47 | | -Upon receiving a request, a container delegates the work to its sub-elements, processes intermediate results and then returns the final result to the client. |
48 | | -``` |
49 | | - public class Component : IComponent |
50 | | - { |
51 | | - readonly List<IComponent> _components = new List<IComponent>(); |
52 | | - public void Operate() |
53 | | - { |
54 | | - foreach (var c in _components) |
55 | | - c.Operate(); |
56 | | - } |
57 | | -
|
58 | | - public void AddComponent(IComponent c) => _components.Add(c); |
59 | | - public void RemoveComponent(IComponent c) => _components.Remove(c); |
60 | | - public IComponent GetComponent(int index) => _components[index]; |
61 | | - } |
62 | | -``` |
63 | | - |
64 | | -The *Client* works with all elements through the component interface. As a result, the client can work in the same way with both simple or complex elements of the tree. |
| 15 | +1. Similar to adapter: Adapter makes things work after they're designed; Bridge makes them work before they are. |
| 16 | +2. All examples are quite different but have the same idea in common: To split Abstraction and Implementation |
65 | 17 |
|
66 | 18 | References: |
67 | | -1. Youtube [Derek Banas](https://www.youtube.com/watch?v=2HUnoKyC9l0&list=PLF206E906175C7E07&index=19&t=0s) |
68 | | -2. Youtube [Christopher Okhravi](https://www.youtube.com/watch?v=EWDmWbJ4wRA&list=PLrhzvIcii6GNjpARdnO4ueTUAVR9eMBpc&index=15&t=965s) |
69 | | -3. Book [Game Programmings Patterns](https://gameprogrammingpatterns.com/component.html) |
70 | | -4. Github [Qian Mo](https://github.com/QianMo/Unity-Design-Pattern/tree/master/Assets/Structural%20Patterns/Composite%20Pattern) |
71 | | -6. Article [Source Making](https://sourcemaking.com/design_patterns/composite) |
72 | | -7. Article [Guru](https://refactoring.guru/design-patterns/composite) |
| 19 | +1. Youtube [Derek Banas](https://youtu.be/9jIgSsIfh_8?list=PLF206E906175C7E07) |
| 20 | +2. Youtube [Christopher Okhravi](https://youtu.be/F1YQ7YRjttI?list=PLrhzvIcii6GNjpARdnO4ueTUAVR9eMBpc) |
| 21 | +4. Github [Qian Mo](https://github.com/QianMo/Unity-Design-Pattern/tree/master/Assets/Structural%20Patterns/Bridge%20Pattern) |
| 22 | +6. Article [Source Making](https://sourcemaking.com/design_patterns/bridge) |
| 23 | +7. Article [Guru](https://refactoring.guru/design-patterns/bridge) |
0 commit comments