we have an interface, but we want a different one, and building an adapter over the interface is what gets us to where we want to be.
We have an interface that DrawsPoint(); We need to build adapter that can take VectorObjects to collection of lines to collection of points so that we can draw them using DrawsPoint()
Imagine that your application deals with Youtube API and in order to get access token, you have to call a function called getYoutubeToken(); So, you called this function in 20 different places in your application (which is a problem if Google releases a new version of YouTube API (possibly changing methodNames))...
so build a YouTubeAdapter class
Problem is having like having RedCircle, BlueCircle, GreenCircle, etc...
Principal goal of the Bridge design pattern is to avoid excessive proliferation of data types where there are two or more dimensions, or aspects of a system that can potentially multiply in number.
Best approach is ACTIVE AVOIDANCE (replace classes with enums, if possible)...
...simply abstract away both hierarchies if not possible and find way of connecting them
Bridge is NOTHING MORE than the application of the dependency inversion principle, where you connect two distint hierarchies together through a common parameter.
Composite design pattern allows us to provide identical interfaces for individual objects and collections of objects
Ways for an object to advertise that it is composed of something
Decorator allows us to enhance existing types without either modifying the original types (open-closed Principle) or causing an explosion of the number of derived types...
...inheritance sometimes fails because base class is 'sealed' or you need to inherit something else
A Decorator gives a class additional functionality while adhering to the OCP and mitigating issues related to sealed classes and multiple inheritance.
Multiple Inheritance in addition to extending SEALED classes, Decorator also shows up when you want to have multiple base classes, which cannot do because c# does not support multiple inheritance.
Dynamic Decorators which can store references to the decorated objects and provide dynamic (runtime) composability
Static Decorators preserve the information about the type of the objects involved in the decoration
complex interaction of different parts is required for something to get done we might want to put it behind a much simpler interface (facade)
Facade is a way of putting a simple interface in front of one or more complicated subsystems.
Make your code easier to understand (hide complexity) and to make dependencies as loosely coupled as possible.
A place where you will see facades often is Angular using its services as a means of simplifying background logic.
Trading Terminals first part of a terminal window is the buffer. (rendered characters are stored) Rectangular area of memory, typically a ID2 or 2D char or wchar_t array A buffer can be much larger than the visible area of the terminal window, so it can store some historical output to which you can scroll back. viewport(rectangular area of buffer) console (terminal window itself) can Create a faster terminal scren using something like OpenGL API
Temporary component that acts as a smart reference to something (sometimes called token or cookie)
fundamentally a space-saving technique
DotNet example is Span
store a name once and then references to it... separate First and Last Name and store in an indexed store and then simply store the index value instead of actual string
Similar to Decorator Pattern but tries to preserve exactly (or as closely as possible) the API that is being used while offering internal enhancements
Have a Car class AND want to check drivers age before allowing to use the Drive method
expose ICar interface AGAIN in a CarProxy class CarProxy takes a Driver in the constructor (Driver contains the age) private Car car = new Car(); INSIDE of the CarProxy class
just moving something that's running on the same server / system to somewhere remote like a web API and pinging it etc...