Модификаторы доступа в интерфейсах

[StUV]

т.е. я бы использовал instanceof в случаях динамических зависимостей на типах:

interface ISome {...}
class C implements ISome {...}
class C1 extends C {...}
class C2 extends C {...}

...
function someFunc(ISome $obj)
{
...
 if ($obj instanceof C1) {...}
 if ($obj instanceof C2) {...}
...
}

но проверка типа входного параметра должна быть на уровне языка (если проверка нужна)

++
в реале я и такое не использую - так как код по возможности дожен быть прозрачен относительно понимания текущего типа переменной - иначе дебаг будет невыносимым

к тому же сам по себе instanceof в некотором смысле рушит основы ОО-структур - т.е. в данном примере мы статически связываем входной параметр с некоторым типом - фактически то что внутри IF должно быть внутри метода класса справа от instanceof

 

[CRL]

Автор оригинала: berkut
public function __construct(IInput $io)
просто красивее)
и читается легче - сразу всё ясно. и автокомплит в редакторах его показывает

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

function __construct($storage)
{
            if(($storage instanceof IStorage) === false)
            {
                $this->error_handler("");
            }
            $this->storage = $storage;
}

и далее

private function error_handler($error_msg)
{
           //    загружаю xml-шаблон страницы сообщения об ошибке и вставляю в него $error_msg
            exit();
}

Это, конечно, не страхует от ошибки в работе самого обработчика ошибок, но при таком подходе можно унифицировать страницу сообщений об ошибке.

 

[Wicked]

StUV

по-моему, это просто нерабочий код - т.е. ошибка уровня "до тестирования" - не то чтобы продакшна

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

а ексепшны - они для ошибок логики приложения, но никак не семантики

Почему нет? В питоне, например, конкатенация строки и инта порождает exception. Вызов несуществующего метода - тоже.

 

[StUV]

вот-вот
гибкость пхп - это его как плюс, так и дикий минус... - при чтении такого кода сразу возникает вопрос
"а какого хрена и ваще откуда в конструктор может прийти не_инстансоф_istorage ?"

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

тогда и все эти "пляски" нафик не нужны

-~{}~ 29.05.08 12:47:

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

и да - ошибок такого рода точно не должно быть на продакшне

у тебя на продакшене не бывает подобного рода ошибок, которые не отловили при тестировании?

как я выше отметил - у меня такие ошибки не доходят до тестирования

 

[CRL]

Автор оригинала: StUV
при чтении такого кода сразу возникает вопрос
"а какого хрена и ваще откуда в конструктор может прийти не_инстансоф_istorage ?"

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

 

[StUV]

резонно написать код, в котором прозрачен ответ на вопрос "что здесь дОлжно быть"

ты же когда делаешь $id = $obj->getId();
потом не пишешь if (!is_int($id) { throw ...;}

или пишешь ?

или в getId - if (!...) throw; return id; - ?

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

-~{}~ 29.05.08 13:03:

ну и

например, я знаю интерфейс

вот и я про что
в случае some(ISome $obj) - _я_знаю_интерфейс_
в случае some($obj) { if (!instanceof) ... } - _я__НЕ_знаю_интерфейс_

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

 

[CRL]

Автор оригинала: StUV
резонно написать код, в котором прозрачен ответ на вопрос "что здесь дОлжно быть"

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

 

[rotoZOOM]

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

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