|
5 | 5 | * Mergulho nos padrões de projeto - Alexander Shvets |
6 | 6 | * Refactoring Guru - refactoring.guru |
7 | 7 |
|
| 8 | +> |
8 | 9 | ### Creational Patterns |
9 | 10 | --- |
| 11 | + |
| 12 | +> |
10 | 13 | #### Factory Method |
11 | 14 |
|
| 15 | +<img src="./assets/factory-method.png" width="100%"> |
| 16 | + |
12 | 17 | > Factory Method is a creational design pattern that provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that will be created. |
13 | 18 |
|
14 | 19 | * Use the Factory Method when you don’t know beforehand the exact types and dependencies of the objects your code should work with. |
15 | 20 | * Use the Factory Method when you want to provide users of your library or framework with a way to extend its internal components. |
16 | 21 | * Use the Factory Method when you want to save system resources by reusing existing objects instead of rebuilding them each time. |
17 | 22 |
|
| 23 | +> |
18 | 24 |
|
19 | 25 | #### Abstract Factory |
20 | 26 |
|
| 27 | +<img src="./assets/abstract-factory.png" width="100%"> |
| 28 | + |
21 | 29 | > Abstract Factory is a creational design pattern that lets you produce families of related objects without specifying their concrete classes. |
22 | 30 |
|
23 | 31 | * Use the Abstract Factory when your code needs to work with various families of related products, but you don’t want it to depend on the concrete classes of those products—they might be unknown beforehand or you simply want to allow for future extensibility. |
24 | 32 |
|
| 33 | +> |
25 | 34 | #### Builder |
26 | 35 |
|
| 36 | +<img src="./assets/builder.png" width="100%"> |
| 37 | + |
27 | 38 | > Builder is a creational design pattern that lets you construct complex objects step by step. The pattern allows you to produce different types and representations of an object using the same construction code. |
28 | 39 |
|
29 | 40 | * Use the Builder pattern to get rid of a “telescopic constructor”. |
30 | 41 | * Use the Builder pattern when you want your code to be able to create different representations of some product (for example, stone and wooden houses). |
31 | 42 | * Use the Builder to construct Composite trees or other complex objects. |
32 | 43 |
|
| 44 | +> |
33 | 45 | #### Prototype |
34 | 46 |
|
| 47 | +<img src="./assets/prototype.png" width="100%"> |
| 48 | + |
35 | 49 | > Prototype is a creational design pattern that lets you copy existing objects without making your code dependent on their classes. |
36 | 50 |
|
37 | 51 | * Use the Prototype pattern when your code shouldn’t depend on the concrete classes of objects that you need to copy. |
38 | 52 | * Use the pattern when you want to reduce the number of subclasses that only differ in the way they initialize their respective objects. Somebody could have created these subclasses to be able to create objects with a specific configuration. |
39 | 53 |
|
| 54 | +> |
40 | 55 | #### Singleton |
41 | 56 |
|
| 57 | +<img src="./assets/singleton.png" width="100%"> |
| 58 | + |
42 | 59 | > Singleton is a creational design pattern that lets you ensure that a class has only one instance, while providing a global access point to this instance. |
43 | 60 |
|
44 | 61 | * Use the Singleton pattern when a class in your program should have just a single instance available to all clients; for example, a single database object shared by different parts of the program. |
45 | 62 | * Use the Singleton pattern when you need stricter control over global variables. |
46 | 63 |
|
| 64 | +> |
47 | 65 | ### Structural Patterns |
48 | 66 | --- |
| 67 | +> |
49 | 68 | #### Adapter |
50 | 69 |
|
| 70 | +<img src="./assets/adapter.png" width="100%"> |
| 71 | + |
51 | 72 | > Adapter is a structural design pattern that allows objects with incompatible interfaces to collaborate. |
52 | 73 |
|
53 | 74 | * Use the Adapter class when you want to use some existing class, but its interface isn’t compatible with the rest of your code. |
54 | 75 | * Use the pattern when you want to reuse several existing subclasses that lack some common functionality that can’t be added to the superclass. |
55 | 76 |
|
| 77 | +> |
56 | 78 | #### Bridge |
57 | 79 |
|
| 80 | +<img src="./assets/bridge.png" width="100%"> |
| 81 | + |
58 | 82 | > Bridge is a structural design pattern that lets 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. |
59 | 83 |
|
60 | 84 | * Use the Bridge pattern when you want to divide and organize a monolithic class that has several variants of some functionality (for example, if the class can work with various database servers). |
61 | 85 | * Use the pattern when you need to extend a class in several orthogonal (independent) dimensions. |
62 | 86 | * Use the Bridge if you need to be able to switch implementations at runtime. |
63 | 87 |
|
| 88 | +> |
64 | 89 | #### Composite |
65 | 90 |
|
| 91 | +<img src="./assets/composite.png" width="100%"> |
| 92 | + |
66 | 93 | > 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. |
67 | 94 |
|
68 | 95 | * Use the Composite pattern when you have to implement a tree-like object structure. |
69 | 96 | * Use the pattern when you want the client code to treat both simple and complex elements uniformly. |
70 | 97 |
|
| 98 | +> |
71 | 99 | #### Decorator |
72 | 100 |
|
| 101 | +<img src="./assets/decorator.png" width="100%"> |
| 102 | + |
73 | 103 | > Decorator is a structural design pattern that lets you attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors. |
74 | 104 |
|
75 | 105 | * Use the Decorator pattern when you need to be able to assign extra behaviors to objects at runtime without breaking the code that uses these objects. |
76 | 106 | * Use the pattern when it’s awkward or not possible to extend an object’s behavior using inheritance. |
| 107 | + |
| 108 | +> |
| 109 | +#### Facade |
| 110 | + |
| 111 | +<img src="./assets/facade.png" width="100%"> |
| 112 | + |
| 113 | +> Facade is a structural design pattern that provides a simplified interface to a library, a framework, or any other complex set of classes. |
| 114 | +
|
| 115 | +* Use the Facade pattern when you need to have a limited but straightforward interface to a complex subsystem. |
| 116 | +* Use the Facade when you want to structure a subsystem into layers. |
0 commit comments