design-patterns - libro - design patterns: elements of reusable object-oriented software




Oltre i modelli di design? (2)

Negli ultimi 10 anni ci sono stati un'infarinatura di articoli e documenti che fanno riferimento al nuovo lavoro di Christopher Alexander "La natura dell'ordine" e come può essere applicato al software.

Sfortunatamente, le uniche opere che riesco a trovare sono di James Coplien e Richard Gabriel; non c'è niente oltre a questo, almeno dai miei tentativi di trovare tali cose attraverso Google.

Questo tipo di discussione sta accadendo ovunque?

MSN

@Georgia

La mia domanda non riguarda modelli di design o linguaggi di pattern; si tratta di provare a vedere se più del lavoro di Christopher Alexander può essere applicato al software (cosa che probabilmente può, dal momento che ha ancora meno vincoli fisici rispetto all'architettura e alla costruzione).

Sembra che gli schemi di progettazione e i linguaggi del motivo abbiano abbracciato la struttura degli schemi progettuali di Alexander, ma non molti ne catturano l'essenza. L'essenza è qualcosa che va oltre la soluzione di un problema in un particolare contesto.

È difficile da spiegare senza utilizzare alcuni dei lavori successivi di Alexander come punto di riferimento.

Edit: No, riprendo quello.

Ad esempio, esiste un modello di progettazione architettonica chiamato Alcoves. Il modello ha un contesto che non è solo radicato nelle circostanze della situazione, ma anche radicato in fondamenti sullo scopo degli edifici: che sono strutture per essere vissute e devono promuovere la vita in esse. Nel caso del pattern Alcove, il contesto è che si desidera un'area che consenta a più persone di trovarsi nella stessa area a fare cose diverse, perché è importante che i membri della famiglia siano fisicamente insieme e in grado di fare cose che tendono a distrarre gli altri membri della famiglia.

La maggior parte dei modelli di progettazione software descrive un problema in un contesto, ma non fanno dichiarazioni più profonde sul perché il problema è importante, o sul perché il problema sia fondamentale per il software. Rende molto facile applicare i modelli di progettazione in modo inappropriato o blandamente, che è l'esatto opposto dell'intento dei modelli di progettazione con cui è iniziato.

MSN



La tua domanda richiama alcuni dei commenti fatti da Eric Evans nel suo libro "Domain-Driven Design". Sottolinea che i modelli di progettazione nello sviluppo del software sono stati spesso descritti come soluzioni strettamente tecniche a problemi tecnici. Ma a volte c'è l'opportunità di applicare un modello che non solo dia una struttura all'implementazione del software, ma che sia anche significativo nel modello di business.

Ad esempio, considera l'utilizzo del pattern STRATEGY come un semplice dettaglio di implementazione, rispetto al caso in cui ha effettivamente senso per i programmatori e l'azienda parlare di come vengono selezionate e utilizzate STRATEGIE, cioè dove fa parte della LINGUA UBIQUITOSA del sistema:

Quando utilizziamo il modello di progettazione tecnica nel livello dominio, dobbiamo aggiungere una motivazione aggiuntiva, un altro livello di significato. Quando la STRATEGIA corrisponde a una vera strategia o politica aziendale, il modello diventa più di una semplice tecnica di implementazione (anche se anche questo è prezioso fino a quel punto). [Capitolo 12]

Evans sostiene che l'allineamento del modello software con il modello profondo del dominio aziendale è un obiettivo difficile da raggiungere, ma che fornisce una quantità enorme di valore. Se ha ragione, forse la "dichiarazione più profonda" che un modello di progettazione del software deve fare è: come si inserisce il modello nel più ampio contesto del problema, oltre lo stretto ambito tecnico del sistema software stesso.







design-patterns