Il sistema POS deve prevedere che esso sia lievemente modificabile, ovvero che consenta ai compratori di inserire regole di business personalizzabili.

Per essere più precisi, per esempio:

• si supponga che, quando viene creata una nuova vendita, sia possibile identificare che questa sarà pagata con un "buono regalo". Un negozio potrebbe avere un regola per consentire l'acquisto di un solo articolo nel caso in cui venga utilizzato un buono regalo. Di conseguenza, le operazioni enterItem successive alla prima devono essere invalidate.
• Inoltre, se la vendita viene pagata tramite un buono regalo, si devono invalidare tutti i tipi di restituzione del resto al cliente (al massimo sotto-forma di un nuovo buono regalo). Il resto mediante contanti deve essere invalidato.
• Si supponga poi che, quando viene creata un nuova vendita, sia possibile identificare che venga devoluta a una causa di beneficenza. Un negozio potrebbe anche avere una regole che consente solo l'inserimento di articoli il cui prezzo è inferiore a 250 dollari, e che consente l'aggiunta degli articoli alla vendita solo se il "cassiere" autenticato è un direttore.

In termini di analisi dei requisiti, occorre identificare i punti specifici negli scenari di tutti i casi d'uso. Per questa investigazione verrà considerato solo il punto enterItem, ma la stessa soluzione si applica nello stesso modo a tutti i punti.
Si supponga inoltre che l'architetto non sia sicuro dell'implementazione migliore per questa gestione delle regole inseribili, e voglia sperimentare diverse soluzioni per rappresentare, caricare e valutare le regole. Per esempio, le regole possono essere implementate con il pattern Strategy, o con un interprete di regole open source che legga e interpreti un insieme di regole IF-THEN, o con un interprete di regole commerciale, da acquistare, o con un sistema per la gestione di regole (gratuito o commerciale).

Per risolvere questo problema di progettazione è possibile utilizzare il pattern strutturale Facade.

Una Facade è un oggetto "front-end" che rappresenta il punto di entrata singolo ai servizi di un sotto-sistema; l'implementazione e gli altri componenti del sotto-sistema sono privati e non possono esser visti dai componenti esterni. Una Facade fornisce Protected Variations da cambiamenti nell'implementazione di un sotto-sistema.

Per esempio verrà fornito un sotto-sistema "motore delle regole", la cui implementazione specifica non è ancora nota. L'oggetto Facade per questo sotto-sistema sarà chiamato POSRuleEngineFacade. Il progettista decide di collocare le chiamate alla Facade vicino all'inizio dei metodi che sono stati definiti come punti per regole inseribili, come nel seguente esempio:

public class Sale{
	public void makeLineItem(ProductDescription desc, int quantity){
		SaleLineItema sli = new SaleLineItem(desc, quantity);
		// chiamata alla Facade
		if(POSRuleEngineFaced.getInstance().isInvalid(sli, this)){
			return;
		}
		// se invece la regola è soddisfatta
		lineItems.add(sli);
	}
	//...
}
Copy

Si noti l'uso del pattern Singleton. Spesso agli oggetti Facade vi si accede tramite Singleton.
Con questo progetto, la complessità e l'implementazione di come verranno rappresentate e valutate le regole sono nascoste nel sotto-sistema "motore delle regole", a cui si accede attraverso l'oggetto Facade POSRuleEngineFacade. Si osservi che il sotto-sistema nascosto dall'oggetto Facade potrebbe contenere decine o centinaia di classi oggetti, o addirittura una soluzione non orientata agli oggetti. Tuttavia, un client del sotto-sistema vede solo il suo punto di accesso pubblico unico.

Inoltre è stata ottenuta, una separazione degli interessi: tutte le problematiche di gestione delle regole sono state delegate a un altro sotto-sistema.