Posso applicare i concetti SOLID a intere progettazioni di soluzioni piuttosto che solo ai componenti interni?

3

Quindi forse la risposta rapida è "Sì" assolutamente (o no, suppongo), ma lascia che ti spieghi la mia angolazione di domanda per ottenere una risposta migliore.

Tutti noi usiamo comunemente i principi di progettazione SOLID quando compongono i pezzi e le parti delle nostre applicazioni. Non fare una classe fare troppe cose, non rendere una interfaccia troppo grande, usare l'astrazione non le concrezioni, ecc.

È corretto applicare questa mentalità ad un livello astratto quando si pensa a soluzioni, servizi, ecc.? Il problema principale: sto lottando con la richiesta di fare un singolo servizio per fare tutto ciò che riguarda uno specifico dominio aziendale. Aggiungete a questo più team che avrebbero tutti le mani nel piatto della stessa applicazione per aggiungere qualsiasi funzionalità necessaria.

Ho in mente un servizio con molti buoni principi di architettura e design e credo che molte funzionalità "aggiuntive" potrebbero essere imbullonate verticalmente all'interno dello stesso framework e soluzione. Dopotutto, uno dei motivi per cui trascorriamo del tempo le soluzioni di architettura da accoppiare liberamente e consentire la scalabilità con facilità. Quindi potresti dire: "prendilo, se il framework può gestirlo e poi aggiungere!"

Qualcosa non mi sta proprio bene e sarei interessato a un colosso di un'applicazione / servizio che cerca di fare tutto. Ho provato a fare ricerche su "applicazioni che fanno troppo" o "servizi che hanno troppe responsabilità", ma non è venuto fuori molto. Quando comincio a pensare ai principi SOLID, penso che avere un servizio che tutto correlato a uno specifico dominio aziendale potrebbe non essere una buona idea e che potrebbe causare problemi su strada con manutenibilità e stepping su ogni le dita degli altri.

È corretto utilizzare i principi SOLID quando si esamina l'intera funzionalità della soluzione? La creazione di un servizio come http://www.mycompany.com/api/[everMethodPossible] è corretta, oppure potrei fare qualcosa che non è corretto?

Grazie!

    
posta atconway 21.01.2013 - 16:41
fonte

2 risposte

4

La ragione per cui i principi di progettazione sono così utili e perché è sfortunato che le persone li confondono con modelli è perché un principio di design è semplicemente questo; un principio per il design; tutto il design.

Puoi e dovresti applicare i principi di progettazione a tutte le cose che richiedono design, sono davvero trasversali (parole d'ordine yay!).

Ad esempio, Principle of Least Astonishment è stato creato e descritto sempre per i progettisti dell'interfaccia utente per garantire che presentino un'interfaccia utente che non causi errori agli utenti. Può comunque essere applicato a tutte le definizioni del contratto da parte degli sviluppatori, può davvero essere applicato a qualsiasi cosa, ecco perché l'esempio classico è il pulsante dell'ascensore; uno con una freccia in su che chiama l'ascensore a scendere è di scarsa progettazione.

Se i principi di progettazione possono essere applicati a un'interfaccia utente e ad un ascensore, allora onestamente tutto ciò che deve essere progettato può essere applicato. Immagina se anche il pulsante di abbassamento della finestra di una macchina accenda lo sfiato perché pensa che tu voglia l'aria fresca, suona come un cattivo design, giusto? Principio della singola responsabilità; qualsiasi pulsante di un'auto che fa più cose sembrerebbe strano per un utente.

Anche LSP può essere definito oltre il codice, pensare a un tipo di cosa comune? Di 'un taxi. Ora per un taxi li chiami e loro si presentano quando lo chiedi, un taxi che è sempre in ritardo di 15 minuti viola LSP perché ti aspetti sempre che tutti i taxi siano in orario, se ti aspettavi che siano tutti in ritardo di 15 minuti non violerebbe LSP perché seguirebbe le regole del taxi di tipo comune.

Il principio Open-Closed è osservabile nella progettazione di automobili, hanno un modello di base chiuso per la modifica ma aperto per l'estensione con un portapacchi, accesso senza chiave, rivestimento trasparente, guide laterali ecc. Il veicolo è stato progettato per consentire quelle estensioni, ma è stato progettato per essere chiuso per la modifica ed è per questo che ci vuole un meccanico per cambiare il treno di guida in AWD e non è facile nemmeno per lui. Non è stato progettato per essere modificato in questo modo, ma è stato progettato con punti di estensione pertinenti.

I sistemi su larga scala stessi a livello macro dovrebbero sicuramente tenerne conto, un singolo servizio di processo che è privo di effetti collaterali con una singola responsabilità è ottimo per alcune cose e ne segue molte, ne ha altrettante di quelli che vuoi Un servizio che fa un sacco di cose tutto da solo è comunque una violazione di SRP.

    
risposta data 21.01.2013 - 20:49
fonte
0

È corretto ? No.

La correttezza non ha nulla a che fare con questo. I principi SOLID sono buoni e possono essere applicati al di fuori di OO, come nell'architettura software o nelle funzioni di scrittura. Personalmente, trovo che siano utili nella progettazione dell'ambito dell'architettura, ma ricorda che l'obiettivo è fare del buon software, non fornire le risposte giuste a un test.

    
risposta data 21.01.2013 - 18:50
fonte

Leggi altre domande sui tag