SOLID

Dependency Inversion Principle is fifth and last principle from SOLID acronym. The definition states two things. First: high-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces). Second: abstractions should not depend on details. Details (concrete implementations) should depend on abstractions. In real-life this principle can be compare to devices […]

Interface Segregation Principle is fourth principle from SOLID acronym and the definition is: Clients should not be forced to depend upon interfaces that they do not use. It means that we should be very careful while creating interfaces and make sure that classes that would be implementing these interfaces will not be forced to override methods

Liskov Substitution Principle is third principle from SOLID acronym. It is named after Barbara Liskov, another name of this principle is Behavioral Subtyping and the definition is: The principle that subclasses should satisfy the expectations of clients accessing subclass objects through references of superclass type, not just as regards syntactic safety (such as absence of

Open Close Principle is second principle from SOLID acronym. Definition: Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. That means if program needs to be changed it should be done without modification of existing code. When it is needed to change behavior of our program, it should be

Single Responsibility Principle is first principle from SOLID acronym. A class should not have many tasks to do but it should have only one.Definition: Every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class, module or function.That