Почему в интерфейсе могут быть только public методы?

Question

[vrazbros]

Привет

Почему в интерфейсе могут быть только public методы, а не к примеру protected тоже ?

Comments

[vrazbros]

они так же задают контракт и методы все равно нужно будет реализовывать в классах который подключит интерфейс, так почему бы сразу не задать нужный уровень доступа ?

Answer 1

[Шамсудин Сердеров]

Для начало
Зайти и прочитайте PHP OOP

public - доступ открыт извне класса.
private - только из методов класса.
proteсted - доступ из методов произвольного класса.

P.S

class Example implements ExampleInterface
{
    /****
     * Я тебе везде пригожусь
    */
    public function test()
    {
        return $this->view();
    }
    
    /****
     * Я тебе нужен в этом классе, в другом месте хрен ты меня используешь.
     * 
     * @return string
    */
    protected function view()
    {
        return 'Привет ты меня использовал';
    }
}

interface ExampleInterface 
{
    public function test();
}

class InitExample 
{
    public function release(ExampleInterface $ex)
    {
        echo $ex->test();
    }
}

Answer 2

[Mercury13]

Private — на что? Ведь тот, кто пойдёт этот интерфейс реализовать, их не увидит.

С protected штука более сложная. Дело в том, что в классическом интерфейсе ноль кода и данных, и эти protected должен вызывать — кто — разумеется, потомки. Преждевременно увековечивать внутреннюю архитектуру — зачем?

Встречается ещё такая штука, как «прокачанный интерфейс» — не знаю, как он правильно называется по ООП. Там есть две новых вещи: 1) утилиты — невиртуальные функции, которые представляют собой стандартный сценарий пользования интерфейсом; 2) штатные реализации — некоторым виртуальным функциям придумывают реализацию, которая как-то работает и пользуется другими виртуальными, но потомок, если захочет, может написать более эффективную версию.

Вот например, утилита.

// write Intel word
void st::Stream::writeIW(uint16_t w)
{
    write(&w, sizeof(uint16_t));
}

Утилита не часть интерфейса, и лучший синтаксис для утилит — методы-расширители C#. На худой конец подойдёт простая функция типа Streams.writeIW(stream, 10);.

Вот, например, штатная реализация.

// Возвращает остаток потока
// cu_minus = clipped unsigned minus
virtual Pos remainder() { return cu_minus<Pos>(size(),pos()); }

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

Раз утилита пользуется обычными общедоступными функциями, нет никакого смысла её кидать в protected (теоретически private/protected могут быть некоторые части сложных утилит). Штатные реализации — тем более, это такая же часть интерфейса, как абстрактные size() и pos().

Answer 3

[SpyDeX]

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

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

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