Per esempio, il problema del servizio esterno per la contabilità risolto (e illustrato in Polymorphism) illustrano Protected Variations. Il punto di instabilità o variazione è quello corrispondente alle diverse interfacce o API dei servizi esterni. Il sistema POS deve essere in grado di integrarsi con molti servizi per la contabilità esistenti, e anche con servizi futuri prodotti da terze parti e non ancora esistenti.

Aggiungendo un livello di indirezione, un'interfaccia, e usando il polimorfismo con varie implementazioni di IAccountingAdapter, si ottiene la protezione, all'interno del sistema, da variazioni dei servizi esterni e delle loro API. Gli oggetti interni collaborano con un'interfaccia stabile; le varie implementazioni degli adattatori nascondono le variazioni nei servizi esterni.

(In fondo alla pagina un esempio con codice per una migliore comprensione)

Protected Variations è un servizio molto importante. Circolava già da decenni sotto diversi nomi, tra cui information hiding.

Un importante principio classico della progettazione a oggetti è chiamato Don't talk to strangers o Legge di Demeter. In breve, suggerisce di evitare di creare progetti che attraversano percorsi lunghi nella struttura degli oggetti e inviano messaggi a oggetti lontani e indiretti (gli estranei).

PV (protected variations) è un principio più generale di Don't talk to strangers, poiché quest'ultimo è un caso particolare di PV.

Don't talk to strangers pone dei vincoli sugli oggetti con i quali si può comunicare all'interno di un metodo. Esso afferma che all'interno di un metodo i messaggi devono essere inviati solo ai seguenti oggetti:

• this
• un parametro del metodo
• un attributo di this
• un elemento di una collezione e la collezione è un attributo di this
• un oggetto creato all'interno del metodo
  Lo scopo è quello di evitare di accoppiare un client alla conoscenza di oggetti indiretti e delle connessioni tra oggetti.

Gli oggetti diretti sono i familiari gli indiretti sono gli estranei.
Nel seguente esempio si viola (leggermente) Don't talk to strangers:

public class Register{
	private Sale sale;

	public void method(){
		// sale.getPayment() invia un messaggio ad un familiare (sale) per ottenere payment
		// è familiare perchè sale è un attributo di this
		// invece sale.getPayment().getTenderAmount() viola le regole
		// si sta cercando di comunicare con un attributo di sale (che è un familiare)
		// ma i suoi attributo no
		
		Money amount = sale.getPayment().getTenderAmount();
	
		// ...
	}
	// ...
}
Copy

Questo codice attraversa connessioni strutturali da un oggetto familiare (Sale) a un oggetto estraneo (il Payment), quindi invia a esso un messaggio. È solo leggermente fragile, poiché dipende dal fatto che gli oggetti Sale sono connessi a oggetti Payment. Realisticamente, è poco probabile che ciò costituisca un problema.

Tuttavia si consideri il seguente frammento di codice, che attraversa il percorso strutturale andando più lontano:

public void method(){
	AccountHolder holder = sale.getPayment().getAccount().getAccountHolder();
	// ...
}
Copy

L'esempio è forzato, ma si vede che si attraverso un lungo percorso tra oggetti andando più lontano.
Più lungo è il percorso attraversato dal programma più esso è fragile. Ciò è dovuto al fatto che la struttura degli oggetti (le connessioni) può cambiare; ciò è particolarmente vero nelle applicazioni giovani o nelle iterazioni iniziali.

La soluzione richiede l'aggiunta di nuove operazioni pubbliche ai "familiari" di un oggetto; queste operazioni forniscono le informazioni che si desiderano alla fine avere, e nascondono il modo in cui sono state ottenute. Per esempio, per supportare Don't talk to strangers per i due casi precedenti:

// caso 1
Money amount = sale.getTenderedAmountOfPayment();
// caso 2
AccountHolder holder = sale.getAccountHolderOfPayment();
Copy

Non sprecare diverse ore nella creazione di superclassi delle classi che era davvero necessario scrivere. Ciò rende ogni cosa molto flessibile (e protetta dalle variazioni), in vista di quella situazione futura in cui il progetto ripagherà le ore perse nella creazione di superclassi, ma che immancabilmente non si verificherà.

Gli sviluppatori principianti tendono alla progettazione fragile, gli sviluppatori intermedi tendono a progetti eccessivamente fantasiosi, flessibili e generalizzati. I progettisti esperti scelgono con discernimento; magari un progetto semplice e fragile in cui il costo di un cambiamento viene bilanciato con la probabilità dello stesso.

PV è sostanzialmente uguale ai principi dell'information hiding e open-closed, che saranno discussi tra quale riga. Come pattern ufficiale nella comunità dei pattern, fu chiamato "Protected Variations".

Prima vediamo un frammento di codice che non usa protected variations.
Immaginiamo un'applicazione in cui si fruisce di un servizio di mailing e di accesso ad un database.

public class OrderProcessor{
	private DatabaseConnection dbConn;
	private EmailServive emailService;

	public OrderProcessor(){ // costruttore
		dbConn = new DatabaseConnection();
		emailService = new EmailService();
	}

	public void processOrder(Order order){
		dbConn.connect();
		dbConn.saveOrder(order);
		
		emailService.sendEmail("Order processed successfully");

		dbConn.disconnect();
	}
}
Copy

Il problema del codice sopra è che il "servizio esterno" in questo caso è EmailService e DatabaseConnection. Essi vengono implementati già in OrderProcessor ed utilizzati in loco. Il che vuol dire che se le API di questi due servizi variassero, il codice relativo a OrderProcessor dovrebbe essere ritoccato e adattarlo alle nuove API.

Ora vediamo la correzione per questo stesso frammento di codice: prima di tutto bisogna aggiungere delle interfacce una per ogni servizio.

public class ShoppingCart {
    // Supponiamo che questa classe sia il carrello di un sito di e-commerce

    private List<Item> items;

    public ShoppingCart() { // costruttore
        items = new ArrayList<>();
    }

    public void addItem(Item item) {
        items.add(item);
    }

    public void removeItem(Item item) {
        items.remove(item);
    }

    public double calculateTotalPrice() {
        double totalPrice = 0.0;
        for (Item item : items) {
            totalPrice += item.getPrice();
        }
        return totalPrice;
    }
}
Copy

Il problema di questa classe è che ShoppingCart è fortemente accoppiata a Item, se sopraggiungono dei cambiamenti in Item si rischia di dover ritoccare diverse parti del codice di ShoppingCart.
Per cui possiamo aggiungere una interfaccia:

public interface Item {
	double getPrice();
}
Copy

e fare si che, per esempio, Product sia una implementazione di Item

public class Product implements Item {
	private double price;

	public Product(double price){
		this.price = price;
	}
	
	@Override
	public double getPrice(){
		return price;
	}
}
Copy

Il codice nella prima parte resta invariato.

Ora supponiamo invece che ShoppingCart voglia fare uso di un servizio per il calcolo dello sconto degli elementi nel carrello. Verranno forniti, da terze parti, le API del modulo esterno per il calcolo dello sconto.
Dato che tali API potrebbero cambiare nel corso del tempo, anziché accoppiare ShoppingCart direttamente con una classe che implementa le API fornite. Si può creare una interfaccia con la firma dei metodi necessari e creare una classe che la implementa, nel caso in cui dovessero verificarsi dei cambiamenti, grazie all'interfaccia (e ai principi di PV) si riesce a mitigare l'impatto di tali cambiamenti.

public interface DiscountCalculator {
    double calculateDiscount(double price);
}

public class ThirdPartyDiscountCalculator implements DiscountCalculator {
    // Implementazione del calcolo dello sconto usando un servizio di terze parti

    @Override
    public double calculateDiscount(double price) {
        // Implementazione delle API del servizio di terze parti
        // ...
        return discountedPrice;
    }
}

public class ShoppingCart {
    private List<Item> items;
    private DiscountCalculator discountCalculator;

    public ShoppingCart(DiscountCalculator discountCalculator) {
        items = new ArrayList<>();
        this.discountCalculator = discountCalculator;
    }

    public void addItem(Item item) {
        items.add(item);
    }

    public void removeItem(Item item) {
        items.remove(item);
    }

    public double calculateTotalPrice() {
        double totalPrice = 0.0;
        for (Item item : items) {
            totalPrice += item.getPrice();
        }
        double discount = discountCalculator.calculateDiscount(totalPrice);
        return totalPrice - discount;
    }
}

Copy

Il punto è che se la classe ThirdPartyDiscountCalculator dovesse aggiungere una nuova feature, come segue:

public class ThirdPartyDiscountCalculator implements DiscountCalculator {
    // Implementazione del calcolo dello sconto usando un servizio di terze parti

    @Override
    public double calculateDiscount(double price) {
        // Implementazione delle API del servizio di terze parti
        // ...
        return discountedPrice;
    }

	public void newFeatureCalculation(double price) {
		// Aggiunta di una nuova feature
		// ...
	}
}
Copy

quello che succede in ShoppingCart è che l'attributo discountCalculator è del tipo DiscountCalculator (che è l'interfaccia), nell'interfaccia non è ancora stata aggiunta la firma del metodo che fa riferimento alla nuova feature, perché per il Polimorfismo verrebbe ricercata lì.
In un secondo momento si può decidere di aggiungere la firma che fa riferimento alla nuova feature e renderla disponibile anche a DiscountCalculator.