In articolul Tehnici de programare am prezentat caracteristicile programarii pe obiect. Studiul indelungat asupra acestei tehnici a dus la un set de reguli, de principii de proiectare bine definite. Acestea vor ajuta programatorul sa scrie cod reutilizabil, flexibil, robust.

In OOP sunt recunoscute mai multe principii, insa cele de baza sunt cunoscute ca SOLID, acronimul reprezentand:
Single Responsability Principle (SRP)
Open/Close Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependecy Inversion Principle (DIP)

SOLID a fost introdus de Robert_Cecil_Martin.

Single responsability principle

“A class should have one, and only one, reason to change.”

Pe masura ce scriem cod, clasele, interfetele, metodele tind sa creasca pentru a realiza cat mai multe lucruri, cat mai multe sarcini. Insa, cand o clasa are mai multe responsabilitati, ea devine mai greu de inteles si implicit mai greu de modificat, extins.
Conform SRP, o clasa trebuie sa aiba o singura responsabilitate, o singura sarcina. Aceasta singura responsabilitate va fi incapsulata in intregime in clasa respectiva. Dar asta nu inseamna ca trebuie sa aiba o singura metoda sau o singura proprietate, ci pot exista mai multi membri care sa fie inruditi de aceasta singura responsabilitate. Astfel, clasele scrie urmand acest principiu vor deveni mai mici, mai curate. Intr-adevar, numarul claselor din program va creste, dar pot fi organizate intr-un spatiu de nume, apoi in directoare si in proiecte. Scopul acestui principiu nu este de a crea clase cat mai mici. Este de a crea clase care contin membri legati intre ei de singura resposabilitate a clasei in mod coerent. Folosind SRP, programatorul va sti sigur ca exista un singur motiv pentru care va fi modificat codul clasei.

Un mod prin se poate aplica acest principiu al unicei responsabilitati este ca la denumirea metodei/proprietatii: daca numele se potriveste cu numele clasei, atunci cu siguranta se incadreaza in clasa respectiva. Daca numele nu corespunde, ele vor trebui mutate intr-o alta clasa.

Exemplu:

    public class Robot
    {
        public string Name { get; set; }

        public Robot(string name)
        {
            Name = name;
        }

        /// <summary>
        /// Verifica daca sunt indeplinite conditii pentru a putea porni robotul
        /// </summary>
        public bool CheckEnvironment()
        {
            return true;
        }
        
        public void TurnLeft()
        { 
            //
        }

        public void TurnRight()
        { 
          //        
        }
    }

Clasa Robot are doua metode care vor asigura deplasarea robotului si o metoda care sa verifice daca sunt indeplinite conditii pentru pornirea sa. Conform SRP, metoda CheckEnvironment poate fi mutata intr-o alta clasa, lasand clasa Robot responsabila doar cu o singura sarcina.

Dupa refactorizare, putem avea urmatorul cod:

    public class Robot
    {
        public string Name { get; set; }

        public Robot(string name)
        {
            Name = name;
        }
        
        public void TurnLeft()
        { 
            //
        }

        public void TurnRight()
        { 
          //        
        }
    }
    
    public class EnvironmentChecker
    {
        /// <summary>
        /// Verifica daca sunt indeplinite conditii pentru a putea porni robotul
        /// </summary>
        public bool Check()
        {
            return true;
        }
    }

Astfel, clasa EnvironmentChecker va fi responsabila doar cu verificarea conditiilor pentru pornirea robotului, iar clasa Robot va fi responsabila doar cu deplasarea acestuia.

SRP este intr-o legatura stransa cu OCP, conform caruia o clasa nu trebuie sa fie modificata, ci extinsa. Astfel, putem aplica cu succes al doilea principiu daca avem siguranta ca responsabilitatea clasei este doar una.