Объектно-ориентированное программирование: понимание интерфейсов

Последнее обновление Ноя 21, 2022

Содержание

На данный момент я бы сказал, что основы понимания объектно-ориентированного программирования заложены.

В частности, я рассмотрел:

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

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

Во всяком случае, следующие две темы, которые важно понять:

Интерфейсы
Абстракция

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

Неясно, я знаю, но позвольте мне объяснить, а затем идти оттуда.

Понимание интерфейсов

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

Например, когда вы думаете о контрактах, вы, вероятно, думаете о чем-то очень сложном, с большим количеством жаргона, о сложном процессе подписания, даты, готовности к работе и так далее.

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

Несколько слов об «интерфейсах»

В нашей отрасли слово «интерфейс» используется для обозначения двух вещей:

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

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

Программирование для интерфейса

Мы определяем «программирование для интерфейса» как способ написания кода, который реализует сигнатуры функций, определенных в указанном интерфейсе.

Но что такое сигнатуры методов? Проще говоря, сигнатуры методов включают в себя:

имя имени функции,
аргументы, которые он принимает,
модификатор видимости

В контексте класса вы увидите это так:

<?php

class Cache 
{
  public function set($key, $value) 
  {
    // method implementation
  }
}

Легко, верно?

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

Но интерфейсы также могут включать это. Однако есть одно предостережение: интерфейсы не имеют реализации методов.

Так что, а не что- то вроде этого:

<?php

class Cache 
{
  public function set($key, $value) {
    set_transient($key, $value);
  }
}

Вы увидите это:

<?php

interface iCache 
{
  public function set($key, $value);
  public function get($key);
  public function has($key);
}

Но в приведенном выше коде также есть пара тонкостей, на которые стоит обратить внимание.

Этот код не определяет его как класс. Вместо этого он называет это интерфейсом.
Имя класса имеет префикс «i», чтобы указать, что это интерфейс. Это не требуется; это условность.
Метод не имеет реализации. В нем нет ничего, кроме подписи.

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

Итак, если бы мы связали все, что мы видели выше, окончательная реализация выглядела бы так (хотя в идеале мы бы сохранили это в отдельных файлах):

<?php

interface iCache {
  public function set($key, $value);
  public function get($key);
  public function has($key);
}

public class SimpleCache implemnents iCache
{
  public function set($key, $value)
  {
    set_transient($key, $value, DAY_IN_SECONDS);
  }

  public function get($key)
  {
    if (!$this->has($key))
    {
      return false;
    }
    return get_transient($key);
  }

  public function has($key)
  {
    return false !== get_transient($key);
  }
}

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

Это оно?

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

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

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

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

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

Если вы разработчик WordPress и хотите научиться создавать вещи поверх приложения, используя практичные объектно-ориентированные методы, то почему бы не присоединиться к сайту?

Источник записи: tommcfarlin.com