Diventare uno sviluppatore SOLID

Dec 24 2022

Seguendo i principi di ingegneria del software SOLID

Essere definito solido è un complimento. La parola porta le nozioni positive di affidabilità e rispettabilità.

Essere definito solido è un complimento. La parola porta le nozioni positive di affidabilità e rispettabilità. Tutti noi dovremmo mirare a diventare uno.

https://www.collinsdictionary.com/dictionary/english/solid (schermata)

Se sei un ingegnere del software o vuoi diventarlo, sei fortunato perché c'è una serie di principi SOLIDI che ti guidano.

SOLID è un acronimo nella professione di ingegnere del software. Sta per:

Principio di responsabilità unica
Principio aperto-chiuso
Principio di sostituzione di Liskov
Principio di segregazione delle interfacce
Principio di inversione delle dipendenze

Diamo un'occhiata a questi principi in modo più dettagliato.

Responsabilità unica

Ogni classe dovrebbe avere una singola responsabilità.

An EmailServicedovrebbe preoccuparsi solo di inviare e-mail, non di inviare e-mail e aggiornare lo stato dell'ordine.

Una Carclasse dovrebbe riguardare solo le automobili, non altri tipi di veicoli a motore. Se dobbiamo descrivere un'auto elettrica, allora una sottoclasse come questa ElectricCarè più appropriata che sovraccaricare Carcon le caratteristiche di un'auto elettrica ea benzina.

Principio apri-chiudi

Un modulo dovrebbe essere aperto per l'estensione ma chiuso per la modifica

Il EmailServicepuò essere esteso da un RecallableEmailServiceche aggiunge funzionalità di capacità di richiamo all'e-mail appena inviata.

EmailService e le sue associazioni

ElectricCarAggiunge caratteristiche elettriche senza modificare l'interno di Car.

Sostituzione di Liskov

Le sottoclassi dovrebbero essere sostituibili per le loro classi di base

Nel contesto della progettazione orientata agli oggetti, una classe o un metodo che accetta un'istanza di una classe base dovrebbe essere in grado di accettare qualsiasi istanza della sua sottoclasse.

An OrderServicedovrebbe essere in grado di utilizzare qualsiasi istanza conforme all'interfaccia di EmailServicesenza preoccuparsi che la classe effettiva dell'istanza sia EmailServiceessa stessa oRecallableEmailService

An UrbanTripPlannerdovrebbe essere in grado di utilizzare qualsiasi istanza di Carper determinare un percorso senza sapere se rappresenta un'auto elettrica oa benzina.

Segregazione dell'interfaccia

Molte interfacce specifiche del client sono migliori di un'interfaccia generica

An OrderServicenon ha bisogno di recallEmail(...). Quindi dipende solo EmailServiceper l'invio di e-mail, noRecallableEmailService

Allo stesso modo, an UrbanTripPlannernon ha bisogno del recharge(...)metodo di an EletricCar. Dipende solo dall'interfaccia fornita daCar

Auto e le sue associazioni

Inversione di dipendenza

Dipende dalle astrazioni. Non dipendere dalle concrezioni.

Il meccanismo di dipendenza procedurale parte dall'alto, si espande gradualmente e dipende da dettagli implementativi concreti.

Nella programmazione orientata agli oggetti, la dipendenza è invertita . La maggior parte delle dipendenze dovrebbe essere su astrazioni. E dove esiste l'implementazione, il suo rapporto con l'astrazione si inverte . Piuttosto che dipendere direttamente, l'implementazione ora dipende dall'astrazione.

Fonte: Principi di progettazione e modelli di progettazione di Uncle Bob

An OrderServicedipende dall'interfaccia fornita da EmailServicee non dalla sua implementazione IMAP o POP.

An UrbanTripPlannerdipende dall'interfaccia fornita da Car, non dalla sua implementazione Tesla o Toyota

Conclusione

Abbiamo esaminato l'origine dell'acronimo SOLID, nonché esaminato ciascuno di essi in dettaglio con 2 casi d'uso di progettazione orientata agli oggetti ciascuno.

Potresti aver seguito alcuni di questi principi in passato senza saperlo perché sono buone pratiche. L'incapsulamento, secondo me, segue il principio Open-close .

Potresti anche averne applicati alcuni perché è così che stanno le cose. Sintatticamente, un ElectricCaroggetto può sempre passare per un Carparametro, seguendo così il principio di sostituzione di Liskov . Se hai utilizzato Dependency Injection, segui già il principio Dependency Inversion .

Altri principi richiedono un po' di riflessione. Il principio di responsabilità singola richiede un buon modello OO per mantenere il metodo/classe/modulo pulito e snello. Potrebbe essere necessario il buon senso per determinare quanto deve essere profonda la segregazione mentre si segue il principio di segregazione dell'interfaccia .