Please enable JavaScript.
Coggle requires JavaScript to display documents.
design (GRASP (Pure fabrication (A pure fabrication is a class that does…
design
GRASP
-
consist of guidelines for assigning responsibility to classes and objects in object-oriented design. It is not related to the SOLID design principle.
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).
-
Information expert
Information expert (also expert or the expert principle) is a principle used to determine where to delegate responsibilities such as methods, computed fields, and so on.
Using the principle of information expert, a general approach to assigning responsibilities is to look at a given responsibility, determine the information needed to fulfill it, and then determine where that information is stored.This will lead to placing the responsibility on the class with the most information required to fulfill it
High cohesion
-
low cohesion is a situation in which a given element has too many unrelated responsibilities. Elements with low cohesion often suffer from being hard to comprehend, reuse, maintain and change.
Low coupling
Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements
Protected variations
The protected variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.
Indirection
The indirection pattern supports low coupling and reuse potential between two elements by assigning the responsibility of mediation between them to an intermediate object. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the model-view control pattern. This ensures that coupling between them remains low.
-
-
-
Tell Don't Ask
you should endeavor to tell objects what you want them to do; do not ask them questions about their state, make a decision, and then tell them what to do
-
as the caller, you should not be making decisions based on the state of the called object that result in you then changing the state of the object The logic you are implementing is probably the called object’s responsibility, not yours. For you to make decisions outside the object violates its encapsulation.
SortedList thingy = someObject.getEmployeeList();
thingy.addElementWithKey(foo.getKey(), foo);
-
-
-
-
Instead, this should be: someObject.addToThingy(foo);
To ask is a query, to tell is a command.
LoD
-
A multilayered architecture can be considered to be a systematic mechanism for implementing the Law of Demeter in a software system. In a layered architecture, code within each layer can only make calls to code within the layer and code within the next layer down. "Layer skipping" would violate the layered architecture.
Since objects are less dependent on the internal structure of other objects, object containers can be changed without reworking their callers.
-
SOLID
DIP
-
-
low level classes the classes which implement basic and primary operations(disk access, network protocols,...)
high level classes the classes which encapsulate complex logic(business flows, ...)
-
In order to avoid such problems we can introduce an abstraction layer between high level classes and low level classes.
-
-
Example with Manager and Worker and introducing new class SuperWorker which is also managed by Manager and needs redefinition.
High-level modules, which provide complex logic, should be easily reusable and unaffected by changes in low-level modules, which provide utility features
LSP
-
All the time we design a program module and we create some class hierarchies. Then we extend some classes creating some derived classes. We must make sure that the new derived classes just extend without replacing the functionality of old classes. Otherwise the new classes can produce undesired effects when they are used in existing program modules.
Example with having interface with predefined method which is overridden in a subclass and substituting a new instance implementing that interface will result in different results returned by that method when invoked from interface and instance class.
all sub classes should have the same behavior as parent class/interface , in other words substitution doesn't change result.
OCP
-
Software entities like classes, modules and functions should be open for extension but closed for modifications.
The design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. (unit tests should not be
example : think of switch cases in e.g. Shape class handling rectangles, circles etc. What if we add another shape? We have to edit the class, so it's not closed for editions and open for additions. Instead we should change it to solution with interface and addition of new class implementing common methods.
-
-
-