Полная Версия: Императив VS ООП
| Цитата (twin @ 15.01.2015 - 17:12) |
| Разработка приложения на ООП парадигме занимает несоизмеримо большее время, нежели на имеративе. |
зависит от опыта программиста и его умения мыслить объектами
_____________
Стимулятор ~yoomoney - 41001303250491
Нет, не надоело. Ибо я с этим не согласен в корне. И пока не вижу доказательств всем этим громким заявлениям.
ООП, это никакой не каркас. Вернее не так. Наличие каркаса, это не прерогатива ООП. И без него можно писать вполне стройные приложения. По другим правилам, но по правилам все же. И пока мы не сравнили, никто не может уверенно сказать, какие правила лучше.
ООП, это никакой не каркас. Вернее не так. Наличие каркаса, это не прерогатива ООП. И без него можно писать вполне стройные приложения. По другим правилам, но по правилам все же. И пока мы не сравнили, никто не может уверенно сказать, какие правила лучше.
| Цитата |
| каркас который вообще не должен зависеть от реализации и от конкретного языка программирования. При процедурке весь каркас надо держать в голове. |
А вот это вообще никогда не приму. Ты сам недавно писал про ложку, лопату и экскаватор. А сейчас предлагаешь универсальное, всеобъемлещее "устройство".
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (Valick @ 15.01.2015 - 14:25) | ||
зависит от опыта программиста и его умения мыслить объектами |
Это субъективная оценка. Примерно как "порошок Дося отстирывает в три раза больше пятен". Почему берется за основу опыт ООП программиста, а опыт императивщика не берется?
Я стараюсь делать объективные выводы. Из той информации, которую имеем на сегодняшний момент.
Если взять за основу все прочие равные (квалификации исполнителей, библиотеки наработок и так далее), то разработка императивных приложений происходит быстрее. Ибо императивное приложение по сути имеет законченный вид. И может быть не так круто, но работать начинает быстрее. Потом уже рефакторинг, до этого мы не дошли.
ООП приложение не может быть законченным, ибо сильно связано. И чтобы внедрить какую-нибудь новую фишку (тот же Identity map к примеру), нужно переписать большую половину уже готового кода. Потому что "каркас".
Отсюда и вывод, а не из времени, потраченном оппонентом на разработку и не из оценки его квалификации.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
twin, еще хочу заметить, у меня есть такая черта характера как перфекционизм. Если бы её не было, я бы наверное уже давно вам выдал своё решение. Я постоянно рефакторю код и пытаюсь найти лучшее решение, но это в итоге ведет к увелечению сроков.
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
chee
Прости, но это не увеличение сроков уже, и не перфекционизм. Это какая то эректильная дисфункция.
Любой программист недоволен своим вчерашним кодом. Я специально не открываю этот скрипт с тех пор, как задекларировал его готовность. Ибо знаю, что полезу что-нибудь исправлять.
Но я точно знаю, что мне исправлять нужно будет мааалюсенькие кусочки. Вам же приходится каждый раз переписывать все заново. Иначе такой срок разработки ничем объяснить нельзя. Повторюсь, там работы при самом халатном отношении на три вечера. Ну максимум неделя. Мы ждем уже больше двух месяцев.
Так что пока 1:0 в мою пользу.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Прости, но это не увеличение сроков уже, и не перфекционизм. Это какая то эректильная дисфункция.
Любой программист недоволен своим вчерашним кодом. Я специально не открываю этот скрипт с тех пор, как задекларировал его готовность. Ибо знаю, что полезу что-нибудь исправлять.
Но я точно знаю, что мне исправлять нужно будет мааалюсенькие кусочки. Вам же приходится каждый раз переписывать все заново. Иначе такой срок разработки ничем объяснить нельзя. Повторюсь, там работы при самом халатном отношении на три вечера. Ну максимум неделя. Мы ждем уже больше двух месяцев.
Так что пока 1:0 в мою пользу.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (twin @ 15.01.2015 - 17:50) |
| ООП приложение не может быть законченным, ибо сильно связано. И чтобы внедрить какую-нибудь новую фишку (тот же Identity map к примеру), нужно переписать большую половину уже готового кода. Потому что "каркас". |
это шутка юмора такая? то что ты сейчас описал - это не ООП, это классический говнокод (говнокод с использованием классов). В грамотно организованном ООП для расширения функционала вообще не надо переписывать ни одной строчки, если это не так, то значит нарушены принципы инкапсуляции, а без инкапсуляции - это уже не ООП.
_____________
Стимулятор ~yoomoney - 41001303250491
| Цитата (twin @ 15.01.2015 - 19:25) |
| к что пока 1:0 в мою пользу. |
Я это не отрицаю.
| Цитата (twin @ 15.01.2015 - 19:25) |
| Любой программист недоволен своим вчерашним кодом. |
ну-ну
| Цитата (twin @ 15.01.2015 - 19:25) |
| Но я точно знаю, что мне исправлять нужно будет мааалюсенькие кусочки. |
ну-ну
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
| Цитата |
| В грамотно организованном ООП для расширения функционала вообще не надо переписывать ни одной строчки |
C этим никто не спорил. Тут вопрос как раз о времени разработки такого "грамотно организованного ООП".
Яркий пример мы и наблюдаем. Сначала была одна организация, потом она стала немного грамотнее (внедрили новый паттерн), потом еще немного грамотнее (еще один паттерн), потом еще... И так до бесконечности. Беда в том, что для достижения полной грамотности приходится перелопачивать всю структуру, а это занимает кучу времени. А гармонии так можно и никогда не достичь.
Я поступил проще. Взял и выполнил все условия ТЗ. Хотел сравнить, как это будет в плане расширяемости и так далее. А приходится ждать, пока оппонент достигнет полного просветления. Что, как я подозреваю, в ООП невозможно по определению. Впрочем как и в любой парадигме. Нет предела совершенству.
А время разработки действующего продукта есть. И вот его я и учитываю. Все что после - второе уже.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Яркий пример мы и наблюдаем. Сначала была одна организация, потом она стала немного грамотнее (внедрили новый паттерн), потом еще немного грамотнее (еще один паттерн), потом еще... И так до бесконечности. Беда в том, что для достижения полной грамотности приходится перелопачивать всю структуру, а это занимает кучу времени. А гармонии так можно и никогда не достичь.
Я поступил проще. Взял и выполнил все условия ТЗ. Хотел сравнить, как это будет в плане расширяемости и так далее. А приходится ждать, пока оппонент достигнет полного просветления. Что, как я подозреваю, в ООП невозможно по определению. Впрочем как и в любой парадигме. Нет предела совершенству.
А время разработки действующего продукта есть. И вот его я и учитываю. Все что после - второе уже.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (chee @ 15.01.2015 - 16:04) | ||||
ну-ну
ну-ну |
Что "ну-ну"?
Я не говорю пока, что мой подход круче. Потому что не с чем сравнивать. Вот если бы было бы с чем, можно было бы увидеть на практике. Может я и не прав, для того и вся затея - уяснить истину. А просто так сказать "нуну", это не разговор.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (Valick @ 15.01.2015 - 17:59) |
| это шутка юмора такая? то что ты сейчас описал - это не ООП, это классический говнокод (говнокод с использованием классов). В грамотно организованном ООП для расширения функционала вообще не надо переписывать ни одной строчки, если это не так, то значит нарушены принципы инкапсуляции, а без инкапсуляции - это уже не ООП. |
Тематика данной темы: Императив VS ООП, Практическое сравнение..
А не бла бла бла.
Бла бла бла сопли , повторенные за кем то, любой мальчишка выдать сейчас может.
Раз такой "грамотный" ооп оппонент твину, ну так вперед, вместо chee покодь для разнообразия чуть чуть, chee то очевидно слился, при этом подставив twina.
_____________
There never was a struggle in the soul of a good man that was not hard
twin, в середине этой темы я хотел отказаться от этой затей, я прдолжаю ей заниматься не для спора а лишь по двум причинам: проверить смогу ли я сделать законченый продукт и обучиться лучше общаться с объектами. Как соревнование между парадигмами данное действо бесмысленно.
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
twin, кстати а судьи кто?
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
| Цитата (chee @ 15.01.2015 - 16:19) |
| twin, в середине этой темы я хотел отказаться от этой затей |
Вообще, как говорится, "заметьте, не я это предложил".
Мне сейчас довольно обидно за потраченное время. Теоретически мы долго спорили в другой теме, здесь я надеялся разобраться практически. И был очень рад, когда наконец то нашелся человек, готовый не просто декларировать (читай: бездумно повторять за другими) преимущества ООП парадигмы, а разобрать это на практике. Дело в том, что обычно поборники сливаются не в середине и даже не в начале, а вообще до того.
Я так понимаю боятся, что все перелопаченные, вызубренные и вымученные паттерны окажутся обыкновенными костылями, а им с этим жить.
| Цитата |
| я прдолжаю ей заниматься не для спора а лишь по двум причинам: проверить смогу ли я сделать законченый продукт и обучиться лучше общаться с объектами. Как соревнование между парадигмами данное действо бесмысленно. |
Я так понимаю, Вы никогда раньше не делали законченных приложений? Хорошо, это аргумент. Потерпим еще.
Однако любое терпение имеет предел. Вы обманываете не только мои надежды, но и всех тех, кто хотел для себя узнать много нового, о чем не пишут в ваших умных книжках про ООП. Уважайте окружающих, не затягивайте с дедлайном плиз.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (chee @ 15.01.2015 - 16:21) |
| twin, кстати а судьи кто? |
Главный судья - объективность. Мы сравним приложения по тем параметрам, которые можно измерить или вычислить или обосновать. Как допустим вот этот первый - скорость разработки.
В процессе определим. Объем кода, объем дополнительного кода для расширения, скорость работы скрипта, память, количество обращений к ФС и так далее.
Можно провести голосование по субъективным показателям (прозрачность кода допустим), но это уже по желанию в процессе.
Вобщем то тут не ралли Париж-Дакар, тут не в призах дело. А в реальном сравнении и сделанных на его основе выводах.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
twin
chee
Давайте вы просто напишите валидатор данных или роутер, или что нибудь меньше 400 строчек кода и посмотрим что будет
twin
Я могу выступить в виду соперника (ООП), только если меньше слов будет и больше дела.
_____________
Мой блог
chee
Давайте вы просто напишите валидатор данных или роутер, или что нибудь меньше 400 строчек кода и посмотрим что будет
twin
Я могу выступить в виду соперника (ООП), только если меньше слов будет и больше дела.
_____________
Мой блог
Здесь расположена полная версия этой страницы.