SOLID principles Flashcards
Symptoms of bad software
Confusing
Rigidity: To make a modification you need to touch a lot of stuff.
Fragility: You change something somewhere, and it breaks the software in unexpected areas that are entirely unrelated to the change you made.
Immobility (no-reusability): The software does more than what you need. The desirable parts of the code are so tightly coupled to the undesirable ones that you cannot you use the desirable parts somewhere else.
What makes a language OO?
Encapsulation
Inheritance
Polymorphism
Encapsulation: Bundling data and methods into a class while controlling access.
Inheritance: Subclass inheriting properties and behaviors from a superclass.
Polymorphism: Treating objects of different types as if they are of a common type.
Coupling
The degree of interdependence between software modules or components. It measure how closely one module is connected to, or relies on, another.
We want low coupling.
Cohesion
The degree to which the functionality within a module is related and focused on a single, well defined purpose.
High cohesion means that a module or
class is designed to perform a
specific, clear task, and it doesn’t
contain unrelated or loosely
related functionality.
Name all five principles of SOLID
Single responsible principle
Open / closed principle
Liskov substitution principle
Interface segregation principle
Dependency Inversion Principle
Single responsible principle
“a class should only have one, and only one, reason to change”
Only one reason to change and should only have one responsibility.
Open / closed principle
“software entities should be open for extensions but closed
for modifications”
You should not have to rewrite an existing class for implementing new features.
Liskov substitution principle
“derived classes should be usable through the base class interface, without the need for the user to know the difference”
Subtypes should be substitutable for their base types without altering the correctness of the program.
Interface segregation principle
“many client-specific interfaces are better than one general-purpose interface”
i.e. if you have transaction, split into deposit transaction, withdrawal transaction and transfer transaction.
Dependency-inversion principle
“depend upon abstractions, do not depend upon concretions”