http://www.it.uu.se/edu/course/homepage/asd/ht14/Lecture%204.pdf
https://web.cs.dal.ca/~jin/3132/lectures/dp-13.pdf
https://www.cs.cmu.edu/~aldrich/214/slides/design-grasp.pdf
https://dzone.com/articles/solid-grasp-and-other-basic-principles-of-object-o
A collection of patterns/principles for achieving good design – patterns of assigning responsibility. Refer to software objects not domain objects.
- Low coupling
- High cohesion
- Creator
- Information expert
- Controller
- Polymorphism
- Indirection
- Pure fabrication
- Protected variations
Read more here: https://gist.github.com/dimabory/140223715fe24025eeacc78251f063b0
Problem: How to reduce the impact of change? Advice: Assign responsibilities so that (unnecessary) coupling remains low.
Use this principle to evaluate alternatives. Focus on points of realistic instability or evolution.
Drawback: may add additional layers of indirection.
Read more here: https://gist.github.com/dimabory/140223715fe24025eeacc78251f063b0
Problem: How to keep objects focussed, understandable, and manageable, and as a side effect, support Low Coupling? Advice: Assign responsibilities so that cohesion remains high.
Use this to evaluate alternatives.
Problem: Who creates an A? Advice: Assign class B the responsibility to create an instance of class A if one of these is true (the more the better):
- B “contains” or compositely aggregates A.
- B records A.
- B closely uses A.
- B has the initialising data for A.
Problem: What is the basic principle by which to assign responsibilities/functionality to objects? Advice: Assign a responsibility to a class that has the information needed to fulfil it.
Problem: What first object beyond the UI layer receives and coordinates (“controls”) a system operation? Advice: Assign the responsibility to an object representing one of these choices:
- Represents the overall “system”, a “root object”, a device that the software is running within, or a major subsystem (these are all variations of a facade controller).
- Represents a use case scenario within which the system operation.
Avoid bloated controllers.
Problem: How to handle alternatives based on type? How to create pluggable software components? Advice: When related alternatives or behaviours vary by type (class), assign responsibility for the behaviour — using polymorphic operations— to the types for which the behaviour varies.
Avoid adding flexibility just because you can.
Problem: Where to assign a responsibility, to avoid direct coupling between two (or more) classes? How to decouple objects so that low coupling is supported and reuse potential remains higher? Advice: Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled.
Problem: What object should have the responsibility, when you do not want to violate High Cohesion and Low Coupling, or other goals, but solutions offered by Information Expert (for example) are not appropriate? Advice: Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a domain concept—sometimes invented to support high cohesion, low coupling, and reuse.
Problem: How to design objects, subsystems, and systems so that the variations or instability in these elements does not have an undesirable impact on other elements? Advice: Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them.
Interface is used in broadest sense – not just Java interfaces.