You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
4. Book : [https://www.amazon.com/dp/B08XLJ8Z2J](https://www.amazon.com/dp/B08XLJ8Z2J) : ASIN B08XLJ8Z2J
34
-
-**Book** includes FREE Video Access Codes to view videos from the official documentation website at [https://sbcode.net/python/](https://sbcode.net/python/)
35
-
34
+
-**Book** includes FREE Video Access Codes to view videos from the official documentation website at [https://sbcode.net/python/](https://sbcode.net/python/)
36
35
37
36
All the code examples in the book can be found in these pages.
38
37
@@ -44,59 +43,39 @@ A familiarity of Design Patterns will be very useful when planning, discussing,
44
43
45
44
Also, throughout the book, as each design pattern is discussed and demonstrated using example code, I also introduce new python coding concepts with each new design pattern. So that as you progress through the book and try out the examples, you will also get experience and familiarity with some of the finer details of programming with python.
46
45
47
-
So, in this book, you will learn about these 23 Design Patterns,
48
-
49
-
* Creational
50
-
-[Factory](factory)
51
-
-[Abstract Factory](abstract_factory)
52
-
-[Builder](builder)
53
-
-[Prototype](prototype)
54
-
-[Singleton](singleton)
55
-
* Structural
56
-
-[Decorator](decorator)
57
-
-[Adapter](adapter)
58
-
-[Facade](facade)
59
-
-[Bridge](bridge)
60
-
-[Composite](composite)
61
-
-[Flyweight](flyweight)
62
-
-[Proxy](proxy)
63
-
* Behavioral
64
-
-[Command](command)
65
-
-[Chain of Responsibility](chain_of_responsibility)
66
-
-[Observer Pattern](observer)
67
-
-[Interpreter](interpreter)
68
-
-[Iterator](iterator)
69
-
-[Mediator](mediator)
70
-
-[Memento](memento)
71
-
-[State](state)
72
-
-[Strategy](strategy)
73
-
-[Template](template)
74
-
-[Visitor](visitor)
46
+
So, in this book, you will learn about these 23 Design Patterns,
47
+
48
+
- Creational
49
+
-[Factory](factory)
50
+
-[Abstract Factory](abstract_factory)
51
+
-[Builder](builder)
52
+
-[Prototype](prototype)
53
+
-[Singleton](singleton)
54
+
- Structural
55
+
-[Decorator](decorator)
56
+
-[Adapter](adapter)
57
+
-[Facade](facade)
58
+
-[Bridge](bridge)
59
+
-[Composite](composite)
60
+
-[Flyweight](flyweight)
61
+
-[Proxy](proxy)
62
+
- Behavioral
63
+
-[Command](command)
64
+
-[Chain of Responsibility](chain_of_responsibility)
65
+
-[Observer Pattern](observer)
66
+
-[Interpreter](interpreter)
67
+
-[Iterator](iterator)
68
+
-[Mediator](mediator)
69
+
-[Memento](memento)
70
+
-[State](state)
71
+
-[Strategy](strategy)
72
+
-[Template](template)
73
+
-[Visitor](visitor)
75
74
76
75
## Pattern Types
77
76
78
-
*...Refer to Book or Videos for extra content.*
79
-
80
-
<!-- In the list of patterns above, there are Creational, Structural and Behavioral patterns.
81
-
82
-
* **Creational** : Abstracts the instantiation process so that there is a logical separation between how objects are composed and finally represented.
83
-
* **Structural** : Structural patterns focus more on how classed and objects are composed using the different structural techniques, and to form structures with more or altered flexibility.
84
-
* **Behavioral** : Are concerned with the inner algorithms, process flow, the assignment of responsibilities and the intercommunication between objects. -->
77
+
_...Refer to Book or Videos for extra content._
85
78
86
79
## Class Scope and Object Scope Patterns
87
80
88
-
*...Refer to Book or Videos for extra content.*
89
-
90
-
<!-- Each pattern can be further specified whether it relates more specifically classes or instantiated objects.
91
-
92
-
Class scope patterns deal more with relationships between classes and their subclasses.
93
-
94
-
Object scope patterns deal more with relationships that can be altered at runtime
Copy file name to clipboardExpand all lines: abstract_factory/README.md
+2-12Lines changed: 2 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,21 +16,11 @@ Cover | Links
16
16
17
17
## Overview
18
18
19
-
The Abstract Factory Pattern adds an abstraction layer over multiple other creational pattern implementations.
20
-
21
-
To begin with, in simple terms, think if it as a Factory that can return Factories. Although you will find examples of it also begin used to return Builder, Prototypes, Singletons or other design pattern implementations.
19
+
*...Refer to Book or Videos for extra content.*
22
20
23
21
## Terminology
24
22
25
-
***Client**: The client application that calls the **Abstract Factory** and **Abstract Product** classes. It's the same process as the concrete creator in the [Factory](/factory#terminology) design pattern.
26
-
27
-
***Abstract Factory**: An interface to one of the Factories.
28
-
29
-
***Concrete Factory**: The Factory returned via the interface and contains methods or attributes to allow creating the product.
30
-
31
-
***Abstract Product**: The interface for the product within its own Factory.
32
-
33
-
***Concrete Product**: The object finally returned.
Copy file name to clipboardExpand all lines: adapter/README.md
+2-21Lines changed: 2 additions & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,30 +17,11 @@ Cover | Links
17
17
18
18
## Overview
19
19
20
-
Sometimes classes have been written and you don't have the option of modifying their interface to suit your needs. This happens if the method you are calling is on a different system across a network, a library that you may import or generally something that is not viable to modify directly for your particular needs.
21
-
22
-
The **Adapter** design pattern solves these problems:
23
-
24
-
* How can a class be reused that does not have an interface that a client requires?
25
-
* How can classes that have incompatible interfaces work together?
26
-
* How can an alternative interface be provided for a class?
27
-
28
-
You may have two classes that are similar, but they have different method signatures, so you create an Adapter over top of one of the method signatures so that it is easier to implement and extend in the client.
29
-
30
-
An adapter is similar to the [Decorator](/decorator) in the way that it also acts like a wrapper to an object. It is also used at runtime; however, it is not designed to be used recursively.
31
-
32
-
It is an alternative interface over an existing interface. It can also provide extra functionality that the interface being adapted may not already provide.
33
-
34
-
The adapter is similar to the [Facade](/facade), but you are modifying the method signature, combining other methods and/or transforming data that is exchanged between the existing interface and the client.
35
-
36
-
The Adapter is used when you have an existing interface that doesn't directly map to an interface that the client requires. So, then you create the Adapter which has a similar functional role, but with a new compatible interface.
20
+
*...Refer to Book or Videos for extra content.*
37
21
38
22
## Terminology
39
23
40
-
***Target**: The domain specific interface or class that needs to be adapted.
41
-
***Adapter Interface**: The interface of the target that the adapter will need to implement.
42
-
***Adapter**: The concrete adapter class containing the adaption process.
43
-
***Client**: The client application that will use the Adapter.
Copy file name to clipboardExpand all lines: bridge/README.md
+2-38Lines changed: 2 additions & 38 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,47 +17,11 @@ Cover | Links
17
17
18
18
## Overview
19
19
20
-
The **Bridge pattern** is similar to the [Adapter](/adapter) pattern except in the intent that you developed it.
21
-
22
-
The Bridge is an approach to refactor already existing code, whereas the Adapter creates an interface on top of existing code through existing available means without refactoring any existing code or interfaces.
23
-
24
-
The motivation for converting your code to the Bridge pattern is that it may be tightly coupled. There is logic and abstraction close together that is limiting your choices in how you can extend your solution in the way that you need.
25
-
26
-
E.g., you may have one Car class, that produces a very nice car. But you would like the option of varying the design a little, or outsourcing responsibility of creating the different components.
27
-
28
-
The Bridge pattern is a process about separating abstraction and implementation, so this will give you plenty of new ways of using your classes.
29
-
30
-
```python
31
-
CAR= Car()
32
-
print(CAR)
33
-
> Car has wheels and engine and windows and everything else.
34
-
```
35
-
36
-
But you would like to delegate the engine dynamically from a separate set of classes or solutions.
37
-
38
-
```python
39
-
ENGINE= EngineA()
40
-
CAR= Car(EngineA)
41
-
```
42
-
43
-
A Bridge didn't exist before, but since after the separation of interface and logic, each side can be extended independently of each other.
44
-
45
-
Also, the application of a Bridge in your code should use composition instead of inheritance. This means that you assign the relationship at runtime, rather than hard coded in the class definition.
46
-
47
-
I.e., `CAR = Car(EngineA)` rather than `class Car(EngineA):`
48
-
49
-
A Bridge implementation will generally be cleaner than an Adapter solution that was bolted on. Since it involved refactoring existing code, rather than layering on top of legacy or third-party solutions that may not have been intended for your particular use case.
50
-
51
-
You are the designer of the Bridge, but both approaches to the problem may work regardless.
52
-
53
-
The implementer part of a Bridge, can have one or more possible implementations for each refined abstraction. E.g., The implementor can print to paper, or screen, or format for a web browser. And the abstraction side could allow for many permutations of every shape that you can imagine.
20
+
*...Refer to Book or Videos for extra content.*
54
21
55
22
## Terminology
56
23
57
-
***Abstraction Interface**: An interface implemented by the refined abstraction describing the common methods to implement.
58
-
***Refined Abstraction**: A refinement of an idea into another class or two. The classes should implement the Abstraction Interface and assign which concrete implementer.
59
-
***Implementer Interface**: The implementer interface that concrete implementers implement.
60
-
***Concrete Implementer**: The implementation logic that the refined abstraction will use.
Copy file name to clipboardExpand all lines: builder/README.md
+2-12Lines changed: 2 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,21 +16,11 @@ Cover | Links
16
16
17
17
## Overview
18
18
19
-
The Builder Pattern is a creational pattern whose intent is to separate the construction of a complex object from its representation so that you can use the same construction process to create different representations.
20
-
21
-
The Builder Pattern tries to solve,
22
-
23
-
* How can a class create different representations of a complex object?
24
-
* How can a class that includes creating a complex object be simplified?
25
-
26
-
The Builder and Factory patterns are very similar in the fact they both instantiate new objects at runtime. The difference is when the process of creating the object is more complex, so rather than the Factory returning a new instance of `ObjectA`, it calls the builders director constructor method `ObjectA.construct()` that goes through a more complex construction process involving several steps. Both return an Object/Product.
19
+
*...Refer to Book or Videos for extra content.*
27
20
28
21
## Terminology
29
22
30
-
***Product**: The Product being built.
31
-
***Builder**: Builds the concrete product. Implements the `IBuilder` interface.
32
-
***Builder Interface**: The Interface that the Concrete builder should implement.
33
-
***Director**: Has a `construct()` method which when called creates a customized product.
Copy file name to clipboardExpand all lines: chain_of_responsibility/README.md
+2-12Lines changed: 2 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,21 +17,11 @@ Cover | Links
17
17
18
18
## Overview
19
19
20
-
**Chain of Responsibility** pattern is a behavioral pattern used to achieve loose coupling in software design.
21
-
22
-
In this pattern, an object is passed to a **Successor**, and depending on some kind of logic, will or won't be passed onto another successor and processed. There can be any number of different successors and successors can be re-processed recursively.
23
-
24
-
This process of passing objects through multiple successors is called a chain.
25
-
26
-
The object that is passed between each successor does not know about which successor will handle it. It is an independent object that may or may not be processed by a particular successor before being passed onto the next.
27
-
28
-
The chain that the object will pass through is normally dynamic at runtime, although you can hard code the order or start of the chain, so each successor will need to comply with a common interface that allows the object to be received and passed onto the next successor.
20
+
*...Refer to Book or Videos for extra content.*
29
21
30
22
## Terminology
31
23
32
-
***Handler Interface**: A common interface for handling and passing objects through each successor.
33
-
***Concrete Handler**: The class acting as the **Successor** handling the requests and passing onto the next.
34
-
***Client**: The application or class that initiates the call to the first concrete handler (successor) in the chain.
Copy file name to clipboardExpand all lines: command/README.md
+2-25Lines changed: 2 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,34 +16,11 @@ Cover | Links
16
16
17
17
## Overview
18
18
19
-
The **Command** pattern is a behavioral design pattern, in which an abstraction exists between an object that invokes a command, and the object that performs it.
20
-
21
-
E.g., a button will call the **Invoker**, that will call a pre-registered **Command**, that the **Receiver** will perform.
22
-
23
-
A Concrete Class will delegate a request to a command object, instead of implementing the request directly.
24
-
25
-
Using a command design pattern allows you to separate concerns and to solve problems of the concerns independently of each other.
26
-
27
-
E.g., logging the execution of a command and its outcome.
28
-
29
-
The command pattern is a good solution for implementing UNDO/REDO functionality into your application.
30
-
31
-
Uses:
32
-
33
-
* GUI Buttons, menus
34
-
* Macro recording
35
-
* Multi-level undo/redo
36
-
* Networking - send whole command objects across a network, even as a batch
37
-
* Parallel processing or thread pools
38
-
* Transactional behavior
39
-
* Wizards
19
+
*...Refer to Book or Videos for extra content.*
40
20
41
21
## Terminology
42
22
43
-
***Receiver**: The object that will receive and execute the command.
44
-
***Invoker**: The object that sends the command to the receiver. E.g., A button.
45
-
***Command Object**: Itself, an object, that implements an execute, or action method, and contains all required information to execute it.
46
-
***Client**: The application or component that is aware of the Receiver, Invoker and Commands.
Copy file name to clipboardExpand all lines: composite/README.md
+2-14Lines changed: 2 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,23 +16,11 @@ Cover | Links
16
16
17
17
## Overview
18
18
19
-
The **Composite** design pattern is a structural pattern useful for hierarchal management.
20
-
21
-
The Composite design pattern,
22
-
23
-
* allows you to represent individual entities(leaves) and groups of leaves at the same.
24
-
* is a structural design pattern that lets you compose objects into a changeable tree structure.
25
-
* is great if you need the option of swapping hierarchal relationships around.
26
-
* allows you to add/remove components to the hierarchy.
27
-
* provides flexibility of structure
28
-
29
-
Examples of using the Composite Design Pattern can be seen in a filesystem directory structure where you can swap the hierarchy of files and folders, and also in a drawing program where you can group, un-group, transform objects and change multiple objects at the same time.
19
+
*...Refer to Book or Videos for extra content.*
30
20
31
21
## Terminology
32
22
33
-
***Component Interface**: The interface that all leaves and composites should implement.
34
-
***Leaf**: A single object that can exist inside or outside of a composite.
35
-
***Composite**: A collections of leaves and/or other composites.
Copy file name to clipboardExpand all lines: decorator/README.md
+2-14Lines changed: 2 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,23 +17,11 @@ Cover | Links
17
17
18
18
## Overview
19
19
20
-
The **decorator pattern** is a structural pattern, that allows you to attach additional responsibilities to an object at runtime.
21
-
22
-
The decorator pattern is used in both the Object Oriented and Functional paradigms.
23
-
24
-
The decorator pattern is different than the Python language feature of [Python Decorators](https://www.python.org/dev/peps/pep-0318/#on-the-name-decorator) in its syntax and complete purpose. It is a similar concept in the way that it is a wrapper, but it also can be applied at runtime dynamically.
25
-
26
-
The decorator pattern adds extensibility without modifying the original object.
27
-
28
-
The decorator forwards requests to the enclosed object and can perform extra actions.
29
-
30
-
You can nest decorators recursively.
20
+
*...Refer to Book or Videos for extra content.*
31
21
32
22
## Terminology
33
23
34
-
***Component Interface**: An interface for objects.
35
-
***Component**: The object that may be decorated.
36
-
***Decorator**: The class that applies the extra responsibilities to the component being decorated. It also implements the same component interface.
0 commit comments