SOLID Principles

The Interface Segregation Principle states the following: Clients of a class should not be forced to depend on those of its methods they don't use. Suppose you are building an animal simulator and you design an interface as shown below. In the beginning, you think that the application will accept only animals. So you design the IBehaviour interface to have three methods. eat(), sleep(), move(). Now let's assume that the application would not simulate animals, it would also simulate plants. The solution sounds quite simple, you just create the Plant class and implement the IBehaviour interface. But there is a problem a plant can't move and also can't sleep, so the methods sleep() and move() would end up having nothing inside as shown below. @Override     public void move() {         throw new UnsupportedOperationException("Not supported");      }     @Override     public void sleep() {         throw new ...

 Liskov Substitution Principle can be stated as: A type must be substitutable by its subtypes without altering the correctness of the application. To make it easier let's start with an example. See the image below: As you can see there is an interface IAnimal that defines two methods, speak() and sleep(). The IAnimal interface is implemented by two classes Parrot and Elephant. So far, so good but let's say that we should include ants in the application. To incorporate this change create an additional class called Ant that implements IAnimal. Since ants do not speak once you implement the interface the code would look something like this: @Override     public void speak() {         throw new UnsupportedOperationException("Not supported yet.");      } Now we can see a problem that might cause errors in the application. To correct this you can split the IAnimal interface into two. IAnimalSpeak and IAnimalSleep. The modified design is shown ...

 The Dependency Inversion Principle can be stated as follows: High-level classes should not depend on low-level classes. Both of them should depend on abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. The first part consists of dependency between high-level and low-level classes. A high-level class is a class that does something significant for the application, while a low-level class does some auxiliary work. The secondary part tells us that abstraction should not depend on details, the details should depend on abstractions. Let's suppose you build an authentication system that needs to manage users. Where a way to change password is required. When a password is change a notification is sent to the user. In this case the class in charge on doing the user management is a high level class and the class sending the notification is a low-level class. Consider the classes shown below: The  high-level class, UserManager contains the...