-
Notifications
You must be signed in to change notification settings - Fork 0
Creational Design Patterns
Primarily named and practiced around OOP. Fundamentally an encapsulation, abstraction, and DRY effort. Attempts to solve design problems that arise from complicated object and class instantiation, such as:
🔴 Needing to know the actual "concrete" names of one or more classes
🔴 Needing to establish the state of an object via many setters, sometimes in a specific order
🔴 Needing to retrieve the state of an object via getters, with results that require further work or need to be handled by additional objects — though it's really those results — "get me this" — that fall under "creational" consideration
🔴 Refining program design later, and needing to modify all instances of creation and/or object interaction during creation
Creational patterns thus attempt to alleviate "instantiation hell." They encapsulate the work and knowledge that is often required around the new keyword.
🟢 Less "hard-coded" way of thinking — can easily override creation methods and classes (may be necessary in unit testing at minimum)
🟢 Can hide complexity surrounding object interaction, and easily change that process across an app
🟢 Focus on behavior over object creation and setup
🟢 Can track/monitor how many objects exist and if needed return an existing one instead of creating something new
🔴 Need to re-think program design to accommodate existence of many "creators," which is easier to do in the beginning than halfway through
🔴 For some scenarios these approaches may feel "over-engineered"
🔴 May be confusing to new programmers who aren't as experienced with real-world "instantiation hell"
🟡 Need to think about how it aids or hinders dependency injection if also using it
Two generic approaches are:
⚪ Object-creational — Define a creation object dedicated to the work surrounding an object's creation
⚪ Class-creational — Subclasses determine creation details (in constructors?)
Will at minimum contain a "creator" object.
| Name | Core concepts | Good for | Examples |
|---|---|---|---|
| Builder | ⚪ Creator object is a "builder" ⚪ Builder creates and assembles | 🟢 Object creation is verbose, but often similar 🟢 Object is complex and can be represented many different ways 🟢 Cases where a fluent interface feels intuitive | ⚪ jQuery ⚪ FluentQueryBuilder — .NET query building class ⚪ Many query- and tree-builders (HTML/DOM/XML/JSON), and parsers |
Instantiation by method arguments vs. configuration object vs. minimal construction with setters/getters (modified state) or method-chaining. If a library or object was designed as a fluid interface, it is likely implementing a creational pattern (builder). Method chaining and fluid interfaces are different but often exist together. Note that basic language constructs can impact how much a programmer might start fighting with instantiation. But some things, such as needing to override creation behavior, exist regardless of instantiation approach.
Testing what this does?