Корисник:LuleIzOrbite/песак

° SOLID je akronim koju označava pet osnovnih principa dizajna softvera, osmišljenih kako bi objektno-orijentisani dizajn bio razumljiviji, fleksibilniji i lakši za održavanje. Ovi principi su podskup mnogih principa promovisanih od strane američkog softverskog inženjera i instruktora Roberta S. Martina, poznatijeg kao "Ujka Bob" (engl. "Uncle Bob") ^[1]^[2]^[3], prvi put predstavljene u njegovom radu iz 2000. godine pod nazivom Principi dizajna i dizajnerski obrasci koji se bave softverskom buđi.

Akronim SOLID je kasnije uveden oko 2004. godine od strane Majkla Federsa^[4].

Iako se SOLID principi odnose na bilo koji objektno-orijentisani dizajn, takođe mogu da predstavljaju osnovnu filozofiju za metodologije poput agilnog razvoja ili adaptivnog softverskog razvoja.

Ideje koje SOLID obuhvata su:

Princip jedinstvene odgovornosti

(engl. Single Responsibility Principle): "Nikada ne bi trebalo da postoji više od jednog razloga za promenu klase."^[5] Drugim rečima, svaka klasa treba da ima samo jednu odgovornost.

U ovom primeru, napisanom u javi programerskom jeziku, klasa Kalkulator u krši principe jedinstvene odgovornosti jer osim toga što se bavi logikom sabiranja dva broja, takođe se brine o unosu i ispisu podataka.

public class Kalkulator {

    public void saberi() {

        Scanner scanner = new Scanner(System.in);
        System.out.println("Unesite broj a");
        int a = scanner.nextInt();
        System.out.println("Unesite broj b");
        int b = scanner.nextInt();

        System.out.println("Vrednost sabiranja broja " + a + " i broja b " + b + " je " + (a + b));

    }
}

Da bi se klasa više pridržavala principu, može se refaktorisati u nešto nalik ovome

public class Kalkulator {

    public int saberi(int a, int b) {
       return a+b;
    }
}

Sada klasa Kalkulator je odgovorna samo za datu logiku sabiranja dva broja, dok bi se za: unos, ispis itd... brinula neka druga klasa.

Otvoreno/Zatvoren Princip

(engl. Open/Closed Principle): "Softverski entiteti bi trebalo da budu zatvoreni za modifikaciju, ali otvoreni za proširivanje."^[6]

U ovom primeru, u slučaju da postoji potreba za dodavanjem novog načina plaćanja gotovinom, kod bi morao da se doda direktno u klasu ProcesorPlacanja čime se rizikuje promena već definisanog ponašanja, tj. uvođenje baga.

public class ProcesorPlacanja {

    public void obradiPlacanje(String tipPlacanja, double iznos) {
        switch (tipPlacanja) {
            case "KreditnaKartica":
                obradiPlacanjeKreditnomKarticom(iznos);
                break;
            case "PayPal":
                obradiPlacanjePayPalom(iznos);
                break;
            case "Bitcoin":
                obradiPlacanjeBitcoinom(iznos);
                break;
        }
    }

    private void obradiPlacanjeKreditnomKarticom(double iznos) {
        // Logika za plaćanje kreditnom karticom
    }

    private void obradiPlacanjePayPalom(double iznos) {
        // Logika za plaćanje PejPalom
    }

    private void obradiPlacanjeBitcoinom(double iznos) {
        // Logika za plaćanje Bitkoinom
    }
}

Izvlačenjem interfejsa ProcesorPlacanja i klasa koje ga nasleđuju PlacanjeKreditnomKarticomPlacanjePayPalom PlacanjeBitcoinom omogućava se lakše proširenje funkcionalnosti plaćanja, bez ikakvog uticaja na ostale implementacije.

public interface ProcesorPlacanja {
    void obradiPlacanje(double iznos);
}

class PlacanjeKreditnomKarticom implements ProcesorPlacanja {
    @Override
    public void obradiPlacanje(double iznos) {
        // Logika za plaćanje kreditnom karticom
    }
}
class PlacanjePayPalom implements ProcesorPlacanja {
    @Override
    public void obradiPlacanje(double iznos) {
        // Logika za plaćanje PejPalom
    }
}

class PlacanjeBitcoinom implements ProcesorPlacanja {
    @Override
    public void obradiPlacanje(double iznos) {
        // Logika za plaćanje Bitkoin
    }
}

Liskov princip zamene

(engl. Liskov Substitution Principle): "Ako je klasa B potklasa klase A, prosleđivanje klase B programu koji očekuje klasu A ne sme izazvati neočekivano ili nedefinisano ponašanje"^[7]. Dakle u programu koji rukovodi klasama tipa B koje nasleđuju klasu A, ne sme se zadesiti da se nadja klasa koja nasleđuje klasu A, a ne ispunjava sve njene funckionalnosti.

U narednom primeru postoji abstraktnu klasa Vozilo koju nasleđuju klase Auto i Bicikl i abstraktne funkcije zaustaviMotor() i pokreniMotor(). Pošto Bicikl nema motor, to dovodi do neočekivanog ponašanja sa programom koji bi koristio funkcije zaustaviMotor() i pokreniMotor() od klase Vozilo.

abstract class Vozilo {
    abstract public void idiNapred();
    abstract public void pokreniMotor();
    abstract public void zaustaviMotor();
    abstract public int brojTockova();
}

class Auto extends Vozilo {

    @Override
    public void idiNapred() {
        //Logika za vožnju
    }

    @Override
    public void pokreniMotor() {
        // Logika za pokretanje motora auta
    }

    @Override
    public void zaustaviMotor() {
        // Logika za zaustavljanje motora auta
    }

    @Override
    public int brojTockova() {
        return 4;
    }
}

class Bicikl extends Vozilo {

    @Override
    public void idiNapred() {
        //Logika za vožnju
    }
    
    @Override
    public void pokreniMotor() {
        throw new RuntimeException("Bicikl nema motor");
    }

    @Override
    public void zaustaviMotor() {
        throw new RuntimeException("Bicikl nema motor");
    }

    @Override
    public int brojTockova() {
        return 2;
    }
}

Jedno od mogućih rešenja je da se od klase Vozilo izdvoji druga abstraktna klasaVoziloSaMotorom koja će nasleđivati klasu Vozilo i da se tu dodaju funckije pokreniMotor() i zaustaviMotor(), dok bi se u Vozilo nalazile funkcije idiNapred() i brojTockova(). Klasu Vozilo bi nasleđivao Bicikl, dok bi klasu VoziloSaMotorom nasleđivao Auto.

abstract class Vozilo {
    abstract public void idiNapred();
    abstract public int brojTockova();
}

abstract class VoziloSaMotorom extends Vozilo{
    abstract public void pokreniMotor();
    abstract public void zaustaviMotor();
}
class Auto extends VoziloSaMotorom {

    @Override
    public void idiNapred() {
        //Logika za vožnju
    }

    @Override
    public void pokreniMotor() {
        // Logika za pokretanje motora auta
    }

    @Override
    public void zaustaviMotor() {
        // Logika za zaustavljanje motora auta
    }

    @Override
    public int brojTockova() {
        return 4;
    }
}

class Bicikl extends Vozilo {

    @Override
    public void idiNapred() {
        //Logika za vožnju
    }

    @Override
    public int brojTockova() {
        return 2;
    }
}

Princip segregacije interfejsa

(eng.l Interface Segregation Principle): "Klijenti ne bi trebalo da budu prisiljeni da zavise od interfejsa koje ne koriste."^[8]

U ovom primeru KorisnickiServis je primoran da implementira i funkcije izvrsiUplatu()izvrsiIsplatu()promeniPin(int noviPIN) čak iako klijenta zanima samo trenutno stanje računa.

interface BankomatServis {

    void izvrsiUplatu(double iznos);

    void izvrsiIsplatu(double iznos);

    void prikaziStanjeRacuna();

    void promeniPIN(int noviPIN);
}

class KorisnickiServis implements BankomatServis {

    @Override
    public void izvrsiUplatu(double iznos) {
        
    }

    @Override
    public void izvrsiIsplatu(double iznos) {
        
    }

    @Override
    public void prikaziStanjeRacuna() {
        // Logika za prikazivanje računa 
    }

    @Override
    public void promeniPIN(int noviPIN) {
        
    }
}

class UpravljackiServus implements BankomatServis {

    @Override
    public void izvrsiUplatu(double iznos) {
        // Logika za uplatu
    }

    @Override
    public void izvrsiIsplatu(double iznos) {
        // Logika za isplatu
    }

    @Override
    public void prikaziStanjeRacuna() {
        // Logika za prikaz stanja računa
    }

    @Override
    public void promeniPIN(int noviPIN) {
        // Logika za PIN
    }
}

Da bi ovaj primer bio prilagoðen principu segregacije interfejsa, može se izdvojiti još jedan interfejs od BankomatServis, tako da klijenti koriste samo ono što im je potrebno.

interface UpravljackiBankomatServis {

    void izvrsiUplatu(double iznos);

    void izvrsiIsplatu(double iznos);
    
    void promeniPIN(int noviPIN);
}

interface InformacionaiBankomatServis {
    void prikaziStanjeRacuna();
    
}

class KorisnickiServis implements InformacionaiBankomatServis {

    @Override
    public void prikaziStanjeRacuna() {
        // Logika za prikazivanje računa
    }

}

class UpravljackiServis implements UpravljackiBankomatServis, InformacionaiBankomatServis {

    @Override
    public void izvrsiUplatu(double iznos) {
        // Logika za uplatu
    }

    @Override
    public void izvrsiIsplatu(double iznos) {
        // Logika za isplatu
    }

    @Override
    public void promeniPIN(int noviPIN) {
        // Logika za PIN
    }

    @Override
    public void prikaziStanjeRacuna() {
        // Logika za prikazivanje stanja računa
    }
}

Princip inverzije zavisnosti

(engl. Dependency Inversion Principle): "Klijenti treba da zavise od apstrakcija, ne od konkretnih implementacija." ^[9] Ako klasa A u sebi sadrži klasu B, klasa A zavisi od klase B.

Ovaj princip govori o tome da klasa B ne bi trebalo da bude konkretno neka implementacija, već neka vrste apstrakcije. Što omogućava veću modularnost programa i lakšu zamenu implementacija u slučaju da dođe do potrebe za tim. Ovaj princip je poznat po tome što se često koristi u potrebi testiranja softvera, jer omogućava lakšu zamenu pravih implementacija sa lažnim, za potrebe testiranja.

U ovom primeru ako bi programer želeo da zameni izvor korisnika, iz baze podataka u udaljeni izvor, to bi mu bilo otežano činjenicom da klasa KorisnikServis u sebi sadrzi konkretnu implementaciju KorisnikBazaPodataka.

class Korisnik {

    private String ime;
    private String prezime;
    long id;

    public Korisnik(String ime, String prezime, int id) {

        this.ime = ime;
        this.prezime = prezime;
        this.id = id;
    }

    @Override
    public String toString() {

        return "Korisnik{" +
                "ime='" + ime + '\'' +
                ", prezime='" + prezime + '\'' +
                ", id=" + id +
                '}';
    }
}

class KorisnikServis {

    KorisnikBazaPodataka korisnikBazaPodataka = new KorisnikBazaPodataka();

    public void iscitajKorisnika() {
   System.out.println(korisnikBazaPodataka.dobijKorisnika(1234).toString());
    }

}

class KorisnikBazaPodataka {

    public Korisnik dobijKorisnika(int id) {
        // Logika za čitanje korisnika iz baze
    }
}

class KorisnikUdaljeniIzvoraPodataka {

    public Korisnik dobijKorisnika(int id) {
        // Logika za dobijanje korisnika sa nekog udaljenog izvora podataka
    }
}

Da bi se to izbeglo može da se uvede interfejs KorisnikIzvorPodataka koji sadrži funkciju dobijKorisnika(int id) koje će klase KorisnikUdaljeniIzvoraPodataka i KorisnikBazaPodataka da implementiraju, a klasa KorisnikServis da zavisi od njega.

class Korisnik {

    private String ime;
    private String prezime;
    long id;

    public Korisnik(String ime, String prezime, int id) {

        this.ime = ime;
        this.prezime = prezime;
        this.id = id;
    }

    @Override
    public String toString() {

        return "Korisnik{" +
                "ime='" + ime + '\'' +
                ", prezime='" + prezime + '\'' +
                ", id=" + id +
                '}';
    }
}

class KorisnikServis {

    KorisnikIzvorPodataka korisnikBazaPodataka;

    public KorisnikServis(KorisnikIzvorPodataka korisnikIzvorPodataka) {
        this.korisnikBazaPodataka = korisnikIzvorPodataka;
    }
    public void iscitajKorisnika() {

        System.out.println(korisnikBazaPodataka.dobijKorisnika(1234).toString());
    }

}

interface KorisnikIzvorPodataka {
    public Korisnik dobijKorisnika(int id);
}
class KorisnikBazaPodataka implements KorisnikIzvorPodataka {

    public Korisnik dobijKorisnika(int id) {
        // Logika za čitanje korisnika iz baze
    }
}

class KorisnikUdaljeniIzvoraPodataka implements KorisnikIzvorPodataka {

    public Korisnik dobijKorisnika(int id) {
        // Logika za dobijanje korisnika sa nekog udaljenog izvora podataka
    }
}

Ovim postupkom se može jednostavno zameniti izvor podataka u klasi KorisnikServis, i dodati drugi ako ima potrebe za tim.

Vidi takođe

Ponovna upotreba koda

GRASP (dizajn orijentisan objektima)

Nasleđivanje (objektno-orijentisano programiranje)

Spisak filozofija razvoja softvera

Reference

^ Martin, Robert C. „Principles Of OOD”. ButUncleBob.com. Архивирано из оригинала 10. 9. 2014. г. Приступљено 2014-07-17. . (Referenca se odnosi na "the first five principles", akronim SOLID nije korišćen u ovom izvoru.) Datira jos
^ Martin, Robert C. (13. 2. 2009). „Getting a SOLID start”. Uncle Bob Consulting LLC (Google Sites). Архивирано из оригинала 17. 9. 2013. г. Приступљено 2013-08-19.
^ Metz, Sandi (мај 2009). „SOLID Object-Oriented Design”. YouTube. Архивирано из оригинала 2021-12-21. г. Приступљено 2019-08-13. Govor održan 2009. godine na Gotam Ruby Konferenciji.
^ Martin, Robert (2018). Clean Architecture: A Craftsman's Guide to Software Structure and Design. стр. 58. ISBN 9780134494166.
^ „Single Responsibility Principle” (PDF). objectmentor.com. Архивирано из оригинала 2. 2. 2015. г.
^ https://www.cs.utexas.edu/users/downing/papers/OCP-1996.pdf
^ https://www.cs.utexas.edu/users/downing/papers/LSP-1996.pdf
^ https://condor.depaul.edu/dmumaugh/OOT/Design-Principles/isp.pdf
^ https://www.engr.mun.ca/~theo/Courses/sd/5895-downloads/sd-principles-4.ppt.pdf

[ub-old-web-solid-1] Martin, Robert C. „Principles Of OOD”. ButUncleBob.com. Архивирано из оригинала 10. 9. 2014. г. Приступљено 2014-07-17. . (Referenca se odnosi na "the first five principles", akronim SOLID nije korišćen u ovom izvoru.) Datira jos

[ub-solid-2] Martin, Robert C. (13. 2. 2009). „Getting a SOLID start”. Uncle Bob Consulting LLC (Google Sites). Архивирано из оригинала 17. 9. 2013. г. Приступљено 2013-08-19.

[metz-presentation-2009-3] Metz, Sandi (мај 2009). „SOLID Object-Oriented Design”. YouTube. Архивирано из оригинала 2021-12-21. г. Приступљено 2019-08-13. Govor održan 2009. godine na Gotam Ruby Konferenciji.

[4] Martin, Robert (2018). Clean Architecture: A Craftsman's Guide to Software Structure and Design. стр. 58. ISBN 9780134494166.

[5] „Single Responsibility Principle” (PDF). objectmentor.com. Архивирано из оригинала 2. 2. 2015. г.

[6] ttps://www.cs.utexas.edu/users/downing/papers/OCP-1996.pdf

[7] ttps://www.cs.utexas.edu/users/downing/papers/LSP-1996.pdf

[8] ttps://condor.depaul.edu/dmumaugh/OOT/Design-Principles/isp.pdf

[9] ttps://www.engr.mun.ca/~theo/Courses/sd/5895-downloads/sd-principles-4.ppt.pdf

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]