ZendFramework соглашения PHP о проверке параметров функции/метода

[Lionishy]

Добрый день!

Хочу узнать у практикующих PHP программистов,
как принято организовывать проверку входящих параметров функции/метода.

#before call client reliable contract

ParametersCheck("namespace\SomeClass::someMethod",$string,$int,$interface);
->someMethod($string,$int,$interface);

#inside call exceptional contract

public function someMethod($string,$int,$interface) {
   if( !check($string,$int,$interface) )
        throw new \ErrorException(<some message>);
}

Сам я на PHP мало программировал, но нужно программистам, с которыми я работаю, тон приличия, чтобы нас другие понимали.

Спасибо!

 

[С.]

как принято организовывать проверку входящих параметров функции/метода

Проверку на что?

 

[Lionishy]

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

 

[A1x]

Возможно это - http://ua2.php.net/manual/ru/function.assert.php

 

[Вурдалак]

Type hinting. А вот скалярные типы (string, int, ...) обычно не проверяют, ну или exception, да.

 

[AmdY]

Lionishy
в php в первую очередь нужно стараться привести параметры к нужному типу, а затем делать проверку.

 

[Lionishy]

A1x, Вурдалак
А кто производит проверку? Клиент или поставщик? Всё же, принято assert или exception?

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

AmdY
То есть, параметры, пришедшие в функцию, приводятся принудительно к нужному типу, а затем используются уже для обыкновенной проверки на область определения?

#

/**
 * @param string $string
 * @param int $int
 * @param ns\IInterface $interface
 * @throws SomeException 
 */
public function someMethod($string,$int,$interface) {
    $string = (string)$string; $int = (int)$int; $interface = (ns\IInterface)$interface;
    if( <smth> )
       throw new SomeDerivedException();
}

P.S. Дело в том, что я очень слабо ориентируюсь в конструировании на PHP. Тем паче в каких бы то ни было соглашениях. Хотелось бы узнать именно практические способы, которыми люди пользуются и которые PHP конструкторы узнают сразу, а не ругаются и не рефакторят.

 

[AmdY]

Lionishy
интерфейс можно проверять через тайпхинт, а остальные лучше приводить, затем проверять как можно ближе к месту где они используются. Как правило удобнее пользоваться сервисным классом для валидации.
неймспейс лучше полностью не писать, а указать в начале в разделе
use NamespaceName; // \NamespaceName\InterfaceName далее указываем как просто InterfaceName без \

public function someMethod($string,$int,InterfaceName $interface) {
    $string = (string)$string; $int = (int)$int;
    $oValidator = new Validator();
    $oValidator->validateEmpty($string, 'Поле "строка" не лдолжна быть пустой');
    if ($oValidator->isValid()) 
   
}

 

[AmdY]

а лучше посмотри сам на примере валидации форм в ZF
http://framework.zend.com/manual/ru/zend.form.quickstart.html

 

[Lionishy]

AmdY
Спасибо!
Кажется я понял.

По-возможности ставим TypeHint, а остальные типы принудительно преобразуем.

валидации форм в ZF

Спасибо, но вот я хотел именно о вопросе корректности контракта более низкого уровня, между клиентом и поставщиком при делегировании.