SOLID રક્ષણક્ષમ, લવચક OOP પ્રણાલીઓ બનાવવા માટે પાંચ ડિઝાઇન સિદ્ધાંતો છે. દરેક એક કઠોર, નાજુક કોડના સામાન્ય કારણને સંબોધિત કરે છે.
SOLID રક્ષણક્ષમ, લવચક OOP પ્રણાલીઓ બનાવવા માટે પાંચ ડિઝાઇન સિદ્ધાંતો છે. દરેક એક કઠોર, નાજુક કોડના સામાન્ય કારણને સંબોધિત કરે છે.
| અક્ષર | સિદ્ધાંત | એક-લીટી અર્થ |
|---|
| S | સિંગલ જવાબદારી | એક વર્ગે બદલાવનું એક જ કારણ હોવું જોઇએ |
| O | ખુલ્લું/બંધ | વિસ્તર માટે ખુલ્લું, સુધારણા માટે બંધ |
| L | લિસ્કોવ સબસ્ટિટ્યુશન | સબટાઇપ્સ આધાર પ્રકાર ક્યાં છે ત્યાં ઉપયોગી હોવી જોઇએ |
| I | ઈન્ટરફેસ સેગ્રીગેશન | ઘણાં નાના ઈન્ટરફેસ એક મોટા કરતાં વધુ સારા છે |
| D | ડિપેન્ડન્સી ઈન્વર્સન | અમૂર્ત પર આધાર રાખો, કોંક્રીટ વર્ગો પર નહીં |
# Dependency Inversion: high-level code depends on an abstraction
class Notifier: # abstraction
def send(self, msg): ...
class EmailNotifier(Notifier):
def send(self, msg): print("email:", msg)
class OrderService:
def __init__(self, notifier: Notifier): # injected abstraction
self.notifier = notifier # not "new EmailNotifier()"
def place(self):
self.notifier.send("order placed") # works with ANY Notifier
OrderService ઈમેલ પર ચોક્કસપણે આધાર રાખતું નથી — તેને સ્પર્શ કર્યા વિના SMS અથવા પરીક્ષણ ડબલ સાથે બદલી કરો (D). એક નવો નોટિફાયર પ્રકાર ઉમેરવાથી OrderService માટે કોઈ પણ પરિવર્તનની જરૂર નથી (O).
SOLID માર્ગદર્શન છે, કાયદો નથી. તેને વધુ-લાગુ કરવું — દરેક વર્ગ માટે એક ઈન્ટરફેસ, હर જગ્યા અનુપ્રેરણા — "અમૂર્ત સૂપ" બનાવે છે જે તેણે હલ કર્યેલી સમસ્યા કરતાં અનુસરવું વધુ મુશ્કેલ છે.
SOLID એક શેર કરાયેલ નિદાન ભાષા આપે છે: સમીક્ષકો નામ આપી શકે છે શા માટે એક વર્ગ બદલવું મુશ્કેલ છે ("આ SRP નું ઉલ્લંઘન કરે છે") સ્વાદ દ્વારા દલીલ કર્યા વિના.
ન્યાયથી લાગુ કરવામાં આવે ત્યારે, સિદ્ધાંતો લહેર અસરો ઘટાડે છે — બદલાવો સ્થાનિક રહે છે, નવી વિશેષતાઓ આફર કરે છે તેના બદલે લેખો, અને પરીક્ષાઓ વાસ્તવિક નિર્ભરતાઓ માટે નકલી બદલી શકે છે.