Ну если придираться к словам, то у класса могут быть constants (константы), members (члены, переменные), methods (методы), а все вместе они - class properties - т.е. свойства класса, которые его и определяют.---------- Добавлено 07.06.2013 в 14:17 ----------Константа - не свойство объекта, а свойство класса.
А я и не претендую на то, что озвучил истину во всех инстанциях :) Мой совет по использованию private-свойств относится к конкретной проблеме, которую озвучил ТС:
Если применить озвученный мной подход, то можно быть уверенным, что экземпляр класса содержит корректное значение свойства и можно не беспокоиться, вызывая методы, работающие с ним.---------- Добавлено 07.06.2013 в 13:43 ----------
Боюсь, ТС работает с user input, поэтому константы тут не помогут.
Хотя формально
и есть определение константы класса.
Да, такое свойство должно иметь модификатор доступа private (или protected, если есть классы-потомки, которые работают с этим свойством) и чтение его значения извне должно осуществляться с помощью public-геттера.
Публичное свойство по определению нельзя защитить от прямых изменений - на то оно и публичное, что каждый может его читать и изменять.
Простая глобальная функция (function isId($input) { ... }) будет видна из любой точки скрипта, если будет несколько таких функций, можно сделать их статическими методами какого-либо класса:
class Validator { static final public function isId($input) { ... } static final public function isEmail($input) { ... } ...}
, но это не панацея, потому что вместо кучи проверок типа is_numeric(), !empty() и т.п. вы будете писать кучу проверок типа Validator::isId(). Это немного сократит код, но не устранит проблему. Нужно изолировать данные и делать доступ к ним контролируемым, для этого (в т.ч.) и была придумана инкапсуляция.
Цивильное отображение - это уровень View, а валидация - уровень модели. Вьюхе, грубо говоря, все равно, как происходит проверка данных, ей важно получить список сообщений об ошибках и инструкции, куда их вставлять. А как был сформирован этот список - через исключения, возвращение false или прямым инжектом в какой-нибудь инстанс-коллектор сообщений - View может, точнее должен, не знать.
Я привел в пример класс, который реализует паттерн ValueObject. Для таких классов нет смысла создавать инстанс с заведомо неправильным значением какого-либо поля, поэтому бросание исключение там вполне уместно.
Валидация данных в модели крайне желательна, поскольку с одной и той же моделью может работать несколько контроллеров и в каждом потребуется делать валидацию, если этого не будет делать модель, а это дублирование кода со всеми вытекающими.---------- Добавлено 07.06.2013 в 00:49 ----------
Вот тут вы ошибаетесь. Если public-сеттер работает с private переменной, он содержит логику валидации значений для этой переменной и существует соглашение о том, что извне задать значение переменной класса можно только с помощью этого метода, то получается единая точка ввода, которая гарантирует, что данная переменная всегда будет иметь корректное значение (или не иметь его вовсе, т.е. быть null). Такой подход очень распространен в серьезных приложениях/фреймворках. Если вы посмотрите в исходный код ZF, Symfony, Yii и т.п., то обязательно увидите примеры таких сеттеров. Самый упрощенный пример - это сеттер с type hint'ом для аргумента, где type hint как раз служит валидатором. Думаю, таких примеров можно найти предостаточно в любом "неговнокоде" на PHP.
Тогда нужно сделать public setter-метод, запрограммировать в нем валидацию и использовать его в конструкторе для установки значения переменной класса.
Если значение переменной класса критично для функционирования всего класса, то да, я реально так делаю. Пример кода:
class Core_Dns_Mx_Route { /** * Hostname * * @access private * @var string */ private $_host; /** * Class constructor * * @access public * * @param string $host * @param int $priority * @param int $port * * @throws Core_Dns_Exception * @return Core_Dns_Mx_Route */ public function __construct($host, $priority = 10, $port = 25) { if (!Zend_Validate::is($host, 'Hostname', array('allow' => Zend_Validate_Hostname::ALLOW_DNS + Zend_Validate_Hostname::ALLOW_IP + Zend_Validate_Hostname::ALLOW_LOCAL))) { throw new Core_Dns_Exception( escsprintf(_("MX hostname '%s' is invalid. It should be either valid DNS hostname or valid IP address"), $host) ); }
А что вы предлагаете дальше делать с тру/не тру?
движок аукционов phpprobid (платный)
Попробую свои непрокачанные навыки телепата...
SELECT * FROM `statti` WHERE `title` LIKE '%запрос%'
Предварительно нужно убедиться, что используемые кодировки совпадают.
Чтобы быть спокойным относительно переменных класса, их нужно делать private и задавать значения только через конструктор и только там делать валидацию. Если валидация не проходит, то конструктор должен бросать исключение. Для правильной валидации существуют такие библиотеки, как, например, Zend Validate - поначалу использование таких решений может выглядеть избыточно, но когда набивается достаточно шишек на собственных велосипедах, приходишь к выводу, что ничего особо лишнего на самом деле там нет.
