Эпизод 3. Интерфейсы и трейты

Приветствую всех в третей, заключительной, части минисериала ” Сущности ООП”. Здесь я буду повествовать об интерфейсах и трейтах(что следует с названия) – что это? зачем? как использовать?

Интерфейсы

С этого сайта: интерфейс — это класс, в котором все методы являются абстрактными и открытыми. Определение, которое даю я на тех.собеседованиях(исходя из своего понимания) – интерфейс – это карта публичных свойств и методов класса, который будет его реализовывать.

Свойства интерфейсов

Как сказал ранее – он определяет публичные свойства(исключая тело метода, только имя и параметры) и методы класса. Также, он определяет константы класса и, в отличии от полей, они могут принимать значения в самом интерфейсе; затем эти константы будут доступны в классе-реализаторе.

<?php
interface B
{
    const A = 1;
    function rr();
}

interface C
{
    function drr();
}

interface D extends B,C
{
}

class Page implements D
{
    function __construct()
    {
        echo self::A;
    }

    function rr()
    {
    }

    function drr()
    {
    }
}

new Page();

/*
Вывод:
1
Process finished with exit code 0

В коде выше(PHP) приведено еще одно свойство интерфейсов – множественное наследование. Несмотря на то, что это карта класса, конечный класс может содержать иные, как публичные, так и скрытые методы и поля.

Разница между абстрактным классом и интерфейсом

Первое – это разные сущности – соответственно, срои сущностные особенности – это и очевидного… Следующее – это то, что в абстрактном классе могут быть реализованные методы. В целом, это все отличия.

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

Трейты

Трейт – это механизм обеспечения повторного использования кода в языках с поддержкой только одиночного наследования определение от разработчиков PHP. По сути, это решение-костыль для языков с одиночным наследованием, но где хочется/нужно наследовать больше кода; т.е. трейт не может быть инициализирован в объект(как и интерфейс, и абстрактный класс), что, также, означает, что трейт без класса ничто(как и интерфейс, в общем-то…).

Свойства

Здесь речь будет не о том, что можно сделать в трейте, а о том как клас вращает трейты. Почему же о классах? – потому как в трейте можно только объявлять методы, свойства и константы. Нет, соврал… трейт может использовать трейт(строка 12), также содержать абстрактные и статические методы и свойства.

Итак, о классах… начнем с того, что можно подмешивать в класс более одного трейта(строка 23). При этом методы и свойства одного метода доступны в другом(если они публичны, строка 6). Об области видимости – она такая же как у классов, с теми же модификаторами.

<?php
trait  A
{
    public function ff()
    {
        echo $this->b;
    }
}

trait B
{
    use C;
    public $b;
    protected function  ff()
    {}
}

trait C
{}

class Page
{
    use A, B {
        A::ff insteadof B;
        b as private;
    }
}

Теперь пару строк о структуре после перечисления используемых трейтов(строки 23 – 26). Поскольку в двух примесях есть метод с одинаковым названием – возникает конфликт и код выкинет фатальную ошибку. Строка 24 говорит о том, что в классе нужно отдать предпочтение методу с трейта А(A::ff вместо B); аналогично работает и для свойств. Строка 25 – изменение видимости свойства/метода.

Как уже отмечалось ранее, цель – это способ осуществления множественного наследования там, где оно недоступно на прямую.

Эпизод 4. О – OCP: The Open Closed Principle

Приветствую вас в 4-ом эпизоде сериала “ООП здорового человека”. Здесь речь пойдет о 2-ом принципе SOLID – открытость-закрытость кода…

Теория

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

Здесь я немного припух: как так – дядя Боб(на деле – первая формулировка сиего принципа принадлежит Бертрану Мейеру) запрещает использовать одну из возможностей ООП? Ну-да… полазив в интернете, посмотрев иные трактовки(а также пример в книге Роба) – нет! Речь идет не о наследовании, а о порождении объекта класса для дальнейшего использования(что, в принципе, не перечит моей трактовке… однако, я не представляю – как не переопределять методы родителя в некоторых ситуациях…).

Речь, как я понял(если откинуть мою трактовку) об объектном полиморфизме. Смысл в том, чтоб при создании метода (вызывающего класс в процессе работы) была предусмотрена возможность изменить вызываемый класс, не изменяя, при этом, сам метод. Кста, мы уже знаем о SRP, поэтому в его контексте: при соблюдении OCP также будет соблюден SRP, поскольку точка зависимости от чужого класса останется одной.

Примеры

№1: печатная машинка и компьютер с принтером; и там и там пользуясь клавиатурой происходит набор текста, затем краска на бумаге отображает набранное. Интерфейс одинаков, результат тоже – различные только механизмы между точками.

Практика

Для иллюстрации этого принципа рассмотрим класс Product(из этой статьи); а именно – метод получения данных о продукте. Дело в том ,что эти данные где-то лежат; соответственно, нужно установить связь с хранилищем, составить запрос и исполнить его – и всем этим занимается отдельный(-е) класс. Представим это так

<?php
class Product
{
    // достать инфо  о продукте:
    // -- дергаем Storage и строим запрос
    // -- приказываем выполнить его
    // дергаем Currency и пересчитываем цену продукта
}

class Storage
{
    // Устанавливаем соединение с хранилищем
    // выполняем запрос
}

Теперь, хранилища могут быть разные(MySQL, MongoDB, обычный файл…); у каждого свой способ соединения и свой способ задать вопрос – в общем свой класс. Этот принцип о том, что класс Storage должен проектироваться так, чтоб он мог работать с классом любой БД:

<?php
class Storage
{
    // Приказ об устанавлении соединения с хранилищем:
    // -- получим инфу об используемой БД
    // -- инициализируем новый экземпляр для работы с БД
    // выполняем запрос
}

ну и, как все понимают, классы работы с хранилищами должны иметь одинаковые методы. Для реализации данного принципа построения кода придуманы дизайн-паттерны кода – Стратегия и  Шаблонный метод; разберу эти паттерны позже – в этой же статейке я хотел показать, что в подобных ситуациях(когда логика говорит о возможности появлении вариантов развития системы) – используй порождение объекта, а не наследование его класса. Можно конечно и начальный способ оставить – но это чревато ошибками в будущем… и это уже не про мой сериал.