Update for 15-03-22 22:45
This commit is contained in:
parent
f2ac305bfb
commit
7d014951ac
@ -64,12 +64,14 @@ Different ways to store and operate on data, with differing efficiency
|
|||||||
|
|
||||||
* [[singleton]]
|
* [[singleton]]
|
||||||
* [[prototype]]
|
* [[prototype]]
|
||||||
|
* [[builder]]
|
||||||
|
|
||||||
=== Structural ===
|
=== Structural ===
|
||||||
|
|
||||||
|
* [[composite]]
|
||||||
|
|
||||||
=== Behavioral ===
|
=== Behavioral ===
|
||||||
|
|
||||||
* builder
|
|
||||||
* factory
|
* factory
|
||||||
* facade
|
* facade
|
||||||
* proxy
|
* proxy
|
||||||
|
25
tech/builder.wiki
Normal file
25
tech/builder.wiki
Normal file
@ -0,0 +1,25 @@
|
|||||||
|
= Builder =
|
||||||
|
|
||||||
|
This is a design pattern where you create a complex object step by step. The
|
||||||
|
pattern allows you to produce different types and representations of an object
|
||||||
|
using the same construction code.
|
||||||
|
|
||||||
|
This is often used when you have an object with a large number of constructor
|
||||||
|
paramaters due to the complexity of said object. Or, when you have a large
|
||||||
|
number of subclasses for specific variations on the object.
|
||||||
|
|
||||||
|
What we can do therefore is create a *builder* class who has several functions
|
||||||
|
that can be called to modify some object to be created, then return the object
|
||||||
|
once it is in a state to be returned.
|
||||||
|
|
||||||
|
== Implementation ==
|
||||||
|
|
||||||
|
For different features of the object, have a function to add that feature or
|
||||||
|
flag to the object, such as `addGPS`, `addSeats`, and `addWindows` for a car.
|
||||||
|
Have each return `this` so that they may be chained together.
|
||||||
|
|
||||||
|
== Use case ==
|
||||||
|
|
||||||
|
* when code needs to create different representations of the same product, such
|
||||||
|
as a sports car, truck, and sedan
|
||||||
|
|
1
tech/composite.wiki
Normal file
1
tech/composite.wiki
Normal file
@ -0,0 +1 @@
|
|||||||
|
= Composite =
|
@ -5,4 +5,22 @@ code dependent on their classes.
|
|||||||
|
|
||||||
The general idea is sometimes we need an exact clone of an object. We cant copy
|
The general idea is sometimes we need an exact clone of an object. We cant copy
|
||||||
the object exactly from the outside, as we dont know the private fields.
|
the object exactly from the outside, as we dont know the private fields.
|
||||||
Therefore, the object can implement a `clone` method
|
Therefore, the object can implement a `clone` method to return an exact copy of
|
||||||
|
the object. Such an object that implements `clone` is a *prototype*
|
||||||
|
|
||||||
|
== Prototype registry ==
|
||||||
|
|
||||||
|
Some objects are commonly copied, and therefore we can cache them in a
|
||||||
|
[[hash_table]] for O(1) lookup, then just call `clone` on the object and return
|
||||||
|
the new object.
|
||||||
|
|
||||||
|
== Implementation ==
|
||||||
|
|
||||||
|
Often it only needs to be a method, `clone()` which returns the same type as
|
||||||
|
`this`, and just calls `return myObject(this)`.
|
||||||
|
|
||||||
|
== Use case ==
|
||||||
|
|
||||||
|
* when code shouldnt depend on the concrete classes of objects that you need to
|
||||||
|
copy
|
||||||
|
* Reduce number of subclasses that differ in how their init their subobjects
|
||||||
|
Loading…
Reference in New Issue
Block a user