added lsp, isp and dip

Author: ccarella

README.md

@@ -24,4 +24,53 @@ It might be tempting to just open up the `Guitar` class and add a flame pattern
 throw up in our application.
 
 Following OCP we create `SuperCoolGuitarWithFlames` by extending the Guitar class we can be sure that our existing 
-application won't be affected.
+application won't be affected.
+
+### Liskov Substitution
+
+**If class A is a subtype of class B, then we should be able to replace B with A without disrupting the behavior 
+of our program.**
+
+Defined a `Car` interface, we have implemented a `MotorCar`. We want to introduce electric cars which by definition
+is a car without the engine. `ElectricCar` is the implementation. This a violation of Liskov substitution principle.
+
+One possible solution would be to rework our model into interfaces that take into account the engine-less state of 
+our `Car`   
+
+### Interface Segregation Principle
+
+**Larger interfaces should be split into smaller ones. By doing so, we can ensure that implementing classes only need 
+to be concerned about the methods that are of interest to them**
+
+We define a `BearKeeper` class. As avid zookeepers, we're more than happy to wash and feed our beloved bears. 
+However, we're all too aware of the dangers of petting them.
+
+Only the crazy zookeepers can do that. But with this implementation we force every zookeepers to pet bears.
+
+We create 3 new interfaces  `BearCleaner`, `BearFeeder` and `BearPetter`.
+
+Now, thanks to interface segregation we can implement `BearCarer` and `CrazyPerson`.
+
+### Dependency Inversion Principle
+
+**The principle of Dependency Inversion refers to the decoupling of software modules. This way, instead of high-level 
+modules depending on low-level modules, both will depend on abstractions.**
+
+In `Windows98Machine` class by declaring the `StandardKeyboard` and `Monitor` with the new keyword, we've tightly 
+coupled these 3 classes together
+
+Not only does this make our Windows98Computer hard to test, but we've also lost the ability to switch 
+out our StandardKeyboard class with a different one should the need arise. And we're stuck with 
+our Monitor class, too.
+
+To implement DI we:
+
+- adding a more general Keyboard interface
+- rewrite it to `Windows98MachineDI`   
+
+Now our classes are decoupled and communicate through the Keyboard abstraction. If we want, we can easily switch out 
+the type of keyboard in our machine with a different implementation of the interface. 
+We can follow the same principle for the Monitor class.
+
+We've decoupled the dependencies and are free to test our Windows98Machine 
+with whichever testing framework we choose.

src/main/java/dip/Keyboard.java

@@ -0,0 +1,4 @@
+package dip;
+
+public interface Keyboard {
+}

src/main/java/dip/Monitor.java

@@ -0,0 +1,4 @@
+package dip;
+
+public class Monitor {
+}

src/main/java/dip/StandardKeyboard.java

@@ -0,0 +1,4 @@
+package dip;
+
+public class StandardKeyboard implements Keyboard {
+}

src/main/java/dip/Windows98Machine.java

@@ -0,0 +1,13 @@
+package dip;
+
+public class Windows98Machine {
+
+    private final StandardKeyboard keyboard;
+    private final Monitor monitor;
+
+    public Windows98Machine() {
+        monitor = new Monitor();
+        keyboard = new StandardKeyboard();
+    }
+
+}

src/main/java/dip/Windows98MachineDI.java

@@ -0,0 +1,13 @@
+package dip;
+
+public class Windows98MachineDI {
+
+    private final Keyboard keyboard;
+    private final Monitor monitor;
+
+    public Windows98MachineDI(Keyboard keyboard, Monitor monitor) {
+        this.keyboard = keyboard;
+        this.monitor = monitor;
+    }
+
+}

src/main/java/isp/BearCarer.java

@@ -0,0 +1,15 @@
+package isp;
+
+public class BearCarer implements BearCleaner, BearFeeder {
+
+    @Override
+    public void washTheBear() {
+        // I think we missed a spot
+    }
+
+    @Override
+    public void feedTheBear() {
+        //Tuna Tuesday
+    }
+
+}

src/main/java/isp/BearCleaner.java

@@ -0,0 +1,7 @@
+package isp;
+
+public interface BearCleaner {
+
+    void washTheBear();
+
+}

src/main/java/isp/BearFeeder.java

@@ -0,0 +1,7 @@
+package isp;
+
+public interface BearFeeder {
+
+    void feedTheBear();
+
+}

src/main/java/isp/BearKeeper.java

@@ -0,0 +1,9 @@
+package isp;
+
+public interface BearKeeper {
+
+    void washTheBear();
+    void feedTheBear();
+    void petTheBear();
+
+}

src/main/java/isp/BearPetter.java

@@ -0,0 +1,7 @@
+package isp;
+
+public interface BearPetter {
+
+    void petTheBear();
+
+}

src/main/java/isp/CrazyPerson.java

@@ -0,0 +1,10 @@
+package isp;
+
+public class CrazyPerson implements BearPetter {
+
+    @Override
+    public void petTheBear() {
+        //Good luck with that
+    }
+
+}

src/main/java/lsp/Car.java

@@ -0,0 +1,8 @@
+package lsp;
+
+public interface Car {
+
+    void turnOnEngine();
+    void accelerate();
+
+}

src/main/java/lsp/ElectricCar.java

@@ -0,0 +1,14 @@
+package lsp;
+
+public class ElectricCar implements Car {
+
+    @Override
+    public void turnOnEngine() {
+        throw new AssertionError("I don't have an engine!");
+    }
+
+    @Override
+    public void accelerate() {
+        //this acceleration is crazy
+    }
+}

src/main/java/lsp/Engine.java

@@ -0,0 +1,13 @@
+package lsp;
+
+public class Engine {
+
+    public void on() {
+        //vroom
+    }
+
+    public void powerOn(int amount) {
+        //do something
+    }
+
+}

src/main/java/lsp/MotorCar.java

@@ -0,0 +1,16 @@
+package lsp;
+
+public class MotorCar implements Car {
+
+    private Engine engine;
+
+    @Override
+    public void turnOnEngine() {
+        engine.on();
+    }
+
+    @Override
+    public void accelerate() {
+        engine.powerOn(1000);
+    }
+}