S.O.L.I.D

Question 1

[S]ingle Responsibility Principle

SRP

Answer 1

A class should have one, and only one, reason to change.

Cohesion is defined as the functional affinity of a Module’s element.

Question 2

[O]pen/Closed Principle

OCP

Answer 2

You should be able to extend a classes behavior, without modifying it.

Note: Type classes were introduced first in Haskell as a new approach to ad-hoc polymorphism.

Question 3

[L]iskov Substitution Principle

LSP

Answer 3

Derived classes must be replaceable for their base classes.

LSP is the enabling principle of the Open/Closed Principle

Despite Inheritance is a powerful mechanism, it must be used contextualized and moderating, avoiding cases of classes being extended only by having something in common.

Composition is easier to test , to maintain and less prone to errors

Traits concerns
Traits to model behaviors

Question 4

[I]nterface Segregation Principle

ISP

Answer 4

it’s better to have very specific interfaces than a general interface

Interfaces that have many Behaviors are difficult to maintain and evolve.

Make fine grained interfaces that are client specific

Cohesion in Interfaces

Interfaces = Behaviors

“fat” classes, can cause bizarre and damaging couplings to business rules.

Question 5

[D]ependency Inversion Principle

DIP

Answer 5

Depend on abstractions, not on concretions.

“High-level modules should not depend on low-level modules. Both should depend on abstractions.”

“Abstractions should not depend on details. Details should depend on abstractions.”

Abstractions change less and make it easier to change behaviors and future code evolutions.

Question 6

S.O.L.I.D

Answer 6

is an acronym that represents five principles of object-oriented programming and code design theorized by our beloved Uncle Bob

Question 7

Cohesion

Answer 7

Cohesion is defined as the functional affinity of a Module’s element.

It refers to the Relationship that the Members of this Module have if they have a more Direct and Important Relationship.