Series SOLID Principles

Continue the Clean Code series, I'll talk about SOLID principles. Do you know, the term SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable. The principles are a subset of many principles promoted by Robert C. Martin. Though they apply to any object-oriented design, the SOLID principles can also form a core philosophy for methodologies such as agile development or adaptive software development.

Single Responsibility Principle

• Classes should have only one responsibility - one reason to change.

• To understand more about SRP, refer to the following example:
• Initial request:
  - Contains student information such as student name, type of student (regular, talented, foreign)
  - Formatting student information by text, html and json.
  - Archive persistence student information to database and file.

• Problem:
  - As the code grows, more functionality, class Student will be bulging.
  - If there are other classes such as Person, Teacher, etc., the code display / store information will be scattered in many classes, difficult to repair and upgrade. 
• Request for change:
  - The format for displaying student information in text, xml, and json format replaces the getInfoHTML() method with the getInfoXml() method.
  - Archive persistence student information to database, file and cloud firebase >> add saveToFirebase() method.
  - Test all the methods in the Student class.
• Solution:
  - Split into multiple classes, each with its own function.
  - When upgrading and repairing, it will take place in each class, not affect the remaining classes. 

Open-Closed Principle

• Classes should be open for extension but closed for modification. 

• For example, you have a DSLR camera, you have a kit lens attached to the machine to capture the landscape of flowers, now you want to have "professional portraits" how to?
  >> We will use the lens designed to specialize portraits, not to bring the kit lens is out to correct.
• To understand more about OCP, refer to the following example:
• Initial request:
  - There are three tuition fees for three different types of students:
      + Regular student = Standard tuition fee
      + Talented student = standard tuition fee * 0.8
      + Foreign students = standard tuition fees * 1.3
  - Add student tuition payment behavior.

• Request for change:
  - One more type of graduate student with tuition = standard tuition fee * 1.5
  >> change method payTuitionFee().
• Solution:
  - Build each student into different classes and inherit from the Student class.
  - Each type of student installs the payTuitionFee() method according to their tuition rates.

 

Liskov Substitution Principle

• Objects in a program should be replaceable with instances of their sub types without altering the correctness of that program.

• To understand more about LSP, refer to the following example:
• Initial request:
  - Each student can apply for a scholarship to be considered for an award.
  - However, foreign students are not allowed to apply scholarships.

• Problem:
  - If there are only domestic students (regular students, talented students), the program runs smoothly, with no compiler errors, and we think we have programmed correctly.
  - Suddenly, the school has more foreign students, the program crashed.
  - Design like this hidden money risk "run okay in the short term, but serious bugs in the long term" when expanding the program. 
• Solution:
  - In order to meet the requirements of the software, and to make the program stable in the long run, we need to ensure that the program will immediately error with us when compile-error, avoid the situation. thrown Exception (runtime-error).

Interface Segregation Principle

• Many client-specific interfaces are better than one general-purpose interface. 

• Initial request:
  - All students are required to take courses in English, French, Mathematics and Philosophy.
  - Full-time students study English, Mathematics and Philosophy.
  - Talented students learn English, French and Math.
  - Foreign students study English and Math.

• Problem:
  - Not all students must study all subjects >> There are many empty methods.
  To handle:
  - Split the general interface into several separate interfaces.

 

Dependency Inversion Principle

• Classes should depend upon abstractions, not on concrete details.

• For example, the electrical system should not depend on the hairdryer, but the hair dryer should depend on the electrical system. 
• The high-end module (electrical system) needs an abstract definition (outlet) for the hair dryer to be plugged in (the hair dryer is a specific module of the outlet interface), ie the hair dryer needs to be plugged in. It must comply with the standard socket, all other standard-compliant devices plug into the electrical system. 
• That's why the Dependency Inversion Principle is called the Dependency Inversion Principle.
• Initial request:
  - The results of applying for a scholarship will be notified to the student through the email channel.

• Request for change:
  - The application of scholarship application will be notified to students via e-mail or SMS, depending on the needs of the students.

• Problem:
  - Depending on the needs of the student who wants to communicate with the channel, the applyScholarship() method must be changed. 
• Solution:
  - Do not use live details like Email or Sms.
  - Use the abstract class Notification to easily change according to the needs of students.

See you in the next topic about Design Pattern...