-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Не пойму, в чем удобство такого метода написания кода
- Автор темы Leonid
- Дата начала
> мыслить надо удобством API
А кто спорит? Именно так.
Кстати, я думаю DOM - идеальный ООП пример.
-~{}~ 28.10.10 20:28:
korchasa
и имя ему Billing
Это не ооп, функциональное программирование обернутое в класс.
-~{}~ 28.10.10 20:28:
korchasa
Да, там написано про функцию, но до этого тот же автор писал аналогичное про методы.
А кто спорит? Именно так.
Кстати, я думаю DOM - идеальный ООП пример.
-~{}~ 28.10.10 20:28:
korchasa
и имя ему Billing
Это не ооп, функциональное программирование обернутое в класс.
-~{}~ 28.10.10 20:28:
korchasa
Да, там написано про функцию, но до этого тот же автор писал аналогичное про методы.
AmdY
Я недавно имел беседу на эту тему и сформулировалось вот что
(не претендую на истинность, это просто размышления):
ООП, в моём представлении - это попытка упростить управление системой, усложнив её саму.
ООП ведь появилось не от балды. Это попытка как-то объять необъятные объемы кода. Попытка в очевидном направлении - мы так поступаем так всегда. Абстрагируемся от деталей, масштабируем изображение.
Из этого постулата уже вытекают разнообразные следствия.
Следствие: ООП - это write-only подход. В парадигме ООП ошибку проще (и правильнее!) исправить не в корне, а в ветках, сделав новую, с исправленным методом.
пример:
На стаковерфлоу вопрос, как избежать сообщения об ошибке о deprecated функции get_magic_quotes_gpc в Кохане.
Ответ: ни в коем случае не правьте в коде, унаследуйте класс, и в нем переопределяйте все, что хотите.
Сама идеология ООП заставляет нас не думать о том, что в корнях, что внутри, не оглядываться назад, а смотреть вперед.
Разумеется, у такого подхода есть недостатки. Наследованные классы наслаиваются друг на друга, как краска на скамейке. И в какой-то момент начинают отслаиваться...
Следствие: Любая иерархия классов - это уже новый язык. Со своей документацией, соглашениями, идеологией. Это уже не РНР! Именно поэтому в данном топике так много споров: все говорят на разных языках.
Следствие: программа, написанная без ООП, всегда будет "проще" - проще в восприятии, понятнее окружающим - она написана на "всеобщем" языке.
Следствие: как всякий опасный инструмент двойного действия (упрощение через усложнение), ООП всегда будет черезвычайно сложно в применении и прорждать случаи неправильного использования, усугубленные идеологией: поклонник некоего подхода всегда будет подсознательно закрывать глаза на недостатки и выпячивать достоинства, причем даже не перед другими в первую очередь, а для себя - в использовании.
Смотря что проще.
Я недавно имел беседу на эту тему и сформулировалось вот что
(не претендую на истинность, это просто размышления):
ООП, в моём представлении - это попытка упростить управление системой, усложнив её саму.
ООП ведь появилось не от балды. Это попытка как-то объять необъятные объемы кода. Попытка в очевидном направлении - мы так поступаем так всегда. Абстрагируемся от деталей, масштабируем изображение.
Из этого постулата уже вытекают разнообразные следствия.
Следствие: ООП - это write-only подход. В парадигме ООП ошибку проще (и правильнее!) исправить не в корне, а в ветках, сделав новую, с исправленным методом.
пример:
На стаковерфлоу вопрос, как избежать сообщения об ошибке о deprecated функции get_magic_quotes_gpc в Кохане.
Ответ: ни в коем случае не правьте в коде, унаследуйте класс, и в нем переопределяйте все, что хотите.
Сама идеология ООП заставляет нас не думать о том, что в корнях, что внутри, не оглядываться назад, а смотреть вперед.
Разумеется, у такого подхода есть недостатки. Наследованные классы наслаиваются друг на друга, как краска на скамейке. И в какой-то момент начинают отслаиваться...
Следствие: Любая иерархия классов - это уже новый язык. Со своей документацией, соглашениями, идеологией. Это уже не РНР! Именно поэтому в данном топике так много споров: все говорят на разных языках.
Следствие: программа, написанная без ООП, всегда будет "проще" - проще в восприятии, понятнее окружающим - она написана на "всеобщем" языке.
Следствие: как всякий опасный инструмент двойного действия (упрощение через усложнение), ООП всегда будет черезвычайно сложно в применении и прорждать случаи неправильного использования, усугубленные идеологией: поклонник некоего подхода всегда будет подсознательно закрывать глаза на недостатки и выпячивать достоинства, причем даже не перед другими в первую очередь, а для себя - в использовании.
korchasa
LIMB infected
*****
Почти со всем согласен, но:
1. Термин write-only, ИМХО, не совсем корректен. write-only это perl, который часто невозможно прочитать. Тут же читать относительно просто. Другое дело, что расширение поведения, действительно идет вниз, а не заменой блоков "внутри".
2. Программа без ООП проще только до определенного момента, пока ее можно удержать в голове. Дальше ты все равно начнешь плодить абстракции. И уже не важно будут они в виде ооп или в виде процедур.
Почти со всем согласен, но:
1. Термин write-only, ИМХО, не совсем корректен. write-only это perl, который часто невозможно прочитать. Тут же читать относительно просто. Другое дело, что расширение поведения, действительно идет вниз, а не заменой блоков "внутри".
2. Программа без ООП проще только до определенного момента, пока ее можно удержать в голове. Дальше ты все равно начнешь плодить абстракции. И уже не важно будут они в виде ооп или в виде процедур.
*****
В точку. Поэтому, появляется необходимость в документировании всего и вся как в самом коде, так и в вики внутри группы разработчиков.
fixxxer
> $this->$method_name();
Потому что это не метод объекта, это хня (о его магическом действие будет знать только разработчик), такой вот ООП - в ступор вгонит любого (не ооп это!). Я даже не смогу задокументировать метод в где этот код ни интерфесом ни чем, ибо мне как разработчику неизвестно, какого результата ждать, что он возвратит, засунуть обертку для уменьшения кода мы получаем большую проблему.
Подобный код выносится в логические операции, тот же иф и всеми ненавистный switch.
В точку. Поэтому, появляется необходимость в документировании всего и вся как в самом коде, так и в вики внутри группы разработчиков.
fixxxer
> $this->$method_name();
Потому что это не метод объекта, это хня (о его магическом действие будет знать только разработчик), такой вот ООП - в ступор вгонит любого (не ооп это!). Я даже не смогу задокументировать метод в где этот код ни интерфесом ни чем, ибо мне как разработчику неизвестно, какого результата ждать, что он возвратит, засунуть обертку для уменьшения кода мы получаем большую проблему.
Подобный код выносится в логические операции, тот же иф и всеми ненавистный switch.
craz
Нестандартное звание
*****
в данный момент как раз открыта статья
http://www.maxkir.com/sd/designDead_RUS.html
и я наверное на ее основе смогу с вами поспорить, ООП таким становиться от того, что или оно действительно возникает уже поверх некоторой системы
Или в же в противном случае, ООП начинают писать и усложнять не следуя принципам ХР.
Таким образом в первом случае меняют то, что надо перепроектировать и переписать, или во втором случае делают не нужные потуги при написании, не делая рефакторинга, об этом у вас сказано
в данный момент как раз открыта статья
http://www.maxkir.com/sd/designDead_RUS.html
и я наверное на ее основе смогу с вами поспорить, ООП таким становиться от того, что или оно действительно возникает уже поверх некоторой системы
А тогда это противоречит, принципу что любая система должна быть сначала спроектирована.
Или в же в противном случае, ООП начинают писать и усложнять не следуя принципам ХР.
Таким образом в первом случае меняют то, что надо перепроектировать и переписать, или во втором случае делают не нужные потуги при написании, не делая рефакторинга, об этом у вас сказано
В следствии чего надо все таки сделать выводы и тогда ООП будет не врагом, а другом.
>> Подобный код выносится в логические операции, тот же иф и всеми ненавистный switch.
Чем хуже то?
PHP:
#1)
switch ($action) {
case 'foo':
return $this->doFoo();
case 'bar':
return $this->doBar();
default:
throw new InvalidArgumentException;
}
#2)
$handlers = array(
'foo' => 'doFoo',
'bar' => 'doBar',
);
if (isset($handlers[$action])) {
$method = $handlers[$action];
return $this->$method();
} else {
throw new InvalidArgumentException;
}