GoF
'Design Patterns: Elements Of Reusable Object-Oriented Software.' provides 23 commonly used patterns
Links:
What is a pattern?
- Proven solutions
- Easily reused
- Expressive
Anti-pattern?
- Proven ineffective solutions
- Often accidently reused
- Unexpressive, confusing
What design patterns are used in Angular?
- DI
- Module
- MV*
- Factory
- Observe
- Facade
- More...
Debugging purposes
- When something breaks that has been designed well, its easier to figure out whats wrong
- Creating cognitive maps for software workflows helps us understand whats going wrong when it does
Evaluating solutions
- Taking the guesswork out of the process of adding new features
- Architecting applications with tried and true design features can make the software easier and more fun to maintain
Understanding frameworks
- Learn new application frameworks quickly
- Frameworks are in the business of providing common functionality that is extensible, understandable, and useful
- Defend why it is necessary.
- How practical is the pattern?
- Design patterns should be transparent
- Originality is not key
Module pattern
- Encapsulate privacy, exposing a public api
- Clean solution for shielding logic and exposing small parts of the application
- Prevents namespace conflicts and makes it easier to work with other code bases
- Javascript doesn't have a traditional notion of privacy so we use function scope to emulate this feature
AngularJS Modules
- The declarative process is easier to understand.
- You can package code as reusable modules.
- The modules can be loaded in any order (or even in parallel) because modules delay execution.
- Unit tests only have to load relevant modules, which keeps them fast.
- End-to-end tests can use modules to override configuration.
- Keep window clean of globals
- Promote DI with provider, service, factory, value, and constant module components
Links:
MV*
MVC, MVVC, MVP
A set of design patterns used to create an application
MV*
MVC, MVVC, MVP
- There a fair bit of ink spilt in regards to what makes MVC, often we defer to an application framework for this structure
- Javascript MVC are a bit of a departure from traditional MVC as the server-side interpretation of MVC doesn't translate 1:1 to the client-side
- The GoF do not refer to MVC as a design pattern, but rather consider it a set of classes to build a user interface. In their view, it's actually a variation of three classical design patterns: the Observer, Strategy and Composite patterns. Depending on how MVC has been implemented in a framework, it may also use the Factory and Template patterns. The GoF book mentions these patterns as useful extras when working with MVC.
Model
- Models manage the data for an application.
- Represent unique forms of data that an application may require
- Not concerned with the user interface
- Typcally notifify observers of changes
View
- Present the model to the viewer
- Show changes made to the model
- Delegate to the controller user actions
Controllers
- Intermediary between models and views which are classically responsible for updating the model
- Handle changes in the model
For several years +AngularJS was closer to MVC (or rather one of its client-side variants), but over time and thanks to many refactorings and api improvements, it's now closer to MVVM – the $scope object could be considered the ViewModel that is being decorated by a function that we call a Controller.
Igor Minar, maintainer of AngularJS
Links:
AngularJS MV*
The Model in angular is often adhoc...
service.getList().then(function(resp) {
$scope.list = resp.data;
});
AngularJS MV*
- Angular leaves the model in MVC up to you
- This gives us a lot of leeway in implementation
- Simple model, use constructor functions
- Model with mixins, use factory and visitor pattern
- Global mixin with provider
- Goal is modularity and maintainability
Sample application - Model layer in Angular
- Use constructor, factory, and mixin patterns for sharing functionality across implementation
- Structure for maintainability
- Allow for reuse and change, dont forget your product peeps...
Mediator Pattern
- Useful when there are too many direct relationships between components
- The pattern promotes loose coupling by ensuring that instead of components referring to each other explicitly
- Promotes code reuse and helps decouple complex systems
Links:
Sample application - Mediator
- Demonstrate implementation of a series of modals presented in order by using an mediator object
- Structure for maintainability
- Allow for reuse and change, dont forget your product team...
Command Pattern
- Encapsulate method invocation, requests or operations into a single object
- Gives us the ability to both parameterize and pass method calls
- Decouples objects invoking the action from the objects which implement them, giving us a greater degree of overall flexibility
Command Pattern
Sample application - Command
- Use a third party object to calculate limit and offset from a range so that it can be used across different implementations
- This case, we need a range picker for two completely seperate features, import/export
- Structure for maintainability, only change code once
- Allow for reuse and change, dont forget product team...