Podczas tworzenia oprogramowania nieustannie mamy do czynienia ze zmianami. Kiedy aplikacja zostanie napisana, jest później udoskonalana. Wprowadzane są do niej nowe funkcjonalności wymagane przez klientów. Poprawiane są także wykryte i zgłoszone błędy, by kod był coraz bardziej niezawodny. Nie da się tego wszystkiego uniknąć i długo utrzymać systemu w niezmienionym stanie. Jeśli nie zastosujemy się do odpowiednich standardów, w miarę rozwoju programu może być coraz trudniej dokonywać w nim modyfikacji. Właśnie tego problemu dotyczy druga z zasad wyrażonych akronimem SOLID, której nazwa to open-closed principle.

Geneza

Została ona opracowana w 1988 roku przez francuskiego wykładowcę naukowego Bertranda Meyera, który przedstawił ją w książce pt. „Object-Oriented Software Construction”. Jej definicja mówi, że klasy, moduły, funkcje itd. powinny być otwarte na rozszerzanie, a zamknięte na modyfikacje. Nowe funkcjonalności należy wprowadzać do aplikacji przez dodawanie nowych jednostek kodu, a nie przekształcanie istniejących. Może się to wydawać na pierwszy rzut oka niemożliwe. Jak program może zachować się inaczej, jeśli według omawianej zasady nie powinniśmy niczego zmieniać w kodzie? Poniższy przykład pokaże, w jaki sposób można to osiągnąć.

Przykład

Wyobraźmy sobie, że mamy do czynienia z aplikacją, która wykonuje różne operacje na figurach geometrycznych. Jedna z klas może zawierać metodę na przykład do obliczania sumy pól obsługiwanych kształtów. Poniżej znajduje się przykład, jak taki kod może wyglądać.

public function calculateTotalArea(array $shapes): float
{
	$totalArea = 0;

	foreach ($shapes as $shape) {
		if ($shape instanceof Rectangle) {
			$totalArea += $shape->getWidth() * $shape->getHeight();
		} elseif ($shape instanceof Triangle) {
			$totalArea += $shape->getBase() * $shape->getHeight() / 2;
		}
	}

	return $totalArea;
}

Działanie metody jest bardzo proste. Jako argument otrzymuje tablicę zawierającą obiekty figur geometrycznych, a następnie w czasie kolejnych kroków iteracji oblicza pole każdej z nich. Potem otrzymaną wartość dodaje do wyniku, który później zwraca. Niżej znajdują się proste implementacje użytych kształtów: prostokąta i trójkąta.

class Rectangle
{
	private float $width;
	private float $height;

	public function __construct(float $width, float $height)
	{
		$this->width = $width;
		$this->height = $height;
	}

	public function getWidth(): float
	{
		return $this->width;
	}

	public function getHeight(): float
	{
		return $this->height;
	}
}

class Triangle
{
	private float $base;
	private float $height;

	public function __construct(float $base, float $height)
	{
		$this->base = $base;
		$this->height = $height;
	}

	public function getBase(): float
	{
		return $this->base;
	}

	public function getHeight(): float
	{
		return $this->height;
	}
}

Taki kod działa i spełnia swoje zadanie, czyli oblicza sumę otrzymanych figur. Niestety, nie jest on dobrze napisany. Wszystko jest w porządku do momentu, kiedy zachodzi potrzeba dodania nowego kształtu do aplikacji np. trapezu. Zobaczmy, co się stanie w takiej sytuacji. Implementacja kolejnej klasy w programie może wyglądać w następujący sposób.

class Trapezoid
{
	private float $baseA;
	private float $baseB;
	private float $height;

	public function __construct(float $baseA, float $baseB, float $height)
	{
		$this->baseA = $baseA;
		$this->baseB = $baseB;
		$this->height = $height;
	}

	public function getBaseA(): float
	{
		return $this->baseA;
	}

	public function getBaseB(): float
	{
		return $this->baseB;
	}

	public function getHeight(): float
	{
		return $this->height;
	}
}

Konstruktor nowej klasy przyjmuje jako argumenty długości podstaw oraz wysokość trapezu, a gettery zwracają poszczególne rozmiary figury. Niestety nie jest to jedyna zmiana, którą należy wykonać w kodzie. Konieczne jest zmodyfikowanie metody calculateTotalArea, tak aby obliczała pole trapezu i dodawała do zwracanego wyniku.

public function calculateTotalArea(array $shapes): float
{
    $totalArea = 0;

    foreach ($shapes as $shape) {
        if ($shape instanceof Rectangle) {
            $totalArea += $shape->getWidth() * $shape->getHeight();
        } elseif ($shape instanceof Triangle) {
            $totalArea += $shape->getBase() * $shape->getHeight() / 2;
        } elseif ($shape instanceof Trapezoid) {
            $totalArea += ($shape->getBaseA() + $shape->getBaseB()) * $shape->getHeight() / 2;
        }
    }

	return $totalArea;
}

Konieczność zmodyfikowania powyższej metody oznacza, że nie spełnia ona omawianej zasady. Dzieje się tak, ponieważ dodanie nowej funkcjonalności do programu – w tym wypadku kolejnej figury geometrycznej – dokonuje się poprzez zmianę, a nie wyłącznie przez napisanie nowego kodu, czyli klasy Trapezoid. Metoda calculateTotalArea jest zatem otwarta na dodanie następnego kształtu, a powinna być na to zamknięta. Poniżej znajduje się poprawny kod, który spełnia zasadę open-closed principle.

interface ShapeInterface
{
	public function getArea(): float;
}

class Rectangle implements ShapeInterface
{
	private float $width;
	private float $height;

	public function __construct(float $width, float $height)
	{
		$this->width = $width;
		$this->height = $height;
	}

	public function getWidth(): float
	{
		return $this->width;
	}

	public function getHeight(): float
	{
		return $this->height;
	}

	public function getArea(): float
	{
		return $this->width * $this->height;
	}
}

class Triangle implements ShapeInterface
{
	private float $base;
	private float $height;

	public function __construct(float $base, float $height)
	{
		$this->base = $base;
		$this->height = $height;
	}

	public function getBase(): float
	{
		return $this->base;
	}

	public function getHeight(): float
	{
		return $this->height;
	}

	public function getArea(): float
	{
		return $this->base * $this->height / 2;
	}
}

class Trapezoid implements ShapeInterface
{
	private float $baseA;
	private float $baseB;
	private float $height;

	public function __construct(float $baseA, float $baseB, float $height)
	{
		$this->baseA = $baseA;
		$this->baseB = $baseB;
		$this->height = $height;
	}

	public function getBaseA(): float
	{
		return $this->baseA;
	}

	public function getBaseB(): float
	{
		return $this->baseB;
	}

	public function getHeight(): float
	{
		return $this->height;
	}

	public function getArea(): float
	{
		return ($this->baseA + $this->baseB) * $this->height / 2;
	}
}

public function calculateTotalArea(array $shapes): float
{
	$totalArea = 0;

	foreach ($shapes as $shape) {
		$totalArea += $shape->getArea();
	}

	return $totalArea;
}

W celu poprawienia kodu wykonanych zostało kilka zmian. Odpowiedzialność obliczania pola figury geometrycznej została przekazana do każdej z klas, a metoda calculateTotalArea tylko pobiera to pole za pomocą metody getArea. Aby to było możliwe, konieczne było utworzenie interfejsu ShapeInterface, który implementuje wszystkie kształty, tak aby obliczały i zwracały swoją powierzchnię.

W momencie kiedy zostaną wprowadzone kolejne figury, metoda calculateTotalArea nie będzie wymagała żadnych zmian. Wystarczy, że nowa klasa będzie implementowała interfejs ShapeInterface. Dzięki zastosowaniu polimorfizmu została spełniona zasada open-closed principle.

Żadnych zmian?

Według zasady open-closed principle jednostka kodu powinna być zamknięta na modyfikacje, a otwarta na rozszerzanie. Czy to oznacza, że w przedstawionej w powyższym przykładzie metodzie calculateTotalArea nie wolno wprowadzać żadnych zmian? Bynajmniej. Konieczne jest tutaj doprecyzowanie, co oznacza, że kod ma być zamknięty na modyfikacje. Nie chodzi o jakiekolwiek zmiany, ale te z pewnego zakresu. W powyższym przykładzie takim obszarem jest dodawanie nowych figur. Czyli jeśli implementujemy nową figurę, to nie musimy modyfikować metody calculateTotalArea.

Wyobraźmy sobie taką sytuację, że powstaje potrzeba zmodyfikowania działania programu w taki sposób, że ma obliczać sumę pól otrzymanych figur, ale tylko tych, których powierzchnia jest większa niż 50 jednostek kwadratowych. Metoda nie jest zamknięta na taką modyfikację, więc można ją w tym wypadku zmienić, a nawet trzeba, bo inaczej nie będzie można zrealizować nowej funkcjonalności.

public function calculateTotalArea(array $shapes): float
{
    $totalArea = 0;

    foreach ($shapes as $shape) {
        $shapeArea = $shape->getArea();

        if ($shapeArea > 50) {
            $totalArea += $shape->getArea();
        }
    }

    return $totalArea;
}

Taki kod oczywiście zadziała, ale nie jest to właściwe rozwiązanie. Wymaganie związane z tym, że mają zostać zsumowane pola większe niż 50 jednostek kwadratowych może się zmienić i na przykład będą dodawane pola tylko prostokątów. Trzeba zatem utworzyć abstrakcję do filtrowania figur.

interface ShapeFilterInterface
{
    public function filter(array $shapes): array;
}

class ShapeAreaGreaterThanFilter implements ShapeFilterInterface
{
    private float $greaterThan;

    public function __construct(float $greaterThan)
    {
        $this->greaterThan = $greaterThan;
    }

    public function filter(array $shapes): array
    {
        return array_filter($shapes, fn(ShapeInterface $shape) => $shape->getArea() > $this->greaterThan);
    }
}

public function calculateTotalArea(array $shapes, ShapeFilterInterface $shapeFilter): float
{
    $totalArea = 0;
    $shapes = $shapeFilter->filter($shapes);

    foreach ($shapes as $shape) {
        $totalArea += $shape->getArea();
    }

    return $totalArea;
}

Został utworzony interfejs ShapeFilterInterface wraz z jego implementacją ShapeAreaGreaterThanFilter. Konstruktor klasy przyjmuje liczbę, od której mają być większe pola figur przekazanych do metody calculateTotalArea. Ta wartość może się zmieniać, zatem powinna zostać zapisana np. w pliku konfiguracyjnym, w którym będzie można ją łatwo zmodyfikować. Gdyby umieścić ją w kodzie filtra, to każda jej zmiana wymagałaby wyedytowania pliku z klasą.

Korzyści

Stosowanie reguły open-closed principle ma kilka zasadniczych zalet. Po pierwsze w kodzie jest mniej zależności między poszczególnymi modułami, klasami, funkcjami itd. Dzięki temu unikamy przykrej sytuacji, kiedy po zmodyfikowaniu jakiegoś fragmentu aplikacji, trzeba wprowadzić zmiany w miejscu, które jest od tego pierwszego zależne. Po wykonaniu w nim pracy, okazuje się, że jest jeszcze następne, a potem kolejne, w których coś trzeba zrobić. W takich warunkach łatwo o przeoczenie czegoś i wprowadzenie błędu do programu.

Drugą korzyścią ze stosowania tej reguły jest zredukowanie liczby problemów polegających na tym, że modyfikacja w jednym miejscu kodu psuje coś w innym fragmencie, często niezwiązanym z tym pierwszym. Ma to związek z poprzednim punktem. Jeśli nie mamy zależności, które mogą być potencjalnym źródłem błędu, to możemy swobodnie wprowadzać zmiany w kodzie.

Kolejną zaletą tej zasady jest to, że dzięki niej kod jest odpowiedni do ponownego użytku w innym module lub nawet osobnym projekcie. Można to przedstawić na przykładzie kodu z figurami geometrycznymi, który został zaprezentowany wcześniej. Można wykorzystać interfejs ShapeInterface oraz metodę calculateTotalArea, ale napisać zupełnie nowe implementacje interfejsu.

Wreszcie stosując się do zasady, pracujemy efektywniej i oszczędzamy sporo czasu, który musielibyśmy przeznaczyć na rozwiązywanie problemów wynikających z tego, że dana jednostka kodu jest otwarta na zmiany.

Podsumowanie

Po przedstawieniu definicji, przykładów oraz zalet zasady otwarte-zamknięte przyszedł czas na wypróbowanie jej w swojej codziennej pracy. Korzyści jakie to przyniesie spowodują, że pisany przez nas kod będzie dużo lepszej jakości, ponieważ zostanie przygotowany na efektywne wprowadzanie zmian, a także otrzymamy możliwość łatwego przeniesienia go do innego modułu lub projektu, co niewątpliwie zaoszczędzi wiele czasu w przyszłości.

Autorem tekstu jest Szymon Czembor