Что такое интерфейсы php
Перейти к содержимому

Что такое интерфейсы php

  • автор:

PHP: Используем Интерфейсы для улучшения кода

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

Целевая аудитория

Эта статья предназначена для разработчиков, которые имеют базовые представления о концепциях ООП (объектно-ориентированного программирования) и использовании наследования в PHP. Если вы знаете, как использовать наследование в своём PHP коде, мы надеемся, что эта статья будет понятной.

Что такое Интерфейсы

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

Интерфейсы должны:

  • Использоваться для определения публичных методов класса.
  • Использоваться для определения констант класса.

Интерфейсы не должны:

  • Использоваться сами по себе.
  • Использоваться для определения приватных или защищённых методов класса.
  • Использоваться для определения свойств класса.

Интерфейсы используются для определения публичных методов, которые должен включать класс. Важно помнить, что определены только сигнатуры методов и что они не включают тело метода (как вы обычно видите в методе класса). Это связано с тем, что интерфейсы используются только для определения взаимодействия между объектами, а не для определения взаимодействия и поведения, как в классе. Что дать немного контекста, в этом примере показан пример интерфейса, который определяет несколько общедоступных методов:

interface DownloadableReport 

public function getName(): string;

public function getHeaders(): array;

public function getData(): array;
>

Согласно php.net, интерфейсы служат нескольким целям:

  1. Позволить разработчикам создавать объекты разных классов, которые могут использоваться взаимозаменяемо, поскольку они реализуют один и тот же интерфейс или интерфейсы. Типичный пример — несколько служб доступа к базе данных, несколько платёжных шлюзов или разные стратегии кэширования. Различные реализации могут быть заменены, не требуя каких-либо изменений в коде, который их использует.
  2. Позволить функции или методу принимать и оперировать параметром, который соответствует интерфейсу, не заботясь о том, что ещё может делать объект или как он реализован. Эти интерфейсы часто называют Iterable , Cacheable , Renderable и т.д., чтобы описать поведение.

Использование Интерфейсов в PHP

Интерфейсы могут быть бесценной частью кодовых баз ООП (объектно-ориентированного программирования). Они позволяют нам отделить наш код и улучшить расширяемость. Для иллюстрации этого, давайте рассмотрим следующий класс:

class BlogReport 

public function getName(): string

return 'Blog report';
>
>

Как вы видите, мы определили класс с методом возвращающим строку. Таким образом, мы определили поведение метода, мы можем увидеть как getName() формирует возвращаемую строку. Однако допустим, что мы вызываем этот метод в нашем коде внутри другого класса. Другой класс не заботит то, как была сформирована эта строка, его заботит только то, что бы она была возвращена. Например, давайте посмотрим, как мы могли бы вызвать этот метод в другом классе:

class ReportDownloadService 

public function downloadPDF(BlogReport $report)

$name = $report->getName();

// Download the file here.
>
>

Хотя вышеприведённый код работает, давайте представим, что мы хотим добавить функциональность для загрузки пользовательского отчёта из класса UserReport . Конечно, мы не можем использовать существующий метод в нашем ReportDownloadService , потому что мы установили, что можно передавать только класс BlogReport . Итак, нам нужно переименовать существующий метод, а затем добавить новый метод, как показано ниже:

class ReportDownloadService 

public function downloadBlogReportPDF(BlogReport $report)

$name = $report->getName();

// Download the file here.
>

public function downloadUsersReportPDF(UsersReport $report)

$name = $report->getName();

// Download the file here.
>
>

Хотя вы этого не видите, давайте предположим, что остальные методы в приведённом выше классе используют идентичный код для создания загрузки. Мы могли бы превратить их общий код в методы, но, вероятно, у нас всё равно будет какой-то общий код. Кроме того, у нас будет несколько точек входа в класс, выполняющий почти идентичный код. Это потенциально может привести к дополнительной работе в будущем при попытке расширить код или добавить тесты.

Представим, что мы создаём новый AnalyticsReport ; нам нужно добавить в класс новый метод downloadAnalyticsReportPDF() . Как вы видите этот файл может начать быстро расти. Это может быть идеальным местом для использования интерфейсов.

Давайте создадим один; назовём его DownloadableReport и определим так:

interface DownloadableReport 

public function getName(): string;

public function getHeaders(): array;

public function getData(): array;
>

Теперь вы можете обновить BlogReport и UsersReport для реализации интерфейса DownloadableReport , как показано в примере ниже. Но обратите внимание, я намеренно неправильно написал код для UsersReport , что бы кое-что продемонстрировать!

class BlogReport implements DownloadableReport 

public function getName(): string

return 'Blog report';
>

public function getHeaders(): array

return ['The headers go here'];
>

public function getData(): array

return ['The data for the report is here.'];
>
>
class UsersReport implements DownloadableReport 

public function getName()

return ['Users Report'];
>

public function getData(): string

return 'The data for the report is here.';
>
>

Если бы мы попытались запустить наш код, мы бы получили ошибки по следующим причинам:

  1. Пропущен метод getHeaders() .
  2. У метода getName() не задан тип возвращаемого значения. Но в сигнатуре метода интерфейса тип определён.
  3. У метода getData() задан тип возвращаемого значения, он не соответствует определённому в сигнатуре метода интерфейса.

Итак, что бы обновить UsersReport , для правильной реализации интерфейса DownloadableReport , нужно заменить его на следующий код:

class UsersReport implements DownloadableReport 

public function getName(): string

return 'Users Report';
>

public function getHeaders(): array

return [];
>

public function getData(): array

return ['The data for the report is here.'];
>
>

Теперь, когда оба класса отчётов реализуют один и тот же интерфейс, мы можем обновить ReportDownloadService следующим образом:

class ReportDownloadService 

public function downloadReportPDF(DownloadableReport $report)

$name = $report->getName();

// Download the file here.
>
>

Теперь мы можем передать объект UsersReport или BlogReport в метод downloadReportPDF() без каких либо ошибок. Потому что мы знаем, что необходимые методы нужные для классов отчёта существуют и возвращают данные ожидаемого типа.

В результате передачи интерфейса методу, а не классу, позволило нам слабо связать ReportDownloadService и классы отчётов в зависимости от того, что делают методы, а не от того, как они это делают.

Если бы мы захотели создать новый AnalyticsReport , мы могли бы заставить его реализовать тот же интерфейс, и это позволило бы нам передать объект отчёта в тот же метод downloadReportPDF() без необходимости добавлять какие-либо новые методы. Это может быть полезно, если вы хотите создать свой пакет или фреймворк, и хотите дать разработчику возможность создавать свой собственный класс. Вы можете просто сказать им, какой интерфейс реализовать, и они смогут создать собственный класс. Например, в Laravel вы можете создать собственный класс драйвера кэша, реализовав интерфейс Illuminate\Contracts\Cache\Store .

Помимо использования интерфейсов для улучшения актуального кода, мне нравятся интерфейсы, потому что они действуют как концепция «Документация — это код». Например, если я пытаюсь выяснить что может класс, а что не может, я обычно сначала смотрю на интерфейс, а затем на класс, который его реализует. Он сообщает вам все методы, которые могут быть вызваны, и не нужно заботиться о том, что у них под капотом.

Как заметили многие мои читатели Laravel-разработчик, довольно часто термины «контракт» и «интерфейс» используются как взаимозаменяемые. Согласно документации Laravel, контракты Laravel — это наборы интерфейсов, которые определяют основные сервисы предоставляемые фреймворком . Итак, важно помнить, что контракт — это интерфейс, но интерфейс необязательно является контрактом. Обычно контракт — это просто интерфейс, предоставляемый фреймворком. Для получения информации об использовании контрактов я рекомендую почитать документацию поскольку в ней хорошо разбирается то как их использовать и когда их использовать.

Вывод

Надеюсь, что прочитав эту статью вы получили краткий обзор того, что такое интерфейсы, как их использовать в PHP, об их преимуществах и использовании.

PHP: Интерфейсы vs Абстрактные классы

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

Готовимся к собеседованию по PHP: Всё, что вы хотели узнать об интерфейсах, совместимости сигнатур и не побоялись узнать

image

Интерфейсы, впервые появившись в PHP 5, давно уже заняли прочное место в объектно-ориентированной (или всё-таки правильнее «класс-ориентированной»?) части языка.

Казалось бы — что может быть проще интерфейса? «Как бы класс, но и не класс, нельзя создать экземпляр, скорее контракт для будущих классов, содержит в себе заголовки публичных методов» — не правда ли, именно такими словами вы чаще всего отвечаете на собеседовании на дежурный вопрос о том, что такое интерфейс?

Однако не всё так просто, как может показаться начинающему программисту на PHP. Привычные аналогии не работают, руководство по языку вводит вас в заблуждение, в коде таятся неожиданные «подводные камни»…

Три предыдущие части:

  • Готовимся к собеседованию по PHP: ключевое слово «static»
  • Готовимся к собеседованию по PHP: псевдотип «callable»
  • Готовимся к собеседованию по PHP: Всё об итерации и немного про псевдотип «iterable»

Что может содержать интерфейс?

Очевидно, что публичные методы, причем без реализации: сразу после заголовка (сигнатуры) метода следует закончить его точкой с запятой:

interface SomeInterface

Чуть менее очевиден (хотя и описан в мануале) тот факт, что интерфейс может содержать константы (разумеется, только публичные!):

interface SomeInterface < public const STATUSES = [ 'OK' =>0, 'ERROR' => 1, ]; > if (SomeInterface::STATUSES['OK'] === $status) < // . >

Почему же константы в интерфейсах не получили широкого распространения в промышленном коде, хотя и используются иногда? Причина в том, что их невозможно переопределить в интерфейсе-наследнике или в классе, реализующем данный интерфейс. Константы интерфейсов — самые константные константы в мире 🙂

Чего не может содержать интерфейс?

Больше ничего не может. Кроме заголовков публичных методов и публичных констант.

Нельзя включать в интерфейс:

  • Любые свойства
  • Непубличные методы
  • Методы с реализацией
  • Непубличные константы

Совместимость сигнатур методов

Для дальнейшего изучения интерфейсов нам с вами нужно узнать о важнейшем понятии, которое незаслуженно обойдено вниманием в мануале по PHP: о понятии «совместимости сигнатур».

Сигнатура — это описание функции (метода), включающее в себя:

  • Модификатор доступа
  • Имя функции (метода)
  • Список аргументов, где для каждого аргумента указано:

  • Тип
  • Имя
  • Значение по умолчанию
  • либо оператор «три точки»
function (); public function foo($arg = null); protected function sum(int $x, int $y, . $args): int; 

Предположим, что у нас есть две функции, A и B.
Сигнатура функции B считается совместимой с A (порядок важен, отношение несимметрично!) в строгом смысле, если:

Они полностью совпадают

Тривиальный случай, комментировать тут нечего.

B добавляет к A аргументы по умолчанию
function foo($x); 
function foo($x, $y = null); function foo($x, . $args); 
B сужает область значений A
function foo(int $x); 
// В A допускался возврат любых значений, в B эта область сужена только до целых чисел function foo(int $x): int; 

Теперь, когда мы ввели эти три простых правила совместимости определений, станет гораздо проще понять дальнейшие тонкости, связанные с интерфейсами.

Наследование интерфейсов

Интерфейсы могут наследоваться друг от друга:

interface First < public const PI = 3.14159; public function foo(int $x); >interface Second extends First < public const E = 2.71828; public function bar(string $s); >assert(3.14159 === First::PI); assert(true === method_exists(First::class, 'foo')); assert(3.14159 === Second::PI); assert(2.71828 === Second::E); assert(true === method_exists(Second::class, 'foo')); assert(true === method_exists(Second::class, 'bar')); 

Интерфейс-наследник получает от интерфейса-предка в наследство все определенные в предке методы и константы.

В интерфейсе-наследнике можно переопределить метод из родительского интерфейса. Но только при условии, что либо его сигнатура будет в точности совпадать с сигнатурой родительского, либо будет совместима (см. предыдущий раздел):

interface First < public function foo(int $x); >interface Second extends First < // Так можно, но бессмысленно public function foo(int $x); // Так нельзя, фатальная ошибка Declaration must be compatible public function foo(int $x, int $y); // Так можно, потому что эта сигнатура совместима с родительской - мы просто добавили необязательный аргумент public function foo(int $x, int $y = 0); // Так тоже можно, все аргументы после ". " являются необязательными public function foo(int $x, . $args); // И так тоже можно public function foo(int $x, . $args): int; >

Если ли в PHP множественное наследование?

Если вам зададут такой вопрос, смело отвечайте: «да». Интерфейс может наследоваться от нескольких других интерфейсов.

Теперь вы видели всё:

interface First < public function foo(int $x); >interface Second < public function bar(string $s); >interface Third extends First, Second < public function baz(array $a); >assert(true === method_exists(Third::class, 'foo')); assert(true === method_exists(Third::class, 'bar')); assert(true === method_exists(Third::class, 'baz')); 

Правила решения конфликтов сигнатур методов при множественном наследовании точно такие же, как мы уже видели выше:

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

Тонкости реализации интерфейсов

Собственно, после всего, что вы уже видели, это уже и не тонкости, а так, мелкие нюансы.

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

interface IntSumInterface < public function sum(int $x, int $y): int; >interface IntMultInterface < public function mult(int $x, int $y): int; >class Math implements IntSumInterface, IntMultInterface < public function sum(int $x, int $y): int < return $x + $y; >public function mult(int $x, int $y): int < return $x * $y; >> 

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

Как быть, если в разных интерфейсах, которые реализует класс, будет один и тот же метод (с одинаковым названием)? Смотри выше — также, как и при наследовании интерфейсов друг от друга должен соблюдаться принцип совместимости сигнатур.

И да. Не верьте мануалу, который провозглашает:

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

The class implementing the interface must use the exact same method signatures as are defined in the interface. Not doing so will result in a fatal error.

Всё не так, действует тоже самое правило совместимости:

interface SomeInterface < public function sum(int $x, int $y); >class SomeClass implements SomeInterface < public function sum(int $x, int $y): int или public function sum(int $x, int $y, int $z = 0): int или даже public function sum(int $x, int $y, . $args): int < // реализация метода >> 

Интерфейс — это класс? Pro et Contra

Вообще-то нет. Интерфейс — это интерфейс, он отличается от класса хотя бы тем, что нельзя создать «экземпляр интерфейса».

И вообще-то да, у них в PHP очень много общего:

  1. Интерфейсы, как и классы, могут находиться в пространстве имён.
  2. Интерфейсы, как и классы, можно загружать через механизм автозагрузки. Функции автозагрузки будет передано полное имя интерфейса (с пространством имён).
  3. В каждом интерфейсе есть предопределенная константа ThisInterface::class, содержащая его полное имя
  4. Интерфейс, как и класс, может участвовать справа в операторе instanceof
  5. Интерфейс, как и класс, может быть указан в качестве типа в тайп-хинтинге (указание типа аргумента либо возвращаемого значения функции)

Что почитать в ночь перед ответственным собеседованием?

Разумеется, мануал по языку:

  • php.net/manual/ru/language.oop5.interfaces.php
  • php.net/manual/ru/language.oop5.constants.php
  • php.net/manual/ru/language.constants.predefined.php

Системный подход к самообразованию в программировании очень важен. И, по моему мнению, неплохо в начале пути в IT помогают структурировать самообучение вебинары и краткосрочные курсы. Именно поэтому я рекомендую (и немного скромно рекламирую) даже опытным разработчикам посещать разовые вебинары и курсы повышения квалификации — результат при грамотном сочетании курсов и самоподготовки всегда налицо!

Успехов на собеседовании и в работе!

Для чего нужны интерфейсы в PHP.

В этой заметке, постараюсь, кратко, объяснить в каких случаях стоит использовать интерфейсы в PHP и привести пример практического их использования.

  • в базу данных;
  • в файл;
  • в сессию и др.

Для начала, давайте рассмотрим пример без использования интерфейса.

При создании приложения согласно ООП, нужно отделять логику от функционала, разбивая задачи на отдельные классы.
Допустим есть 3 класса:
— Date (общий класс, получающий данные и использующий методы вспомогательного класса(сервиса) для их сохранения);
— saveDb (класс сохраняющий данные в базу данных);
— saveFile (класс сохраняющий данные в файл)

class Date< //Db – класс сохраняющий данные в БД, $base – экземпляр этого класса public function date(saveDb $base)< $message = array(); //получение данных из формы $date = $this->validate($message); //валидация $base->insertInto(); //вызов методов класса Db для сохранения > public function validate($date) < //проверка данных return $date; >>

в данном примере, для сохранения данных, методу date() класса Date, в качестве аргумента, нужно передать экземпляр конкретного класса — saveDb или saveFile.

Недостаток данного подхода в том, что класс проверяющий данные и класс сохраняющий данные сильно связаны между собой. В примере, мы указываем, что аргумент метода date() — это экземпляр класса работающего с базой данных. Далее используются нужные методы данного класса (saveDb ) вроде insertInto().
А что, если понадобится сохранить данные не в БД, а в файл. В этом случае нужно будет менять весь метод date(), ведь у другого класса могут быть совсем другие методы, а не метод insertInto() и весь принцип построения другого класса может сильно отличаться. Может быть, там даже будет предусмотрена своя валидация и метод validate() класса Date окажется лишним.

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

interface Save < public function insert($date); >class saveDb implements Save < protected function connectDb()<>public function insert($date)< echo $date.' сохранено в БД 
'; > > class saveFile implements Save < protected function openFile()<>public function insert($date)< echo $date.' сохранено в файл
'; > protected function closeFile()<> > class saveSession implements Save < public function insert($date)< echo $date.' сохранено в сессию
'; > > //////////////////////////////////// class Date < public $date; public function __construct($date) < $this->date = $date; > // Save – интерфейс для сохранения данных, $obj – экземпляр одного из классов реализующих данный интерфейс. public function save(Save $obj)< $date = $this->validate($this->date); //валидация $obj->insert($date); //вызов методов класса Db для сохранения > public function validate($date) < // тут проверка данных return $date; >> $date = new Date('Контент'); $db = new saveDb(); $date->save($db); //Контент сохранено в БД $file = new saveFile(); $date->save($file); //Контент сохранено в файл $ses = new saveSession(); $date->save($ses); //Контент сохранено в сессию

В моем упрощенном примере видно, что интерфейс обязует реализующие его классы иметь метод insert(), который (допустим) непосредственно занимаются вставкой данных. А кроме него, каждый класс может иметь другие необходимые для его работы методы. Для класса saveDb, это, например, метод connectDb(), создающий соединение с базой данных. Для тестирования, я сделал вывод сообщений при срабатывании метода insert().

Таким образом, при работе с данными, в конструктор нужного класса или другой метод, мы можем передавать класс-сервис, указывая, что он относится к определенному интерфейсу и быть уверенными, что для всех классов данной группы используются одинаковые методы. Информацию про данные методы (документацию), кстати, можно указать прямо в коде интерфейса возле соответствующих методов, тем более, что там будет намного меньше строк чем в реализующих его классах.

В данном примере, вместо зависимости от конкретного класса (saveDb) передается зависимость от интерфейса Save:

public function save(Save $obj)

Код класса Date не зависит от конкретного реализатора, а только от интерфейса. Стоит отметить, что данный пример построен на базе паттерна «Dependency injection», что переводится как «внедрение зависимости».
Интерфейс обеспечивает наличие указанных в нем методов во всех классах которые его реализуют. Поэтому можно быть уверенным, что вызов метода insert():

$obj->insert($date);

приведет к сохранению данных. При этом место хранения зависит от реализации данного метода в каждом из классов. Так, метод insert() класса saveDb сохраняет в базу данных, метод insert() класса saveFile сохраняет в файл и тд. Выполните код данного примера и увидите, что класс Date отработал со всеми классами интерфейса Save и при этом, код самого класса Date никак не пришлось менять.

Автор: Сергей Дата публикации: 03.06.2017

  • Пример простого REST API на PHP.
  • Использование YouTube Data API для своего WEB-сервиса. Выборка нужных видеозаписей, получение информации.
  • Определение страны и города посетителя по его IP. Расширение GeoIP.
  • Установка, настройка и базовое использование фреймворка для тестирования «Codeception».
  • Основы PHPUnit — 1 часть.

Интерфейс PHP

В PHP ООП интерфейс — это класс, в котором все методы являются абстрактными и открытыми.

Быстро пробежимся по трем терминам, используемым в этом определении. Класс, абстрактный и открытый. Класс представляет собой шаблон или образец объекта, он является основой объектно-ориентированного программирования. Абстрактный — это специальный метод, который объявляется, но не имеет тела, только пустые скобки. Открытый — это модификатор доступа public , он связан с доступом к методам. Это означает, что он доступен из любого места: из этого класса, вне его пределов и из любого производного класса.

Интерфейс PHP представляет собой инструмент для создания надежного кода, определяющего методы, которые должны быть реализованы с помощью класса без определения обработки этих методов. Это мощная и простая концепция, используемая в объектно-ориентированном PHP . Для его создания используется ключевое слово interface , он определяется так же, как класс PHP . Методы, содержащиеся в нем, не имеют никакого функционала, но интерфейс задает, какие методы необходимы для других классов. Любой класс, наследующийся от интерфейса, должен содержать те же методы, которые содержатся в интерфейсе, иначе выдается ошибка.

В интерфейсе ООП PHP мы задаем только имена методов и их параметры, а реализованы они могут быть позже. Принято объявлять все методы интерфейса как public . Для реализации интерфейса используется ключевое слово implements . При необходимости класс может реализовать более одного интерфейса, между собой они разделяются запятой. Как и класс, интерфейс может содержать константы. Единственное отличие заключается в том, что они не могут быть переопределены в производном классе.

Определение и использование интерфейсов

Интерфейс определяется с помощью ключевого слова interface . Все методы в нем должны быть открытыми и абстрактными:

interface animal

Это пустой интерфейс. Мы добавим в него абстрактный метод motion . Таким образом, мы создадим простой PHP 5 ООП интерфейс, который может быть реализован позже:

interface animal < public function motion()<>>

Этот интерфейс может быть реализован любым классом animal , все классы animal будут содержать метод motion . Давайте рассмотрим пример. Для реализации интерфейса мы используем ключевое слово implements :

class Lion implements animal < public function motion() < // Задайте здесь функционал этого метода для класса lion >> class Fish implements animal < public function motion() < // Задайте функционал этого метода для класса fish >>

PHP-интерфейс и абстрактные классы

Интерфейсы и абстрактные классы очень похожи по своей концепции. Они помогают в создании шаблонов для классов, которые будут использоваться в приложении. Согласно основам ООП PHP , они отличаются друг от друга следующим:

  1. В интерфейсе все методы являются абстрактными ( без реализации ). В абстрактном классе лишь некоторые методы являются абстрактными. Абстрактный класс должен содержать, по крайней мере, один абстрактный метод. Иначе это будет стандартный класс PHP ;
  2. В интерфейсе PHP все объявленные методы являются открытыми, а в абстрактном классе методы могут быть открытыми, частными или защищенными. Следовательно, для интерфейсов существует ограничение на использование модификаторов доступа, а в абстрактном классе таких ограничений нет;
  3. Класс может реализовать неограниченное количество интерфейсов. В то же время класс PHP может породить только один абстрактный класс;
  4. Вы должны переопределять все методы интерфейса, а в абстрактном классе у вас есть выбор: переопределять методы или оставить их без изменений;
  5. Интерфейсы имеют более строгие правила, чем абстрактные классы. Интерфейс PHP призван обеспечить определенную логику, он выступает в качестве пустой оболочки или шаблона для других классов.

Для чего используются интерфейсы PHP

Интерфейс помогает программисту мыслить в правильном направлении. С точки зрения PHP ООП , класс представляет собой шаблон, а объект — это набор возможностей. Мы в большей степени связаны с функционалом, что он делает, а не как он это делает. Поэтому мы определяем основной интерфейс, который является общим, а затем он реализуется, что помогает мыслить в правильном направлении.

Корректировка кода в будущем

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

Лучшая структура программы

Объектно-ориентированный PHP был реализован для улучшения структуры создаваемых приложений. Добавление интерфейсов в PHP способствует тому, что кодирование становится аккуратным и чистым. Интерфейсы препятствуют написанию кода, который трудно поддерживать и изменять. С помощью интерфейсов мы можем легко поддерживать и модифицировать код, что повышает эффективность работы программистов.

Добавление всех важных функций

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

Еще один в ООП PHP пример реализации интерфейса

 ?> class Cake implements Recipe < public function methodology() < >>

В этом коде мы видим класс Cake , который реализует интерфейс Recipe .

Вадим Дворников автор-переводчик статьи « PHP interface »

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *