I know what you are thinking and no not the state of matter but in a software engineer capacity. This is an acronym that stands for the 5 principles of software development.

Single-Responsibility Principle

The first principle is called the Single-Responsibility principle, which says that a class should only have one job. So if you have a class that does some sort of calculation and then you have several other methods that print out the calculation in multiple formats then you may want to extract those out into there own class. That is because that class has become something that now does two jobs instead of just one.

Open-Closed Principle

The second is the Open-Closed principle, which says that objects should not be able to be modified but should be able to get extended if needed. Another way to put this is that it should be easy to modify the behavior of a class without actually having to modify the class itself. An easy way to achieve this is to create an interface for a class and then pass that class into another object.

Liskov Substitution Principle

The third is the Liskov substitution principle and it has a very formal saying to explain what it means. The short version however is that every subclass or derived class should work as a substitute for their parent or base class. This means that any derived class shouldn’t modify the behavior of the parent class. Essentially you need to have a very generic abstract class that you inherit from. Take an example like having a circle class and a rectangle class. Both of these classes need to inherit from a generic abstract class called shapes. This will allow you to implement things specifically for each class without interfering with the other classes. It also allows you to create new shape classes easily.

Interface Segregation Principle

The forth is the Interface Segregation principle, which states that a client should not have to implement an interface or depend on a method that it does not use. So if an interface is needed to be implemented by a class and it forces that class to actually implement a method that it will not be able to actually use, for whatever reason. Then it may mean that a new interface needs to be implemented that does not have the method.

Dependency Inversion Principle

The fifth is the Dependency Inversion principle, which states that a high level module should not depend on a low level module. Instead the modules should depend on abstractions. This means that when thinking of the interactions between the high level module and low level module it should be thought of as an abstraction. This allows for decoupling between the two modules.

---

These five principles are easy to grasp in concept and can be very helpful when coding. The hardest part is to remember to use these principles as you code and sometimes things will slip by but that is what refactoring the code is for.