Please enable JavaScript.
Coggle requires JavaScript to display documents.
Design Principles - Coggle Diagram
Design Principles
GRASP
-
Creator
Solution: In general, Assign class B the responsibility to create object A if one, or preferably more, of the following apply:
-
Controller
-
Solution: A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case. For instance, for the use cases Create User and Delete User, one can have a single class called UserController, instead of two separate use case controllers.
Indirection
Problem: Where to assign responsibility, to avoid direct coupling between two (or more) things? How to de-couple objects so that low coupling is supported and reuse potential remains higher?
Solution: Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled.
The intermediary creates an indirection between the other components.
Polymorphism
-
Solution: When related alternatives or behaviors vary by type (class), assign responsibility for the behavior—using polymorphic operations—to the types for which the behavior varies. (Polymorphism has several related meanings. In this context, it means "giving the same name to services in different objects".)
Protected variations
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?
Solution: Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them.
Pure fabrication
A pure fabrication is a class that does not represent a concept in the problem domain, specially made up to achieve low coupling, high cohesion, and the reuse potential thereof derived (when a solution presented by the information expert pattern does not). This kind of class is called a "service" in domain-driven design.
Low coupling
How dependent code parts are on each other. Low coupling is better for maintenance and cope reuse potential.
-
SOLID
-
-
-
-
Dependency principle
When classes talk to each other in a very specific way, they both depend on each other to never change. Instead classes should use promises (interfaces, parents), so classes can change as long as they keep the promise.
Means that the algorithm and its interface should be 2 different things. Can be done using abstract classes and methods. This was if class A depends on something with interface B, we do not have to specify the class, but attach different classes using the same interface