Единый принцип доступа Бертрана Мейера

В своей первой статье на Medium я решил начать с одного из классиков дизайна программного обеспечения: универсального принципа доступа Бертрана Мейера. Эта фундаментальная концепция, изложенная в книге«Object-Oriented Software Construction» (1997), имеет решающее значение для современной разработки программного обеспечения и повлияла на целое поколение разработчиков. Ниже мы проанализируем важность принципа единого доступа и то, как его можно применять для создания простого в обслуживании программного обеспечения.

Бертран Мейер: пионер в разработке программного обеспечения

Бертран Мейер — влиятельный исследователь, писатель и консультант в области компьютерных языков, создатель языка программирования Eiffel. Его работа сыграла важную роль в создании основ современного дизайна программного обеспечения и повлияла на целое поколение разработчиков.

Единый принцип доступа Мейера

Принцип гласит, что свойства и операции объекта должны быть доступны единообразно, без раскрытия того, являются ли они сохраненными атрибутами или результатами операций. Это позволяет клиентам объекта сосредоточиться на его функциональности и поведении, а не беспокоиться о его реализации.

Пример, нарушающий принцип

Чтобы лучше понять этот принцип, полезно увидеть пример, который ему не соответствует. Рассмотрим класс Square, представляющий квадрат на двумерной плоскости. Этот класс имеет общедоступное свойство $sideLength и два общедоступных метода getArea() и getPerimeter(), которые вычисляют площадь и периметр квадрата соответственно.

class Square {
    public $sideLength;

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

    public function getArea() {
        return pow($this->sideLength, 2);
    }

    public function getPerimeter() {
        return 4 * $this->sideLength;
    }
}

В этом примере показано, как можно получить прямой доступ к свойству $sideLength, что нарушает унифицированный принцип доступа и предоставляет доступ к внутренней реализации класса внешнему коду. Это может вызвать проблемы с ремонтопригодностью и гибкостью.

Практический пример на PHP

Чтобы решить эту проблему, можно применить этот принцип, используя методы получения и установки для унифицированного взаимодействия с атрибутами и операциями объекта. Например, вот новая версия класса Square, соответствующая принципу:

class Square {
    private $sideLength;

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

    public function getSideLength() {
        return $this->sideLength;
    }

    public function getPerimeter() {
        return  4 * $this->getSideLength();
    }

    public function getArea() {
        return pow($this->getSideLength(), 2);
    }
}

В этом примере метод getSideLength был создан для свойства $sideLength. Это гарантирует, что изменения во внутренней реализации класса не повлияют на внешних пользователей.

Чтобы продемонстрировать гибкость этого принципа, мы можем изменить класс Square, чтобы он хранил периметр вместо длины стороны:

class Square {
    private $perimeter;

    public function __construct($sideLength) {
        $this->perimeter = $sideLength * 4;
    }

    public function getSideLength() {
        return $this->getPerimeter() / 4;
    }

    public function getPerimeter() {
        return $this->perimeter;
    }

    public function getArea() {
        return pow($this->getSideLength(), 2);
    }
}

В этой версии класса Square свойство, в котором хранится информация, заменено местами. Теперь периметр сохраняется вместо длины стороны, а метод getter был изменен, чтобы возвращать правильное значение. Несмотря на эти внутренние изменения в реализации класса, клиенты могут продолжать единообразно взаимодействовать с классом с помощью методов getter и setter, не зная о внутренних изменениях. Это демонстрирует гибкость и простоту обслуживания, которые обеспечивает этот принцип.

Риски неправильного использования геттеров и сеттеров

Важно помнить, что чрезмерное использование getters может привести к проблемам проектирования программного обеспечения и нарушить принцип инкапсуляции. Поэтому важно следовать принципу "говорить, а не спрашивать" при разработке классов и объектов, чтобы предоставлять методы, которые выполняют желаемую задачу, а не обращаются к внутренней части объекта. информация.

В следующей статье я подробно расскажу о принципе "говори, не спрашивай" и о рисках неправильного использования getters.

Заключение

Унифицированный принцип доступа — это фундаментальная концепция проектирования программного обеспечения, которая сыграла ключевую роль в разработке программного обеспечения. Применяя этот принцип, можно создать более эффективное, простое в обслуживании и гибкое программное обеспечение.

В будущих статьях я продолжу делиться информацией и знаниями о классических концепциях проектирования программного обеспечения, которые могут быть полезными и интересными.