-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
746d5cd
commit 52d76e6
Showing
23 changed files
with
50 additions
and
275 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,10 +1 @@ | ||
## Introducing Adapter pattern | ||
|
||
the adapter pattern is a software design pattern (also known as wrapper, an alternative naming shared with the decorator pattern) that allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code. | ||
|
||
|
||
|
||
### about Example | ||
|
||
|
||
is an adapter that converts the interface of a Document Object Model of an XML document into a tree structure that can be displayed. | ||
allows incompatible interfaces (objects) to work together and acts as a bridge between two incompatible objects |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,13 +1,2 @@ | ||
## Introducing Bridge pattern | ||
|
||
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. | ||
|
||
More : https://refactoring.guru/design-patterns/bridge | ||
|
||
|
||
|
||
### about Example | ||
|
||
|
||
Storing different information(file,text,json) based on different Order(public,CompnayProduct,...) | ||
|
||
• It separates the construction of a complex object from its representation | ||
• We can use the same construction process to create different displays. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,25 +1 @@ | ||
the Chain of Responsibility relies on transforming particular behaviors into stand-alone objects called handlers. | ||
In our case, each check should be extracted to its own class with a single method that performs the check. | ||
The request, along with its data, is passed to this method as an argument. | ||
|
||
The pattern suggests that you link these handlers into a chain. | ||
Each linked handler has a field for storing a reference to the next handler in the chain. | ||
In addition to processing a request, handlers pass the request further along the chain. | ||
The request travels along the chain until all handlers have had a chance to process it. | ||
|
||
Here’s the best part: a handler can decide not to pass the request further down the chain and effectively stop any further processing. | ||
|
||
In our example with ordering systems, a handler performs the processing and then decides whether to pass the request further down the chain. | ||
Assuming the request contains the right data, all the handlers can execute their primary behavior, whether it’s authentication checks or caching. | ||
|
||
|
||
---- | ||
|
||
Chain of Responsibility and Decorator have very similar class structures. | ||
Both patterns rely on recursive composition to pass the execution through a series of objects. However, there are several crucial differences. | ||
|
||
The CoR handlers can execute arbitrary operations independently of each other. | ||
They can also stop passing the request further at any point. | ||
On the other hand, various Decorators can extend the object’s behavior while keeping it consistent with the base interface. | ||
In addition, decorators aren’t allowed to break the flow of the request. | ||
|
||
lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,2 +1 @@ | ||
The Command design pattern encapsulates a request as an object, thereby letting you parameterize clients with different requests, | ||
queue or log requests, and support undoable operations. | ||
encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,10 +1 @@ | ||
The Composite design pattern composes objects into tree structures to represent part-whole hierarchies. | ||
This pattern lets clients treat individual objects and compositions of objects uniformly. | ||
|
||
|
||
• IComponent: This is a shared interface that specifies the operation each component needs to implement. | ||
• Leaf: This is an individual component. | ||
• Composite: This is a collection of components. It can include both leaves and other composites. | ||
• Client: This class has access to different components via the shared interface IComponent, taking advantage of polymorphism. | ||
|
||
|
||
lets you compose objects into tree structures and then work with these structures as if they were individual objects. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,16 +1 @@ | ||
Extending a class is the first thing that comes to mind when you need to alter an object’s behavior. | ||
However, inheritance has several serious caveats that you need to be aware of. | ||
|
||
Inheritance is static. You can’t alter the behavior of an existing object at runtime. | ||
You can only replace the whole object with another one that’s created from a different subclass. | ||
Subclasses can have just one parent class. | ||
In most languages, inheritance doesn’t let a class inherit behaviors of multiple classes at the same time. | ||
One of the ways to overcome these caveats is by using Aggregation or Composition instead of Inheritance. | ||
Both of the alternatives work almost the same way: | ||
one object has a reference to another and delegates it some work, whereas with inheritance, | ||
the object itself is able to do that work, inheriting the behavior from its superclass. | ||
|
||
With this new approach you can easily substitute the linked “helper” object with another, changing the behavior of the container at runtime. | ||
An object can use the behavior of various classes, having references to multiple objects and delegating them all kinds of work. | ||
Aggregation/composition is the key principle behind many design patterns, including Decorator. On that note, let’s return to the pattern discussion. | ||
|
||
lets you attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1 @@ | ||
A facade is a class that provides a simple interface to a complex subsystem which contains lots of moving parts. | ||
A facade might provide limited functionality in comparison to working with the subsystem directly. | ||
However, it includes only those features that clients really care about. | ||
|
||
Having a facade is handy when you need to integrate your app with a sophisticated library that has dozens of features, | ||
but you just need a tiny bit of its functionality. | ||
|
||
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,25 +1 @@ | ||
Flyweight is a structural design pattern that allows programs to support vast quantities of objects by keeping their memory consumption low. | ||
|
||
|
||
• Flyweight: | ||
This is the interface that defines the behavior for the Flyweight concrete classes to perform operations on the extrinsic properties (states). | ||
An abstract can also be used in place of the interface. | ||
|
||
|
||
• ConcreteFlyweight: | ||
This class inherits from the Flyweight interface and provides the functionality and the stateless information that will be shared across the objects. | ||
|
||
|
||
• UnsharedFlyweight: | ||
The UnsharedFlyweight inherits from the Flyweight interface and provides the possibility of creating a stateful object that is not shared. | ||
|
||
|
||
• FlyweightFactory: | ||
This is the factory class that maintains a reference list of all Flyweight objects that have been created, and when the client demands a new object, | ||
first it is checked in the list, if the required object is found then it is returned to the client. If the requested object is not present | ||
, then a new one is created, added to the reference list and the same is returned to the client. | ||
|
||
|
||
• Client: | ||
This is the consumer of the Flyweight objects and maintains a reference of all the objects it is using as well | ||
as it also computes and maintains the extrinsic state of the object. | ||
lets you fit more objects into the available amount of RAM by sharing common parts of state between multiple objects instead of keeping all of the data in each object. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,9 +1 @@ | ||
## Introducing iterator pattern | ||
|
||
In object-oriented programming, the iterator pattern is a design pattern in which an iterator is used to traverse a container and access the container's elements. | ||
The iterator pattern decouples algorithms from containers; in some cases, algorithms are necessarily container-specific and thus cannot be decoupled. | ||
|
||
### about Example | ||
|
||
This is example about Remove duplicates adjacent with iterator pattern in C# | ||
|
||
used to get a way to access the elements of a collection object in sequential manner without any need to know its underlying representation |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,27 +1 @@ | ||
The Memento’s principle can be achieved using serialization, which is quite common in C#. While it’s not the only and the most efficient way to make snapshots of an object’s state, it still allows storing state backups while protecting the originator’s structure from other objects. | ||
|
||
1. Originator | ||
This is a class that creates a memento object containing a snapshot of the Originator's current state. It also restores the Originator to a previously stored state by using SetMemento operation. | ||
2. Memento | ||
This is a class that holds the information about the Originator’s saved state. | ||
3. Caretaker | ||
This is a class that is used to hold a Memento object for later use. This acts as a store only; it never examines or modifies the contents of the Memento object. | ||
|
||
|
||
When considering the use of the Memento pattern, keep the following in mind: | ||
• Memory Implications: Depending on the size of the object’s state and how often mementos are created, the pattern can consume a significant amount of memory. | ||
• Encapsulation: The memento should not expose the internal state details of the originator. Ensure that you’re not breaking encapsulation when implementing the pattern. | ||
So, any situation where you anticipate the need to revert to an earlier state or where maintaining a history of states is beneficial is a potential candidate for the Memento pattern. | ||
Advantages and Disadvantages of Memento Design Pattern | ||
The Memento Design Pattern offers a structured way to capture and restore the internal state of an object without violating its encapsulation. However, as with any design pattern, it has advantages and disadvantages. | ||
Advantages of Memento Design Pattern: | ||
• Preserve Encapsulation: The Memento pattern enables you to save and restore the state of an object without exposing its internal structure. | ||
• Simplifies Originator: By offloading the responsibility of preserving the object’s state to the separate Memento object, the Originator class becomes less complicated. | ||
• Undo Capabilities: The pattern naturally provides an undo mechanism, which can be useful in applications like text editors, graphic editors, and game states. | ||
• History Management: It can maintain a history of states useful in features like branching or version histories. | ||
Disadvantages of Memento Design Pattern: | ||
• Memory Consumption: If not managed properly, keeping too many mementos can lead to high memory usage, especially if the mementos store a lot of state information or are saved frequently. | ||
• Overhead: Creating mementos might introduce runtime overhead, especially if the state is complex or is done frequently. | ||
• Maintenance Complexity: If the internal state of the Originator changes (like when new fields are added), you’ll need to ensure the Memento class is updated appropriately, which can lead to maintenance issues. | ||
• Tight Coupling: Even though the Memento pattern preserves encapsulation from the client’s perspective, the Memento class often has to be tightly coupled with the Originator to access its internal state. This can be a problem if you need to change the structure of the Originator or make it work with mementos created from a different version of the Originator. | ||
• State Integrity: Care must be taken to ensure the integrity of the saved state. If, for some reason, a memento gets corrupted or is not in sync with the originator’s structure, restoring from such a memento can lead to undefined behavior. | ||
lets you save and restore the previous state of an object without revealing the details of its implementation. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,15 +1,2 @@ | ||
The Observer pattern provides a way to subscribe and unsubscribe to and from these events for any object that implements a subscriber interface. | ||
|
||
Usage examples: The Observer pattern is pretty common in C# code, especially in the GUI components. | ||
It provides a way to react to events happening in other objects without coupling to their classes. | ||
|
||
Identification: The pattern can be recognized by subscription methods, | ||
that store objects in a list and by calls to the update method issued to objects in that list. | ||
|
||
--- | ||
The Observer design pattern defines a one-to-many dependency between objects so that when one object changes state, | ||
all its dependents are notified and updated automatically. | ||
|
||
|
||
|
||
|
||
lets you define a subscription mechanism to notify multiple objects about any events that happen to the object they’re observing. | ||
It establishes a one-to-many relationship between a subject and its observers. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,25 +1 @@ | ||
The Prototype pattern is a creational design pattern that allows you to create new objects by cloning existing objects. | ||
|
||
In other words, the Prototype pattern allows you to create new objects from existing ones by cloning them without specifying the exact class of the objects. | ||
|
||
The Prototype pattern is useful when you need to create new objects that are similar to existing ones but with some differences in their state or behavior. | ||
|
||
The Prototype pattern is also helpful for creating a new object that is complex and may incur overhead. | ||
So you want to avoid the complexity and the overhead by cloning an existing object instead of creating a new one from scratch. | ||
|
||
|
||
|
||
The Prototype pattern involves the following participants: | ||
|
||
Prototype: | ||
The Prototype can be an interface or an abstract class. The Prototype interface (or abstract class) has the Clone() method | ||
that creates a new object from an existing object. | ||
|
||
ConcretePrototype: | ||
This is a concrete class of the Prototype interface. The ConcretePrototype class implements the Clone() method for cloning an object. | ||
|
||
Client: | ||
This is the client code that uses the Prototype interface for creating new objects. | ||
The client creates a new object by cloning an existing object and then customizes the cloned object as needed. | ||
|
||
|
||
lets you copy existing objects without making your code dependent on their classes. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
lets you provide a substitute or placeholder for another object. A proxy controls access to the original object, allowing you to perform something either before or after the request gets through to the original object. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
ensures a class has only one instance and provides a global point of access to that instance. Includes | ||
• Private Constructor | ||
• private Static Instance | ||
• Public Instance Property or method | ||
• Use lock or Semaphore or … |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,12 +1,2 @@ | ||
The State pattern is a behavioral design pattern that allows an object to change its behavior when its internal state changes. | ||
The State pattern is useful when the behavior of an object depends on its state and needs to change dynamically when its state changes. | ||
|
||
The State is a behavioural design pattern that lets an object alter its behaviour when its internal state changes. For the system, it appears as if the object changed its class. | ||
The State design pattern is one of the most useful patterns described by the Gang of Four. Games often depend on the State pattern because objects can change so frequently. Many other simulations, whether they are games or not, depend on the State pattern as well. | ||
• Context | ||
• defines the interface of interest to clients | ||
• maintains an instance of a ConcreteState subclass that defines the current state. | ||
• State | ||
• defines an interface for encapsulating the behavior associated with a particular state of the Context. | ||
• Concrete State | ||
• each subclass implements a behavior associated with a state of Context | ||
lets an object alter its behavior when its internal state changes. It appears as if the object changed its class. | ||
There is system that calculate the benefits, but these benefits differ with the type of customer |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,15 +1 @@ | ||
The Observer pattern provides a way to subscribe and unsubscribe to and from these events for any object that implements a subscriber interface. | ||
|
||
Usage examples: The Observer pattern is pretty common in C# code, especially in the GUI components. | ||
It provides a way to react to events happening in other objects without coupling to their classes. | ||
|
||
Identification: The pattern can be recognized by subscription methods, | ||
that store objects in a list and by calls to the update method issued to objects in that list. | ||
|
||
--- | ||
The Observer design pattern defines a one-to-many dependency between objects so that when one object changes state, | ||
all its dependents are notified and updated automatically. | ||
|
||
|
||
|
||
|
||
lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable. |
This file was deleted.
Oops, something went wrong.
Oops, something went wrong.