feat: add Interface Segragation principle implementation

Author: angelo.yanve

04-SOLID/04x04_ISP/README.md

@@ -0,0 +1,12 @@
+## Example
+
+### Description
+Here we are going to take an example on a `AudioPlayer`, `VideoPlayer` and `MediaPlayer` interface.
+
+### Bad point of view
+In the bad ISP example, we have a `MediaPlayer` interface that has methods for both audio and video. This is a violation of the ISP because the `AudioPlayer` and `VideoPlayer` classes are forced to implement methods that they don't need.
+
+### Good point of view
+In the good ISP example, we have a `AudioPlayer` interface and a `VideoPlayer` interface. This is a better design because the `AudioPlayer` and `VideoPlayer` classes are only forced to implement the methods that they need.
+
+Then We can see a use cases example 

04-SOLID/04x04_ISP/bad.ts

@@ -0,0 +1,46 @@
+
+interface MediaPlayer{ 
+    playAudio(): void;
+    playVideo(): void;
+    showLyrics(): void;
+    showSubtitles(): void;
+}
+
+class _MusicApp implements MediaPlayer {
+    playAudio() {
+        console.log('Playing audio');
+    }
+    playVideo() {
+        console.log('Playing video');
+        // This method is not needed for MusicApp
+        //! Here we are breaking the Interface Segregation Principle
+    }
+    showLyrics() {
+        console.log('Showing lyrics');
+    }
+    showSubtitles() {
+        console.log('Showing subtitles');
+        // This method is not needed for MusicApp
+        //! Here we are breaking the Interface Segregation Principle
+    }
+}
+
+class _VideoPlayer implements MediaPlayer {
+    playAudio() {
+        console.log('Playing audio');
+        // This method is not needed for VideoPlayer
+        //! Here we are breaking the Interface Segregation Principle
+    }
+    playVideo() {
+        console.log('Playing video');
+    }
+    showLyrics() {
+        console.log('Showing lyrics');
+        // This method is not needed for VideoPlayer
+        //! Here we are breaking the Interface Segregation Principle
+    }
+    showSubtitles() {
+        console.log('Showing subtitles');
+    }
+}
+

04-SOLID/04x04_ISP/good.ts

@@ -0,0 +1,46 @@
+interface AudioPlayer {
+    playAudio(): void;
+    showLyrics(): void;
+}
+
+interface VideoPlayer {
+    playVideo(): void;
+    showSubtitles(): void;
+}
+
+class MusicApp implements AudioPlayer {
+    playAudio() {
+        console.log('Playing audio');
+    }
+    showLyrics() {
+        console.log('Showing lyrics');
+    }
+}
+
+class VideoPlayer implements VideoPlayer {
+    playVideo() {
+        console.log('Playing video');
+    }
+    showSubtitles() {
+        console.log('Showing subtitles');
+    }
+}
+
+// This way we are following the Interface Segregation Principle
+// We are not forcing the clients to implement methods they don't need
+
+//? This is just an example to know that we can implement multiple interfaces in a class 
+class MusicVideoApp implements AudioPlayer, VideoPlayer {
+    playAudio() {
+        console.log('Playing audio');
+    }
+    showLyrics() {
+        console.log('Showing lyrics');
+    }
+    playVideo() {
+        console.log('Playing video');
+    }
+    showSubtitles() {
+        console.log('Showing subtitles');
+    }
+}

04-SOLID/README.md

@@ -12,23 +12,29 @@ Principle SOLID 5 software design principles that help to create a good software
 - Interface Segregation Principle
 - Dependency Inversion Principle
 
-### Single Responsibility Principle (SRP)
+## Single Responsibility Principle (SRP)
 ***A class should have only one reason to change*** \
 We determine responsability of one class according to the **social structure** of the **users usage**. \
 **Example:** go to file [SingleResponsibilityPrinciple](./04x01_SRP)
 
-### Open-Closed Principle (OCP)
+## Open-Closed Principle (OCP)
 ***A class should be open for extension, but closed for modification*** \
 This principle is about **extending** the behavior of a class without **modifying** it. So to add new functionality, it shouldn't require changing the existing code.
 
 **Tips**: To do this, we write **interfaces** and **abstract classes** in order to dictate the higher-level policy that needs to be implemented, and then we implement that policy using concrete classes.
 
 **Example:** go to file [OpenClosedPrinciple](./04x02_OCP)
 
-### LisKov-Substitution Principle (LSP)
+## LisKov-Substitution Principle (LSP)
 ***Derived classes must be substitutable for their base classes*** 
 
-
 This principle is about **inheritance** and **polymorphism**. It states that if a program is using a base class, then the reference to the base class can be replaced with a derived class without affecting the functionality of the program.
 
-**Example:** go to file [LiskovSubstitutionPrinciple](./04x03_LSP)
+**Example:** go to file [LiskovSubstitutionPrinciple](./04x03_LSP)
+
+## Interface Segregation Principle (ISP)
+***A client should never be forced to implement an interface that it doesn't use*** 
+
+This principle is about **interfaces**. It states it’s better to have `smaller`, `focused` **interfaces** rather than large, monolithic ones.
+
+**Example:** go to files[InterfaceSegregationPrinciple](./04x04_ISP)