PHP: как повторно использовать код (oop)?

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

Поэтому, если ваш метод что-то делает с классом template , проверка объекта template экземпляра будет жестко закодировать зависимость от этого класса. Но на самом деле вам все равно, какой класс вы получаете, вам просто все равно, придерживается ли он интерфейса iTemplate (так как это все, что вы звоните в любом случае).

 public function foo(Template $template) { 

против:

 public function foo(iTemplate $template) { 

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

Если бы вы создали набор классов для птиц, вы могли бы подойти к нему с наследованием и без него. Давайте посмотрим, как мы можем это сделать:

 interface iBird { public function fly(); public function speak(); public function swim(); public function walk(); } class Duck implements iBird { public function fly() { //Fly here } public function speak() { // Quack here } public function swim() { //Swim here } public function walk() { //Walk here } } class Turkey implements iBird { public function fly() { //Fly here, but limited } public function speak() { //Make turkey sound here } public function swim() { throw new Exception('Turkeys can not swim!'); } public function walk() { //Walk here } } 

Теперь это простой пример, но вы можете видеть, что у этих двух птиц функции walk() , вероятно, будут одинаковыми (и, следовательно, нарушают DRY) …

Посмотрим, как это выглядит с одноуровневым наследованием:

 abstract class Bird implements iBird { public function fly() { //Fly here } abstract public function speak(); public function swim() { //Swim here } public function walk() { //Walk here } } class Duck extends Bird { public function speak() { //Quack here } } class Turkey extends Bird { public function speak() { //Make turkey sound here } public function swim() { throw new Exception('Turkeys can not swim!'); } } 

Теперь вы можете видеть, что мы просто повторно использовали 3 метода! Мы не объявляли speak() , так как оно всегда будет чрезмерно (так как ни одна из двух птиц не похожа).

Звучит неплохо? Ну, в зависимости от наших потребностей, мы можем захотеть добавить другие абстрактные типы. Так что давайте скажем, что у нас было много разных видов птиц … У нас были бы некоторые, которые не плавали, поэтому мы могли бы создать абстрактный класс NonSwimmingBird который расширяет Bird , но выдает нам исключение. Или NonFlyingBird , или ShortRangeBird …

Теперь мы действительно находимся на пути к повторному использованию кода, но мы ударяем о стену в другую область. Предположим, у нас есть птица, которая не летает и не плавает. Какой класс мы наследуем? В любом случае, мы дублируем код. Поэтому нам нужно найти другой выход. Ну, как мы это сделаем? Через шаблоны проектирования … Вместо прямого наследования мы могли бы использовать шаблон декоратора, чтобы добавить эти черты «на лету». (Существуют и другие шаблоны, которые можно использовать здесь, и нужно показать, что наследование само по себе не устраивает всех потребностей. И шаблоны сами по себе тоже не будут. Вам нужна хорошая архитектура, использующая оба мира на основе ваших точных потребностей) …

Дело в том, что все зависит от ваших потребностей. Если у вас есть только 2 «класса» объектов, которые вы собираетесь архитектовать гораздо проще, чем если бы вы планировали иметь тысячи. Пункт того, что я написал здесь, состоит в том, чтобы продемонстрировать, как вы можете использовать прямое наследование для принудительного исполнения некоторых СУХИХ принципов (но также и то, как прямое наследование может вызвать дублирование кода). Главное, не пытайтесь придерживаться DRY только потому, что вы не хотите повторять себя. Придерживайтесь DRY, но убедитесь, что вы объединяетесь и расширяетесь там, где это разумно, иначе вы создаете себе головную боль обслуживания. Придерживайтесь Принципа единственной ответственности , и вы должны быть в порядке …

Интерфейс записывает только 1 раз в начале разработки. И только после этого пишет другие классы, реализующие этот интерфейс. Интерфейс – это основа. Примечание: метод setVariable не требуется. В PHP есть хорошие магические методы: __get() и __set() .

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

 interface iPlugin { public function init(); /* .. */ } 

и все плагины будут реализовывать этот интерфейс. Менеджер плагинов тогда мог бы легко проверить, реализует ли плагин интерфейс и вызывает на нем метод init ().

Код не должен быть OO для повторного использования, хотя во многих случаях это помогает.

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

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

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

Часто код, который не начинал «намереваться» для повторного использования, оказывается тем, что вы захотите повторно использовать. Как правило, код запускается «inline», а затем вы обнаруживаете, что вам нужно делать точно или почти точно одно и то же в нескольких местах. Когда вы копируете и вставляете код, пришло время реорганизовать его как функцию.

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

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

Повторное использование объектно-ориентированного программирования – это использование предыдущего класса или функции или метода в данном классе, но не проблема предыдущего класса.