-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Не пойму, в чем удобство такого метода написания кода
- Автор темы Leonid
- Дата начала
itprog
Cruftsman
> Простите, конечно, но как бы я не любил PHP и сколько я бы на ней не писал
тут я могу только сказать хороший программист пишет хороший язык на любом языке. То ты говоришь что хочешь обменяться опытом, то что тебе всеравно какой у тебя код.
Я не считаю это бредом. Длинный метод/функция тяжело читается, его трудно понять просто взглянув на него. Попробуй прочитать сверху вниз код triumvirat-а, потом закрыть его и сказать всё то, что он делает. Я потратил 10 минут чтобы понять его целиком."Требуют большего числа строк" - так никто не запрещает. Это рекомендация, вполне обоснованная. Маленькое - прекрасное. Выдели он класс для работы с куками/реквестами, метод для сборки параметров поиска, редирект в отдельный метод, заменил бы установку переменных в вид на обычный массив - у него вышел бы замечательный и понятный код. Без лишних деталей.
Стиль читабельный. Но код нет. run() делает слишком много вещей. Скорее всего автор его даже не пытался рефакторить, а как всегда, написав его, переключился на другие части.
> "Не умеешь работать иди учи"
Учить и консультировать это разные вещи. Учат в школах и университетах, а когда к тебе приходят реальные компании за тренингом - это уже бизнес, а не преподавание.
> 150 символов длинна строки - почему?
Почему в книгах строки обычно в среднем 100 знаков? Потому, что так удобнее читать.
> что тогда получится?
http://govnokod.com/3448
и то мне далеко до 150 (максимально 118 с пробелами)
И мне нравится идея выделять всё в функции, даже если сейчас мы вызываем ее только один раз. Это добавляет ясность в код и не отвлекает деталями. Для сравнения:
и
тут я могу только сказать хороший программист пишет хороший язык на любом языке. То ты говоришь что хочешь обменяться опытом, то что тебе всеравно какой у тебя код.
Я не считаю это бредом. Длинный метод/функция тяжело читается, его трудно понять просто взглянув на него. Попробуй прочитать сверху вниз код triumvirat-а, потом закрыть его и сказать всё то, что он делает. Я потратил 10 минут чтобы понять его целиком."Требуют большего числа строк" - так никто не запрещает. Это рекомендация, вполне обоснованная. Маленькое - прекрасное. Выдели он класс для работы с куками/реквестами, метод для сборки параметров поиска, редирект в отдельный метод, заменил бы установку переменных в вид на обычный массив - у него вышел бы замечательный и понятный код. Без лишних деталей.
Стиль читабельный. Но код нет. run() делает слишком много вещей. Скорее всего автор его даже не пытался рефакторить, а как всегда, написав его, переключился на другие части.
> "Не умеешь работать иди учи"
Учить и консультировать это разные вещи. Учат в школах и университетах, а когда к тебе приходят реальные компании за тренингом - это уже бизнес, а не преподавание.
> 150 символов длинна строки - почему?
Почему в книгах строки обычно в среднем 100 знаков? Потому, что так удобнее читать.
> что тогда получится?
http://govnokod.com/3448
и то мне далеко до 150 (максимально 118 с пробелами)
И мне нравится идея выделять всё в функции, даже если сейчас мы вызываем ее только один раз. Это добавляет ясность в код и не отвлекает деталями. Для сравнения:
PHP:
if (!$category->getId())
$redirect = new Base_Redirect();
$redirect->setHeader('action_failed');
$redirect->setType('alert');
$redirect->setMessage('element_does_not_exist');
$redirect->setRedirectUrl(array($this->getRequest()->getRequest()->getUriParts(0)));
return $redirect;
}
PHP:
if (!$category->getId())
return $this->elementDoesNotExistRedirect();
cDLEON
Я совсем не хотел это тролить, но мне упорно доказывают, что 20 и не больше, уже второю страницу, меня это дико возмущает, даже не знаю почему...
-~{}~ 29.10.10 00:55:
> И мне нравится идея выделять всё в функции
...
> if (!$category->getId())
Метод и функция две разных вещи, когда эти вещи не дифференцируются, это говорит о многом.
Точно! Очень правильно вставлять сеттеры для объекта в некий другой метод текущего объекта *sarkazm ... Я когда подобный код дебажить буду, с ума сойду...
Я совсем не хотел это тролить, но мне упорно доказывают, что 20 и не больше, уже второю страницу, меня это дико возмущает, даже не знаю почему...
-~{}~ 29.10.10 00:55:
> И мне нравится идея выделять всё в функции
...
> if (!$category->getId())
Метод и функция две разных вещи, когда эти вещи не дифференцируются, это говорит о многом.
Код:
if (!$category->getId())
$redirect = new Base_Redirect();
$redirect->setHeader('action_failed');
$redirect->setType('alert');
$redirect->setMessage('element_does_not_exist');
$redirect->setRedirectUrl(array($this->getRequest()->getRequest()->getUriParts(0)));
return $redirect;
}
и
if (!$category->getId())
return $this->elementDoesNotExistRedirect();
itprog
И еще, маленькая ремарка...
В контексте ООП код
if (!$category->getId())
$redirect = new Base_Redirect();
$redirect->setHeader('action_failed');
$redirect->setType('alert');
$redirect->setMessage('element_does_not_exist');
$redirect->setRedirectUrl(array($this->getRequest()->getRequest()->getUriParts(0)));
return $redirect;
}
Правильнее, чем этот ниже...
if (!$category->getId())
return $this->elementDoesNotExistRedirect();
-~{}~ 29.10.10 01:03:
fixxxer
>> $this->getRequest()->getRequest()
Я тоже не могу понять, что это такое )))
И еще, маленькая ремарка...
В контексте ООП код
if (!$category->getId())
$redirect = new Base_Redirect();
$redirect->setHeader('action_failed');
$redirect->setType('alert');
$redirect->setMessage('element_does_not_exist');
$redirect->setRedirectUrl(array($this->getRequest()->getRequest()->getUriParts(0)));
return $redirect;
}
Правильнее, чем этот ниже...
if (!$category->getId())
return $this->elementDoesNotExistRedirect();
-~{}~ 29.10.10 01:03:
fixxxer
>> $this->getRequest()->getRequest()
Я тоже не могу понять, что это такое )))
itprog
Cruftsman
Активист
кто доказывает? я сказал что все профессиональные программисты говорят что правильнее когда много коротких функций, привел цитату.
>Метод и функция две разных вещи
когда в пхп уберут ключевое слово 'function' из определения метода тогда и будем дифферинцировать %) Методы, процедуры, функции должны быть как можно меньше (меньше 20 при возможности). Лучше?
PS: и никто не будет твой assembly рефакторить. Системное программирование оно другое, и читаемость там на последнем месте.
-~{}~ 28.10.10 20:04:
> Правильнее, чем этот ниже...
чем? хочется услышать аргументы
кто доказывает? я сказал что все профессиональные программисты говорят что правильнее когда много коротких функций, привел цитату.
>Метод и функция две разных вещи
когда в пхп уберут ключевое слово 'function' из определения метода тогда и будем дифферинцировать %) Методы, процедуры, функции должны быть как можно меньше (меньше 20 при возможности). Лучше?
PS: и никто не будет твой assembly рефакторить. Системное программирование оно другое, и читаемость там на последнем месте.
-~{}~ 28.10.10 20:04:
> Правильнее, чем этот ниже...
чем? хочется услышать аргументы
Здесь уместнее Factory =)
-~{}~ 29.10.10 01:21:
> хочется услышать аргументы
1. Судя по коду и при необходимости отладки - сразу видно, что инициализирвется объект типа "Base_Redirect"
2. Далее идут сетеры для приватных/защищенных атрибутов.
3. Для внесения минимальных изменений будет достаточно добавить сетер, а если будет необходимо сменить, например, URL, то в твоем случае - нужно будет заводить новые методы, или еще жухе - вводить свои атрибуты (атрибуты ради атрибутов), вне логичном контексте этого обекта.
4. elementDoesNotExistRedirect
Скорее должен называться getNotExistsRedirectObj, НО, эти 5 строчек кода возвращают объект, его задача одна: возвратить новый обьект (причем ничего в нем не изменяя), задача твоего новоиспеченного метода - возвратить новый объект, также, без какой либо обработки данных и логики, смысл дробить?
5. Кроме того, $this подразумивает обращение к методу этого объекта, выполняемый действия в контексте этого объекта (изменение атрибутов, обработка атрибутов или выполнение других методов контекста этого объекта). Создание обьектов всегда должно быть сразу, через new, factory, instance etc.
> Системное программирование оно другое, и читаемость там на
> последнем месте.
Слив засчитан ;D
-~{}~ 29.10.10 01:21:
> хочется услышать аргументы
1. Судя по коду и при необходимости отладки - сразу видно, что инициализирвется объект типа "Base_Redirect"
2. Далее идут сетеры для приватных/защищенных атрибутов.
3. Для внесения минимальных изменений будет достаточно добавить сетер, а если будет необходимо сменить, например, URL, то в твоем случае - нужно будет заводить новые методы, или еще жухе - вводить свои атрибуты (атрибуты ради атрибутов), вне логичном контексте этого обекта.
4. elementDoesNotExistRedirect
Скорее должен называться getNotExistsRedirectObj, НО, эти 5 строчек кода возвращают объект, его задача одна: возвратить новый обьект (причем ничего в нем не изменяя), задача твоего новоиспеченного метода - возвратить новый объект, также, без какой либо обработки данных и логики, смысл дробить?
5. Кроме того, $this подразумивает обращение к методу этого объекта, выполняемый действия в контексте этого объекта (изменение атрибутов, обработка атрибутов или выполнение других методов контекста этого объекта). Создание обьектов всегда должно быть сразу, через new, factory, instance etc.
> Системное программирование оно другое, и читаемость там на
> последнем месте.
Слив засчитан ;D
HraKK
(array($this->getRequest()->getRequest()->getUriParts(0)));
Либо через New, либо через синголтон, либо черел булдер, либо через слой API, еще есть масса паттернов пораждающих объекты, нужно отталкиваться от архитектуры.
Что-то вроде того,
a) new request;
b) request::getInstance()->;
c) API::request()->;
$this подразумевает под собой действие над самим объектом, а когда я вижу что он (метод) внутри объекта отвечает за рождение нового другого объекта, то логика ООП теряется.
-~{}~ 29.10.10 01:55:
Вообще, такого нужно избегать, объект, он на то и объект, что бы жить отдельно от остальных.
(array($this->getRequest()->getRequest()->getUriParts(0)));
Либо через New, либо через синголтон, либо черел булдер, либо через слой API, еще есть масса паттернов пораждающих объекты, нужно отталкиваться от архитектуры.
Что-то вроде того,
a) new request;
b) request::getInstance()->;
c) API::request()->;
$this подразумевает под собой действие над самим объектом, а когда я вижу что он (метод) внутри объекта отвечает за рождение нового другого объекта, то логика ООП теряется.
-~{}~ 29.10.10 01:55:
Вообще, такого нужно избегать, объект, он на то и объект, что бы жить отдельно от остальных.
HraKK
Что обоснуй? У меня блин два ночи уже, разошелся я.
Например, обект "юзер" имет методы - проверить пароль, сохранить изменения. Объект юзер не должен ничего знать о том, какой урл и т.п., за это отвечает контроллер/модель., а тут получается, что объект "юзер" хранит в себе информацию о другом объекте "запрос" (имеет метод к его доступу), который ни каким боком не касается объекта "пользователь", и нарушение в работе объекта "реквист" вызовет проблемы в работе объекта "юзер".
Если на пальцах, то, есть обект - поезд, он едет своей дорогой со своей скоростью и т.п., и объект - машина, она тоже едет своей дорогой, машина пересекает железную дорогу, но не просто пересекает, а через шлагбаум, шлагбаум (паттерны отвечающе за рождение и доступ к обектав).
Шлагбаумом может быть и прослойка "безопасность", которая отвечает за снятие информации с датчиков., но это уже другой большой объект, и знать поезду про датчики и автомобиль совсем необязательно.
А за все это отвечает дорожная служба, которая и строила дорогу, и ставила шлагбаум, это их ведомство.
Это и есть принцип ООП.
-~{}~ 29.10.10 02:13:
А это - ($this->getRequest()->getRequest()->getUriParts(0))
Получается, едет себе водила, едет, и вдруг хочет получить информацию о состоянии реле открытия шлагбаума через попутчика, который является инженером службы безопасности.
Что обоснуй? У меня блин два ночи уже, разошелся я.
Например, обект "юзер" имет методы - проверить пароль, сохранить изменения. Объект юзер не должен ничего знать о том, какой урл и т.п., за это отвечает контроллер/модель., а тут получается, что объект "юзер" хранит в себе информацию о другом объекте "запрос" (имеет метод к его доступу), который ни каким боком не касается объекта "пользователь", и нарушение в работе объекта "реквист" вызовет проблемы в работе объекта "юзер".
Если на пальцах, то, есть обект - поезд, он едет своей дорогой со своей скоростью и т.п., и объект - машина, она тоже едет своей дорогой, машина пересекает железную дорогу, но не просто пересекает, а через шлагбаум, шлагбаум (паттерны отвечающе за рождение и доступ к обектав).
Шлагбаумом может быть и прослойка "безопасность", которая отвечает за снятие информации с датчиков., но это уже другой большой объект, и знать поезду про датчики и автомобиль совсем необязательно.
А за все это отвечает дорожная служба, которая и строила дорогу, и ставила шлагбаум, это их ведомство.
Это и есть принцип ООП.
-~{}~ 29.10.10 02:13:
А это - ($this->getRequest()->getRequest()->getUriParts(0))
Получается, едет себе водила, едет, и вдруг хочет получить информацию о состоянии реле открытия шлагбаума через попутчика, который является инженером службы безопасности.
HraKK
Да, можешь, потому что двигатель часть машины, а вот, дорога это не твое. В нашем случае обект юзер - это машина, реквист это дорога, но ты можешь спросить у прохожего, по какой ты дороге едешь, прослойка между дорогой и тобой - прохожий.
-~{}~ 29.10.10 02:16:
Тут пример в самом конце добавил
http://phpclub.ru/talk/showthread.php?postid=917763#post917763
Да, можешь, потому что двигатель часть машины, а вот, дорога это не твое. В нашем случае обект юзер - это машина, реквист это дорога, но ты можешь спросить у прохожего, по какой ты дороге едешь, прослойка между дорогой и тобой - прохожий.
-~{}~ 29.10.10 02:16:
Тут пример в самом конце добавил
http://phpclub.ru/talk/showthread.php?postid=917763#post917763