Usando le funzionalità del linguaggio comune solo nel mio ambiente di lavoro, è una buona abitudine?

Recentemente ho fatto un esercizio in cui ho realizzato un design UML completo per un piccolo sistema, quindi ho provato a implementarlo. L'UML è stato scritto il più possibile indipendente dalla lingua, anche se forse un po 'influenzato da Java. Tuttavia, ho usato C ++ per implementarlo. Cosa ho imparato?

Non esiste un progetto indipendente dalla lingua. Le decisioni di progettazione sono modellate dal loro contesto, e le strutture e le lingue fanno parte di quel contesto. Ci sono stati cambiamenti significativi necessari per trasferire l'essenza del design all'implementazione, ma questi cambiamenti hanno avuto un impatto su quasi tutte le dichiarazioni dei metodi, hanno aggiunto e rimosso alcune classi e hanno ricollegato l'interazione tra le classi. L'unica parte rimasta invariata era il nome di alcune classi nel mio modello di dominio.

Anche se i singoli progetti non sono universali, la progettazione di piattaforme specifiche non dovrebbe essere problematica per te. Dopotutto, la progettazione e la risoluzione dei problemi sono meta-competenze che abbracciano l'insieme del tuo lavoro. In effetti, queste abilità diventano più forti man mano che le eserciti attraverso vari domini e contesti, dato che sei costretto a valutare nuovi approcci.

A questo proposito, risolvere lo stesso problema su due piattaforme diverse è un esercizio interessante: la seconda volta, hai una comprensione molto più completa del problema e già conosci le possibili soluzioni. Invariabilmente, i due disegni saranno diversi, ma confrontare queste differenze è una possibilità di migliorare entrambe.

Ma non puoi semplicemente riutilizzare tutte le decisioni di progettazione. L'unica cosa che puoi riutilizzare è tutto il lavoro che porta al design: raccogliere i requisiti ed eseguirne un'analisi. Il risultato dell'analisi potrebbe includere i modelli UML, ma questi sarebbero veramente astratti e indipendenti dalla lingua. Quando concretizzi questo in un progetto, vuoi comunque assicurarti che entrambi i disegni risolvano lo stesso problema. Una matrice di tracciabilità dei requisiti è un possibile approccio: una tabella in cui vengono elencati tutti i requisiti e viene descritto come ogni design li soddisfa. Tale tabella è particolarmente utile più avanti nel ciclo di vita del software per evitare divergenze tra le due applicazioni: è improbabile che altri programmatori che si uniscono più tardi (o anche voi stessi in tre mesi) tengano conto del "quadro generale" per ogni piccolo cambiamento. p>

Un altro approccio per riutilizzare il maggior sforzo possibile è di riutilizzare letteralmente il codice su tutte le piattaforme. Il codice multipiattaforma fornirebbe la funzionalità richiesta come una libreria e un wrapper specifico della piattaforma integrerebbe questa libreria con la piattaforma e fornirà l'interfaccia utente. Tuttavia, molte app in realtà non fanno nulla di spettacolare, e la maggior parte dello sforzo richiesto è nell'interfaccia utente che non è possibile riutilizzare comunque (PhoneGap o tecnologie simili nonostante).

Questo è il tipo di cosa che va male in entrambi i casi se spingi fino a lontano.

Sì, è meglio non dipendere da stranezze della lingua in un disegno che si desidera riutilizzare in un'altra lingua.

Tuttavia, non è bello essere ossessionati dal fatto che una "caratteristica linguistica" esista in entrambi, specialmente se può essere facilmente risolta.

L'ereditarietà multipla è un esempio sfortunato qui. Principalmente perché l'ereditarietà è in disgrazia. Preferisco la composizione. Ma se ci atteniamo a questo, tieni presente che mentre java non esegue l'ereditarietà multipla, può implementare tutte le interfacce a tuo piacimento. Il che è un lungo modo per dire, solo perché non è un "linguaggio" non significa che non possiamo trovare un modo per farlo. Questo è ciò che molti dei modelli di progettazione GoF sono veramente.

Accadranno modelli, soluzioni temporanee e kludges. Non avranno lo stesso aspetto in ogni lingua. Scusa, ma la parità da 1 a 1 qui non accadrà.

Puoi provare a battere il modo in cui esprimi le soluzioni in uniformità per aumentare la manutenibilità del tuo progetto generale. Questo renderà la lettura del codice più facile. Limiterà le soluzioni a tua disposizione. Ma potresti essere in grado di mantenere le differenze nel design al minimo.

Se riesci ad accettare che un 1 a 1 perfetto non accadrà e miri semplicemente a mantenere le due basi di codice in modo abbastanza simile che la conoscenza di una sarà utile nell'altra, allora è ok fare alcune scelte progettuali semplicemente per mantenere le due basi di codice simili.

Ma se passi un sacco di tempo ad angustiarti, è ora di lasciar perdere.