-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
какие минусы у ООП?
- Автор темы HraKK
- Дата начала
fisher
Какие я знания получил среди бывших комментариев? Что ООП бывает индусским? Что он исполняется дольше чем процедурный? Давай не будешь скатываться на "сам дурак", а напишешь что-то и тогда уже получив мое "это не проблемы ООП" или "да, действительно" будешь решать что-то хочу я знать или нет, окей?
Какие я знания получил среди бывших комментариев? Что ООП бывает индусским? Что он исполняется дольше чем процедурный? Давай не будешь скатываться на "сам дурак", а напишешь что-то и тогда уже получив мое "это не проблемы ООП" или "да, действительно" будешь решать что-то хочу я знать или нет, окей?
HraKK
кроме оверхеда из-за тяжёлых обектов, есть ещё оверхед в коде который необходим (интерфейсы, абстракции). паттерны - опять же следствие того, что задача не решена на уровне парадигмы. дублирование кода. сложность построение распределённых систем в сравнении с функциональным подходом. и т.д. и т.п.
идеальная методология, та, которая позволит не писать код вовсе.
кроме оверхеда из-за тяжёлых обектов, есть ещё оверхед в коде который необходим (интерфейсы, абстракции). паттерны - опять же следствие того, что задача не решена на уровне парадигмы. дублирование кода. сложность построение распределённых систем в сравнении с функциональным подходом. и т.д. и т.п.
идеальная методология, та, которая позволит не писать код вовсе.
fisher
накатила суть
HraKK
ок, давай тогда начнем с системы координат - по-моему мы в разных. смотри, у тебя ценности такие, похоже - это всё проблемы не ооп, а проблема бестолковых дураков. а когда берём _умных_ людей, _годные_ инструменты и _спокойно_ так и чтобы бизнес-аналитика была толковая - то всё-всё сможем. а мои ценности другие - надо взлететь с той херней, что есть, здесь и сейчас, без шаровых коней. поэтому ты написал "не проблемы ооп" на то, что проблемами как раз является. так что я считаю, что твои ценности ложные. невозможно спорить, находясь в разных системах координат. в моей системе реальную ценность представляет неидеальность людей и инструментов. я кстати сам пишу довольно посредственный объектный (редко- объектно-ориентированный) код, а не процедурный.
ок, давай тогда начнем с системы координат - по-моему мы в разных. смотри, у тебя ценности такие, похоже - это всё проблемы не ооп, а проблема бестолковых дураков. а когда берём _умных_ людей, _годные_ инструменты и _спокойно_ так и чтобы бизнес-аналитика была толковая - то всё-всё сможем. а мои ценности другие - надо взлететь с той херней, что есть, здесь и сейчас, без шаровых коней. поэтому ты написал "не проблемы ооп" на то, что проблемами как раз является. так что я считаю, что твои ценности ложные. невозможно спорить, находясь в разных системах координат. в моей системе реальную ценность представляет неидеальность людей и инструментов. я кстати сам пишу довольно посредственный объектный (редко- объектно-ориентированный) код, а не процедурный.
о десятках метров работающего кода, написанного десятками людей, с которым надо что-то делать
недавно я столкнулся с вот каким недостатком, специфика задачи - обработка больших объемов данных
использование коллекций вместо массивов, разрезание на части и передача их группам объектов со всякими делегированиями и фасадами, может привести к утечке памяти - отследить все объекты с данными в десятках вызовов бывает непросто
надо писать внимательно, чистить коллекции и вызывать gc - в отличие от процедурного программирования, где после вызова функции в норме остается только параметры и результат
-~{}~ 13.09.10 23:44:
конечно, это тоже не проблема ООП в вакууме,
на процедурном С проблема подчистки памяти стоит в намного большей степени,
но в рамках PHP я такое заметил, без объектов я за очисткой памяти не следил бы
недавно я столкнулся с вот каким недостатком, специфика задачи - обработка больших объемов данных
использование коллекций вместо массивов, разрезание на части и передача их группам объектов со всякими делегированиями и фасадами, может привести к утечке памяти - отследить все объекты с данными в десятках вызовов бывает непросто
надо писать внимательно, чистить коллекции и вызывать gc - в отличие от процедурного программирования, где после вызова функции в норме остается только параметры и результат
-~{}~ 13.09.10 23:44:
конечно, это тоже не проблема ООП в вакууме,
на процедурном С проблема подчистки памяти стоит в намного большей степени,
но в рамках PHP я такое заметил, без объектов я за очисткой памяти не следил бы
atv
Новичок
fisher
ты так и не раскрыл суть своей фразы, что "надо взлететь с той херней, что есть". О какой херне ты говоришь? Ты ведь понимаешь, что хернёй можно назвать всё что угодно, и без чёткого определения разговора не получиться.
P.S. Кстати, кто какое ООП имеет ввиду? ОО Проэктирование или ОО Программирование? HraKK, ты что подразумевал?
ты так и не раскрыл суть своей фразы, что "надо взлететь с той херней, что есть". О какой херне ты говоришь? Ты ведь понимаешь, что хернёй можно назвать всё что угодно, и без чёткого определения разговора не получиться.
P.S. Кстати, кто какое ООП имеет ввиду? ОО Проэктирование или ОО Программирование? HraKK, ты что подразумевал?
fisher
накатила суть
atv
а любая "херня" из жизни, которая в большом количестве упоминалась в этом треде, упоминание которой раздражает автора треда, потому что она из области реальной жизни, в которой всё не так и не эдак, и которую автор треда, особенно не раздумывая, обозначил как "не проблема ооп".
а любая "херня" из жизни, которая в большом количестве упоминалась в этом треде, упоминание которой раздражает автора треда, потому что она из области реальной жизни, в которой всё не так и не эдак, и которую автор треда, особенно не раздумывая, обозначил как "не проблема ооп".
fisher
Скажем так, не одна из этих хреней мне в жизни не создавала проблем.
Дольше загрузка? что 0.01 что 0.03 все равно, узкое место всегда было база данных. А горизонтальное масштабирование спасет мир.
Кривые руки у программистов? Увольняйте. Не можете? Перейдите на другую работу.
Кривые руки у Вас? Потренируйтесь над каким не будь опен сорс проектом или проектом для себя.
Оверхед в коде? Ну как бы да он есть, но это не проблема потому что этот код нужен и он выполняет свою роль. И не раз меня спасал когда в проекте все менялось, а я добавив или подменив пару классов решал поставленную задачу.
Скажем так, не одна из этих хреней мне в жизни не создавала проблем.
Дольше загрузка? что 0.01 что 0.03 все равно, узкое место всегда было база данных. А горизонтальное масштабирование спасет мир.
Кривые руки у программистов? Увольняйте. Не можете? Перейдите на другую работу.
Кривые руки у Вас? Потренируйтесь над каким не будь опен сорс проектом или проектом для себя.
Оверхед в коде? Ну как бы да он есть, но это не проблема потому что этот код нужен и он выполняет свою роль. И не раз меня спасал когда в проекте все менялось, а я добавив или подменив пару классов решал поставленную задачу.
fisher
накатила суть
твоя ключевая ошибка - обощение от "мне в жизни не создавала проблем" к "не проблема ООП".
>>узкое место всегда было база данных
ну а у меня одно из узких мест проц. а ещё узкое место память, между прочим, эта проблема стреляет редко, но в-основном как раз на замороченном ооп-коде.
а с cpu - у нас пхп обрабатывает больше десяти тысяч запросов в секунду. ну что мне теперь издеваться над теми, у кого узкое место бд?
>>пассаж про кривые руки и управление
это детский лепет. ярчайший признак рассуждений программистушки которому похрену на всё кроме личного удобства. будешь отвечать за запуск проекта - а тебе кто-то из подчиненных при срыве сроков или при явном отжоре ресурсов начнет говорить подобную ересь про "перейди на другую работу" и "найми хороших программистов" - вот мне будет очень интересно посмотреть, что ты будешь делать дальше.
>>Оверхед в коде? Ну как бы да он есть, но это не проблема потому что этот код
>>нужен и он выполняет свою роль
а это определенно самый зачотный аргумент в пользу "не проблема ооп".
этот тред нужен, и он выполняет свою роль!
>>узкое место всегда было база данных
ну а у меня одно из узких мест проц. а ещё узкое место память, между прочим, эта проблема стреляет редко, но в-основном как раз на замороченном ооп-коде.
а с cpu - у нас пхп обрабатывает больше десяти тысяч запросов в секунду. ну что мне теперь издеваться над теми, у кого узкое место бд?
>>пассаж про кривые руки и управление
это детский лепет. ярчайший признак рассуждений программистушки которому похрену на всё кроме личного удобства. будешь отвечать за запуск проекта - а тебе кто-то из подчиненных при срыве сроков или при явном отжоре ресурсов начнет говорить подобную ересь про "перейди на другую работу" и "найми хороших программистов" - вот мне будет очень интересно посмотреть, что ты будешь делать дальше.
>>Оверхед в коде? Ну как бы да он есть, но это не проблема потому что этот код
>>нужен и он выполняет свою роль
а это определенно самый зачотный аргумент в пользу "не проблема ооп".
этот тред нужен, и он выполняет свою роль!
atv
Новичок
Ты сам подталкиваешь к тому, чтобы тебе отвечали "а у меня получилось".
И на твою "херню" whirlwind очень правильно ответил http://phpclub.ru/talk/showthread.php?postid=912822#post912822. Ты записываешь в минусы ООП его бОльшую сложность, но так ведь и сложность задач большАя, и он позволяет с этой сложностью справиться (опять упираемся в тонкости различия между OOP и OOD)
-~{}~ 14.09.10 12:44:
Уж сколько раз твердили миру, что стоимость проца ГОРАЗДО дешевле, чем стоимость разработчика. Это раз. А два, оптимизация ООП кода даёт такие же хорошие результаты как и оптимизация процедурного. Да, в некоторых случаях, для повышения производительности, приходиться жертвовать ООП и сворачивать некоторые классы. НО! не во всём проекте, а в строго определённых по профайлингу местах. И таких мест в проекте не так уж и много, наберётся процентов 10 от всего кода.
Это уже проблемы организации процесса разработки и контроля. И ты хочешь сказать, что отказавшись от ООП ты не сталкнёшся с такими проблемами?