Разные интерфейсы, одинаковые методы

[hell0w0rd]

Lionishy, окей. Тебе зачем вообще интерфейс нужен?

 

[accido]

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

Можно открыть окно, а можно открыть новый корпус. И хотя оба интерфейса содержат метод "открыть" они вообще никак не связаны, однако может появится объект, который должен и окно открывать, и новое здание.

раз нет полиморфизма значит делегируй, как тебе посоветовали выше, создай list[], то что у них совпадают имена методов вообще не имеет значения

 

[Lionishy]

Господа, вы прям загадками говорите.

hell0w0rd, вопрос из разряда: "зачем нужны числа?".
Я даже теряюсь, что ответить. Я действительно не понимаю какого ответа Вы от меня ждёте.

Могу предложить краткий вариант проектно-ориентированного определения: "Модель сущности, доступная клиентам абстракции".


accido,

значит делегируй

Кто, кого и куда должен делегировать?

Пример riff не решает поставленной задачи, потому что методы IResolveDog::resolve и IResolveCat::resolve это два совершенно разных метода. Они означены разным целям, они делают разное. Интерфейсы не полиморфны, они разные.

Я уже столько примеров привёл. Ещё один приведу.
Есть радиоприёмник ОКЕАН, у него на передней панели есть ТакаяЧёрнаяРучка(КрутиМеня). Она изменяет частоту приёмного контура.
Есть усилитель Yamaha, у него на передней панели есть ТакаяЧёрнаяРучка(КрутиМеня). Она изменяет выходную мощность.

И вот, делаем мы радиоприёмник с усилителем, чтобы радио усиливать. И у нас на передней панели появляются две ТакаяЧёрнаяРучка(КрутиМеня). Эти ручки совершенно идентичный интерфейс! Но они делают совершенно разные вещи. И в разные моменты времени я воспринимаю своё устройство либо как приёмник, либо как усилитель. Но это одно устройство, которое не представляет ценности, если его разорвать.

 

[accido]

ну так сделайте catList[], dogList[] end profits

 

[Lionishy]

accido, а как я узнаю, какой мне сейчас вызвать *List? Попытка узнать, вызывают меня как IResolveDog или как IResoveCat сама по себе является плохой идеей. Но даже если пытаться такой костыль организовать, думаю, что в разумных целях, такая возможность в PHP отсутствует.
Хотя, если она всё же есть, то поделитесь =]

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

 

[riff]

И вот, делаем мы радиоприёмник с усилителем, чтобы радио усиливать. И у нас на передней панели появляются две ТакаяЧёрнаяРучка(КрутиМеня). Эти ручки совершенно идентичный интерфейс! Но они делают совершенно разные вещи. И в разные моменты времени я воспринимаю своё устройство либо как приёмник, либо как усилитель. Но это одно устройство, которое не представляет ценности, если его разорвать.

accido, По идее у него должно было быть две ручки - одна громкость, вторая мощность (два интерфейса), но он сделал приёмник с одной ручкой (одно название функции) и теперь думает как заставить приёмник угадывать зачем он повернул ручку

 

[WMix]

сходи туда, не знаю куда!

 

[Вурдалак]

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

ООП требует проработки модели, очень важно уделять время именованию. Не должно быть монстроузорных объектов. Не должно быть несколько методов resolve(): если он есть и называется так, значит объект — какой-то вполне определённый резолвер и неоднозначности нет. Если их несколько, то ты нарушаешь SRP и идёшь в жопу.

 

[hell0w0rd]

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

 

[Lionishy]

hell0w0rd,

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

.

Вот это: "возникает необходимость переопределять их (интерфейсы?)" -- совсем ставит в тупик. Что есть переопределение интерфейса? Декорирование? Перегрузка методов? Полиморфизм?

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

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

 

[Redjik]

interface IReslover
{
    public function resolve();
}

interface ICat extends IResolver
{
}

interface IDog extends IResolver
{
}

Чо еще надо то?

 

[Lionishy]

Redjik, выше уже была дискуссия на этот счёт. Резюме: это не решение.

 

[Redjik]

Соглашусь с народом - хренью занимаешься.

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

Тут стартегия тупо.

 

[Lionishy]

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

Соглашусь с народом

Это печально. "Народ" далеко не всегда прав.

 

[флоппик]

Lionishy, ну да, ты то знаешь, какое оно, правильное ООП. И все остальные не понимают твоего величия

 

[Lionishy]

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

 

[флоппик]

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

 

[флоппик]

Вообще, похоже (особенно учитывая постоянные отсылки к плюсам), то та проблема, которую ты пытаешься описать, называется так: http://ru.wikipedia.org/wiki/Ромбовидное_наследование

Там же написано, почему для пхп этой проблемы нет по определению, что и пытаются тебе объяснить участники форума.

 

[Redjik]

interface IEntity
{
    /**
    * @return string
    */
    public function getColor();

    /**
    * @return mixed
    */
    public function getWeight();
}

interface IResolver
{
    /**
    * @param IEntity $entity
    * @return mixed
    */
    public function resolve(IEntity $entity);
}




class Cat implements IEntity
{

    /**
    * @return string
    */
    public function getColor()
    {
        return 'red';
    }

    /**
    * @return mixed
    */
    public function getWeight()
    {
        return 2600;
    }
}

class WeightResolver implements IResolver
{

    /**
    * @param IEntity $entity
    * @return mixed
    */
    public function resolve(IEntity $entity)
    {
        return $entity->getWeight();
    }
}

$cat = new Cat();
$resover = new WeightResolver();
$resover->resolve($cat);

 

[Вурдалак]

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