SOLID

SOLID

The SOLID principles of Object Oriented Design include these five principles: SRP – Single Responsibility Principle OCP – Open/Closed Principle LSP – Liskov Substitution Principle ISP – Interface Segregation Principle DIP – Dependency Inversion Principle Generally, software should be written … Continued
Don’t Repeat Yourself

Don’t Repeat Yourself

The Don’t Repeat Yourself (DRY) principle states that duplication in logic should be eliminated via abstraction; duplication in process should be eliminated via automation. Duplication is Waste Adding additional, unnecessary code to a codebase increases the amount of work required … Continued
Dependency Inversion Principle

Dependency Inversion Principle

The Dependency Inversion Principle (DIP) states that high level modules should not depend on low level modules; both should depend on abstractions. Abstractions should not depend on details.  Details should depend upon abstractions. It’s extremely common when writing software to implement … Continued
Interface Segregation Principle

Interface Segregation Principle

The Interface Segregation Principle (ISP) states that clients should not be forced to depend on methods that they do not use.  Interfaces should belong to clients, not to libraries or hierarchies. Application developers should favor thin, focused interfaces to “fat” … Continued
Liskov Substitution Principle

Liskov Substitution Principle

The Liskov Substitution Principle (LSP) states that subtypes must be substitutable for their base types. When this principle is violated, it tends to result in a lot of extra conditional logic scattered throughout the application, checking to see the specific type … Continued
Open-Closed Principle

Open-Closed Principle

The Open-Closed Principle (OCP) states that software entities (classes, modules, methods, etc.) should be open for extension, but closed for modification. In practice, this means creating software entities whose behavior can be changed without the need to edit and recompile … Continued
Single Responsibility Principle

Single Responsibility Principle

The Single Responsibility Principle (SRP) states that a class should have only one reason to change.  It was first cited in this form by Robert C. Martin in an article that later formed a chapter in his Principles, Patterns, and … Continued
Persistence Ignorance

Persistence Ignorance

The principle of Persistence Ignorance (PI) holds that classes modeling the business domain in a software application should not be impacted by how they might be persisted. Thus, their design should reflect as closely as possible the ideal design needed … Continued
Stable Dependencies

Stable Dependencies

The Stable Dependencies Principle states that “The dependencies between software packages should be in the direction of the stability of the packages. That is, a given package should depend only on more stable packages.” Whenever a package changes, all packages … Continued
Tell Don’t Ask

Tell Don’t Ask

The Tell, Don’t Ask (TDA) principle suggests that it is better to issue an object a command do perform some operation or logic, rather than to query its state and then take some action as a result. It is related … Continued