Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Architecture and Clean Code Design in OOP - Coggle Diagram
Software Architecture and Clean Code Design in OOP
SOLID
is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible, and maintainable
The
Open–closed principle
: "Software entities ... should be open for extension, but closed for modification."
A module will be said to be closed if [it] is available for use by other modules. This assumes that the module has been given a well-defined, stable description (the interface in the sense of information hiding)
A module will be said to be open if it is still available for extension. For example, it should be possible to add fields to the data structures it contains, or new elements to the set of functions it performs.
The
Liskov substitution principle
: "Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it".
Bird all can walk but not all can fly
The
Interface segregation principle
: "Many client-specific interfaces are better than one general-purpose interface."
no client should be forced to depend on methods it does not use
The
Dependency inversion principle
: "Depend upon abstractions, [not] concretions."
High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces).
Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
The
Single-responsibility principle
: "There should never be more than one reason for a class to change." In other words, every class should have only one responsibility.
a computer-programming principle that states that every module, class or function in a computer program should have responsibility over a single part of that program's functionality, and it should encapsulate that part. All of that module, class or function's services should be narrowly aligned with that responsibility
Clean Code architecture
is used when dealing with large project, In order to keep business logic intact and separating the files or classes into components that can change independently of other components.
https://www.freecodecamp.org/news/a-quick-introduction-to-clean-architecture-990c014448d2/
Coupling 耦合
coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are;[1] the strength of the relationships between modules
Cohesion 凝聚
Code should have low coupling and high cohesion :red_flag:
info
Tell, don’t ask
ASK method
Age age = sebastian.getAge();
if (age >= 18) {
letDoTheThingsThatAdultsDoes(sebastian);
}
TELL method
if (sebastian.isAdult()) {
letDoTheThingsThatAdultsDoes(sebastian);
}
Disadvantages
Violation of Single Responsibility Principle
Lower code readability
Maintenance and support become more complicated
Encapsulation principle violation
Summary
Foster object-oriented code design
Delegate an action to an object directly instead of forcing client to ask state of the object to modify it
Help us to separate responsibility between classes
Achieving object-oriented modularity
Demeter’s Law
: Don’t talk to strangers!
The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs.
Each unit should have only limited knowledge about other units — only units “closely” related to the current unit.
Each unit should only talk to its friends — don’t talk to strangers.
Only talk to your immediate friends.
the Law of Demeter requires that a method m of an object O may only invoke the methods of the following kinds of objects:
O itself.
m’s parameters.
Any objects created/instantiated within m.
O’s direct component objects.
A global variable, accessible by O, in the scope of m.
is not applicable for
Data Structures :4:.30"
