Il modo in cui molti modelli di design sono descritti nella letteratura classica è in qualche modo diverso dalla loro implementazione in linguaggi dinamici come Javascript.
La presenza di alcune funzioni come le funzioni di prima classe rende strutturalmente uguali le implementazioni di pattern, cosa che a volte rende più difficile distinguerle.
Ho avuto questo pezzo di codice legacy che si basa su Amazon S3 per l'archiviazione. Ci sono alcune funzioni di facciata che mirano a semplificarne l'uso: getS3 , putS3 , listS3 e così via ...
Non disponevamo di un'adeguata configurazione di sviluppo e mentre cercavo di crearlo, ho sentito la necessità di scrivere dati in diverse posizioni in S3 per ambienti di produzione e sviluppo.
La mia idea era di anteporre un bucket di sviluppo predefinito al percorso S3. Poiché non volevo toccare le funzioni originali, ho pensato ad una funzione wrapper che inizialmente ho chiamato environmentDecorator come allusione al pattern Decorator.
È più o meno come:
function environmentDecorator(fn) {
return function(bucket, key, ...rest) {
if (environment === 'development') {
key = bucket + '/' key
bucket = 'development-bucket'
}
return fn(bucket, key, ...rest)
}
}
Il motivo per cui ho pensato al Decorator Pattern è stata la "capacità di aggiungere responsabilità dinamicamente [alle funzioni]" senza cambiare la loro interfaccia.
Tuttavia, alcuni giorni dopo, mentre stavo rivedendo questo codice, ho pensato che sarebbe stato più adatto per il Pattern Proxy definizione: "Fornisci un surrogato o segnaposto per un altro oggetto per controllarne l'accesso" e "Aggiungi un wrapper e una delega per proteggere il componente reale da una complessità eccessiva" . Se è così, dovrei chiamare il mio wrapper environmentProxy .
Vedo che questa è una domanda teorica e l'importante è risolvere il problema, ma non ho potuto fare a meno di incuriosirlo.