Builders
Builder Functions should return 'this'
to force users of the API to use a Builder we can make the target object's constructors inaccessible and then define a static Create() function that returns the Builder
Builder can be coerced to the object itself by defining the appropriate implicit conversion operator
you can force the client to use a Builder by specifying it as part of a parameter function
a single Builder can expose multiple subbuilders
inheritance of fluent interfaces is possible through recursive generics
Factories
it is the most used design pattern in the OOP world because it saves a lot of time in the future when you have to modify one of the classes you used
Factory Method is a class member that acts as a way of creating objects (typically replaces the constructor)
typically a separate class that knows how to construct objects
can implement caching and other storage optimizations; it is natural choice for approaches such as pooling or the Singleton pattern
Differs from the Builder in that with Factory you create the object in one go whereas with Builder it's piecewise construction
Prototype Pattern
Building from an already existing object
- 1) writing code that correctly duplicates your object (performs a deep copy)
- 2) writing code for support of serialization and deserialization (computational penalty)
Really only 2 ways to implement the Prototype Pattern
Deep vs Shallow copying
assigning jane = john doesn't work because any changes to jane object will affect John as well
with value types, the cloning problem does not really exist (cloning a struct just assign to new variable)
strings are immutable, so you can use the assignment operator = on them without worrying that subsequent modifications will affect more objects than it should
Deep Copy
Prototype Factory
Singleton Pattern
One instance of a component in your application(ex. a component that loads a database into memory adn offers a read-only interface)
Angular’s services are a prime example of the singleton pattern being used in a big popular framework.
LazyLoading Singleton
- use in other components it becomes Fimrly Dependent upon our SingletonInstance...
- ...which presents issues with Unit Testing (having to read a live database is frowned upon in Unit Testing)
- SOLUTION = create something seperate that implements the database interface so we can specify where the data is coming from and NOT DEPEND upon that singleton
Singleton Issues:
- Instead of directly enforcing the lifetime of a class, this funciton is outsourced to an Inversion of Control (IoC) container
- many people believe that using a Singleton in a DI container is the only socially acceptable use of a Singleton...
- ...with this approach if you need to replace a Singleton object with something else, you can do it in one central place: the Container Configuration code
Singletons and Inversion of Control
Monostate
