Principles of object-oriented programming and design
SOLID
The principles when applied together intends to make it more likely that a programmer will create a system that is easy to maintain and extend over time.
Defination on wikipedia
SOLID is a mnemonic acronym introduced by Michael Feathers for the "first five principles" named by Robert C. Martin in the early 2000s that stands for five basic principles of object-oriented programming and design.
The principles, when applied together, intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time.
The principles of SOLID are guidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible. It is part of an overall strategy of agile and Adaptive Software Development.
Overview
| S = SRP |
Single responsibility Principle |
|
| " A class should have only a single responsibility." |
The single responsibility principle states that 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.
All its services should be narrowly aligned with that responsibility
As per SRP, there should not be more than one reason for a class to change,
or a class should always handle single functionality. If you put more than one functionality in one Class in C# it introduce coupling between two functionality and even if you change one functionality there is chance you broke coupled functionality,
which require another round of testing to avoid any surprise on production environment. |
| O = OCP |
Open Closed Principle |
|
| "software entities … should be open for extension, but closed for modification." |
In object-oriented programming, the open/closed principle states “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”; that is, such an entity can allow its behaviour to be extended without modifying its source code.
Open Closed principle helps you write code that is extensible and cleaner. |
| L = LSP |
Liskov substitution Principle |
|
| "objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program." |
The Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address entitled Data abstraction and hierarchy
if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program
In order to follow this principle we need to make sure that the subtypes respect the parent class. |
| I = ISP |
Interface segregation Principle |
|
| "many client-specific interfaces are better than one general-purpose interface." |
The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.
ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.
ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.
ISP is one of the five SOLID principles of Object-Oriented Design, similar to the High Cohesion Principle of GRASP |
| D = DIP |
Dependency inversion principle |
|
| "One should “Depend upon Abstractions. Do not depend upon concretions." |
The Dependency Inversion principle refers to a specific form of decoupling software modules.It states:
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.
The Dependency Inversion principle (DIP) helps us to develop loosely couple code by ensuring that high-level modules depend on abstractions rather than concrete implementations of lower-level modules. |
Principle
KISS
KISS is an acronym for the design principle "Keep it simple, Stupid!".
Defination on wikipedia
KISS is an acronym for "Keep it simple, stupid" as a design principle noted by the U.S. Navy in 1960. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.
YAGNI
You aren't gonna need it
Defination on wikipedia
"You aren't gonna need it" (acronym: YAGNI) is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary. XP co-founder Ron Jeffries has written: "Always implement things when you actually need them, never when you just foresee that you need them." Other forms of the phrase include "You aren't going to need it" and "You ain't gonna need it".
Principle of software development
DRY or DIE
In software engineering, Don't Repeat Yourself (DRY) or Duplication is Evil (DIE) is a principle of software development
Defination on wikipedia
don’t repeat yourself (DRY) is a principle of software development, aimed at reducing repetition of information of all kinds, especially useful in multi-tier architectures. The DRY principle is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
List of software development philosophies
