User:LuleIzOrbite/sandbox

SOLID je skraćenica koja 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 , prvi put predstavljene u njegovom radu iz 2000. godine pod nazivom "Principi dizajna i dizajnerski obrasci koji se bave propadanjem softvera".

Ideje koje SOLID obuhvata su:

'''Princip jedinstvene odgovornosti == (eng. Single Responsibility Principle): "Nikada ne bi trebalo da postoji više od jednog razloga za promenu klase." Drugim rečima, svaka klasa treba da ima samo jednu odgovornost.

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

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

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

Otvoreno/Zatvoren Princip (eng. Open/Closed Principle): "Softverski entiteti bi trebalo da budu zatvoreni za modifikaciju, ali otvoreni za proširivanje."

U ovom primeru, u slučaju da želimo da dodamo način plaćanja gotovinom, morali bi dodamo kod direktno u klasu  čime rizikujemo promenu već definisanog ponašanja, tj. uvođenje baga/LINKovati.

Izvlačenjem Interfejsa  i klasa koje ga nasleđuju      omogućavamo lakše proširenje funkcionalnosti plaćanja, bez ikakvog uticaja na ostale implementacije.

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

U primeru gde imamo abstraktnu klasu  koju nasleðuju klase   i  i abstraktne funkcije   i. Pošto  nema motor, to dovodi do neočekivanog ponašanja sa programom koji bi koristio funkcije   i   od klase. Jedno od mogućih rešenja je da se od klase  izdvoji druga abstraktna klasa  koja će nasleðivati klasu   i da se tu dodaju funckije   i , dok u   bi se nalazile funkcije   i. Klasu  bi nasleðivao , dok bi klasu   nasleðivao. Princip segregacije interfejsa (eng. Interface Segregation Principle): "Klijenti ne bi trebalo da budu prisiljeni da zavise od interfejsa koje ne koriste." Klijenti su u ovom slučaju klase koje nasleðuju druge klase.

U ovom primeru  je primoran da implementira i funkcije     čak iako klijenta zanima samo trenutno stanje računa.

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

Princip inverzije zavisnosti (eng. Dependency Inversion Principle): "Klijenti treba da zavise od apstrakcija, ne od konkretnih implementacija." 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-linkovati 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 -< link u udaljeni izvor, to bi mu bilo otežano činjenicom da klasa  u sebi sadrzi konkretnu implementaciju.

Da bi se to izbeglo može da se uvede interfejs  koji sadrži funkciju   koje će klase   i   da implementiraju, a klasa   da zavisi od njega.

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

Akronim SOLID je kasnije uveden oko 2004. godine od strane Majkla Feathersa.

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.

Vidi takođe

Code reuse

GRASP (dizajn orijentisan objektima)

Nasleđivanje (objektno-orijentisano programiranje)

Spisak filozofija razvoja softvera