Объекты контейнеры (Domain)

asm

Пофигист
Объекты контейнеры (Domain)

Есть нейкие объекты, содержащие только наборы данных, например класс пользователь:
PHP:
class User
{
	public $name     = "";
	public $login    = "";
	public $password = "";
}
Для доступа к свойству соответственно используем $user->name

Далее допустим пароль у нас хранится в MD5 потому мы получаем:

PHP:
class User
{
	public $name     = "";
	public $login    = "";
	private $password = "";
	public function setPassvors($value) {
		$this->password = md5($value);
	}
	public function getPassword(){...}
}
Соответственно для души пишутся функции для свойств name и login. Но теперь доступ к свойству $user->getName(), что уже не так удобно как $user->name, можно конечно прикрутить __set и __get, но тогда человеку незнакомому со структурой класса нужно лезть в документацию или что хуже в сам класс что бы узнать какие же там свойства есть у объекта...

А как делаете вы?
 

HraKK

Мудак
Команда форума
Это не только "удобно", но и правильно. А потом вам понадобится изменить login на emal и что? будете по всему проекту менять?

-~{}~ 25.10.07 14:16:

ЗЫ И никакая это не теория.
ЗЗЫ А вообще читайте умные книги.
 

zerkms

TDD infected
Команда форума
The Data Mapper Pattern очень хорошо себя показывает в работе. по крайней мере я уже очень привык (к нашей реализации)
 

asm

Пофигист
HraKK
Нет вы немного не поняли, вопрос стоит что лучше использовать методы __set и __get против getProperty и setProperty.

-~{}~ 25.10.07 14:20:

Плюсы: __set и __get заметное сокращение кода, минусы нет автокомплита.
У getProperty и setProperty все наоборот...
 

jonjonson

Охренеть
asm, __set и __get существуют, что бы код работы со свойствами разместить в одном месте. Если код этот практически одинаков, то выигрыш на лицо. Если же он больше 60 строк... То есть для каждого свойства свой алгоритм, то проще отписать свои методы доступа.
 

AmdY

Пью пиво
Команда форума
Если ты проверяешь формат имени, то нужна обёртка setName(), если ты делаешь md5 пароля, тоже нужна обёртка.
Засунуть это в один __set не получится без "доширака"
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
не понимаю смысла использования объектов с данными без методов
в подобных случаях я предпочитаю extends ArrayObject / implements ArrayAccess
а если нужно забирать данные после предварительной обработки - то вопрос сам собой отпадает
 

asm

Пофигист
AmdY
ну если у тебя 50 свойств и только 2-5 из них требуют обертки... Проще указать исключения в __set и __get чем плодить 100 методов доступа...

grigori
Нет ну есть некоторые методы, как то toString, pack, unpuck... Просто основная задача это предоставление данных определенной структуры.
Раньше тоже все хранилось в массивах, но захотелось получать данные фиксированной структуры, так удобнее как конечным пользователям так и при обработке ошибок, хотя такие объекты совсем не исключают наследования и прочих вкусностей ООП.

В принципе вопрос исчерпан... Хотелось найти универсальность...
 

Frol

Новичок
ну если у тебя 50 свойств и только 2-5 из них требуют обертки... Проще указать исключения в __set и __get чем плодить 100 методов доступа...
проще повеситься.

вышло красивое завершение умной темы. ;]
 

AmdY

Пью пиво
Команда форума
Автор оригинала: asm
AmdY
ну если у тебя 50 свойств и только 2-5 из них требуют обертки... Проще указать исключения в __set и __get чем плодить 100 методов доступа...
Блин, нужно же быть гибче, а не пороть "либо так, либо вот так, третьего не дано". А кто мешает для специфических свойст написать свои методы, а для остального обрабатывать в __set, Alexandre был прав насчёт архитектуры
 

Pigmeich

Новичок
asm
Рихтер как-то написал: я не понимаю классов с public полями.

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

Остюда простое правило: если данные при обработке не изменяются и идут напрямую в поля, то очень хорошо смотриться __set и __get. Наоборот - используем методы.
 

asm

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

В любом случае я использую setProperty и getProperty, удобство последующего использования пересилило природную лень, жаль что Zend не предоставляет возможностей их генерировать.

AmdY
Да это тоже вариант, но не решает вопрос автокомплита для свойств установленных в __set что при таком количестве свойств более критично на мой взгляд.

Pigmeich
Никто и не говорит про классы с public полями.

-~{}~ 30.10.07 11:12:

Alexandre
А что вы можете предложить взамен? Если данные приходят из хранилища не контролируемого мной... Та же информация о пользователе имеет 34 свойства, разбита на три части, но конечному пользователю нужна вся? Я всего лишь получаю информацию, разбиваю ее и отдаю.

-~{}~ 30.10.07 11:18:

P.S. Мне действительно хочется улучшить свою разработку, буду рад критике.
 

Pigmeich

Новичок
asm
Ну у проблемы есть три решения:
1. public field
2. set/get overload
3. set/get methods

надо было выкинуть первое.
 

AmdY

Пью пиво
Команда форума
Автор оригинала: asm
Да это тоже вариант, но не решает вопрос автокомплита для свойств установленных в __set что при таком количестве свойств более критично на мой взгляд.
Фига се, -1 в голосовании за нормальную IDE, если логика класса строится под автокомплит, то это маразм.
Могу предложить костыль, но не буду, ибо нефик.
 

asm

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

AmdY

Пью пиво
Команда форума
Соглашусь, но это не самоцель, приятно писать хороший код, а автокомплит это приятное дополнение.
 
Сверху