Но сделал же в итоге Работодателю по идее должно быть всё равно - при любом варианте он имеет работающую програму.

Я например "просто код" всегда разбиваю на классы+методы/функции ибо мне так например легче.
Разбил задачу на более мелкие - написал и протестировал каждую, потом соединил и все работает. 
А потом, если что-то аналогичное потребуется (да хоть те же матрицы с их умножением,а они у меня в отдельном классе)
взял, скопировал/унаследовал+дописал и можно юзать.

Добавлено через 2 минуты и 54 секунды


Не, эт я по учебе схалявить хотел и готовый курсак переделать. В итоге убил время на попытку в нем разобраться. 

Не спорю, у разных людей разные предпочтения.

Я же, например, классы, функции, переменные буду избегать всегда, когда это только возможно, вот мне и интересно, оплачивается ли такой подход в программировании

ИМХО нет.
Думаю что если бы оплачивался, то ООП не возникло бы 

Абсолютно не верный вывод. После ввода программы в эксплуатацию требуется её активная поддержка для добавления фич и устранения багов. 

соответсвенно это тоже не верно, ну и всё последующее.

Это сообщение отредактировал(а) Mayk - 18.9.2008, 20:34

Программы приходится развивать. Вырастают новые технические требования, отмирают старые. Вылезают ошибки, а иногда переделывать приходится больше половины готового кода. Есть даже отдельные программисты, которые работают не на написание новых проектов, а на поддержку старых. Что в таком случае является целью? Что думать о товарище программисте, который написал "чтобы работало" и свалил? Не проще ли было изначально задуматься о стройной архитектуре? Я не пытаюсь заставить тебя полюбить ООП, хочешь - решай в функциональной парадигме, но только безо всяких "после нас хоть потоп"!


Умоляю тебя! В данный момент я - жертва такого программиста. Не бывает задачи "неоптимизированность кода". Бывает задача "эй вы, парни, нам надо вот такую фишку сделать и тут поменять", и в решении задачи ты сотни, тысячи раз обматеришь предшественника, поменяешь всё до чего дотянешься (или, что случается чаще, примешь как есть. Нет времени всё переписывать). Ура - задача (не скажу какой ценой) решена, можно перестать ругаться на заплатанный код. Думаешь, какая задача встанет следующей? Правильно! "Вот вылез баг, вот здесь плюшечку, и мы тут с бухгалтерией подумали, что надо вот этот момент по-другому вычислять...", но задачи оптимизации тебе в жизни никогда не поставят. И даже если выбьешь с начальника время на таковую, что теперь уже можно поменять? Только переписать всё целиком.

Чем дальше, тем больше заплатанным становится код. Изменение одной его части влечёт совершенно непредсказуемые для всей программы последствия. Автоматизированные тесты навесить на это разваливающееся и подпёртое костылями чудо невозможно, и тестирование превращается в каторгу. Представь теперь, какое количество иголок будет втыкаться в твою восковую фигуру - нужна такая тяжесть на карме?


Эй, на чём-то придётся остановиться! Ни классов, ни функций, ни переменных - так не бывает, хотя бы что-то одно придётся использовать, причём это одно наверняка окажется функциями   

Диагноз - повышенное оптимизаторство, плавали - знаем, сам с ассемблера начинал. Жизнь заставит - всё полюбишь. И функции (за что на них-то взъелся?), и классы (с опытом поймёшь, как их юзать). И даже переменные. Всё хорошо, когда растёт на своём месте.

Зачем:

function superkod($a, $b){

echo $a+$b;

}

superkod(3+1);

если можно:

echo 3+1;

Это сообщение отредактировал(а) slavaentp - 19.9.2008, 15:18

А представь себе, что там не echo $a + $b, а около 40 строк кода, который делает что то с этими самыми переменными
а в программе это делать с ними надо часто. И тут появляется выбор - функция или копирование кода через
Ctrl+C, Ctrl+V (или как там у кого хоткеи настроены) 
Я лично предпочитаю в такой ситуации написать функцию.

Чем "goto" не устраивает?

Действительно отстой. Название superkod не говорит совершенно ни о чём. Функция обладает побочным эффектом, заключающимся в использовании echo. Ну её такую нафиг!

slavaentp, тролль нехороший  Но зато живая беседа.

Начнем, полжалуй, с функций.
Чтобы пример был нагляднее, возмем матрицу.
Нам нужно посчитать детерминант матрицы. Возьми матрицу 5x5 и попробуй написать код для рассчета ее детерминанта без функций. 
А теперь представь что матрица не 5х5, а вообще произвольного размера - как пользователь задаст.
Это тоже можно написать без функций. И даже будет работать, но код будет во много раз длиннее, а читать этот код будет нереально. Следовательно поддержка программы сводится к нулю.
Итого: больше потраченного времени программиста, программа занимает больше места, большее количество кода увеличивает шанс человеческой ошибки (скрытые баги), поддержку программы осуществлять трудно.

Вообще: большинство из того, что сделано - функции, классы и т.п. - сделано для упрощения поддержки и развития программы.

Это сообщение отредактировал(а) smartov - 19.9.2008, 17:28

Истории много лет, не одна сотня копий разбита в боях. Поисковики в помощь.

Хорошо, а теперь взять те же матрицы и их умножение (недавно сам делал):
как с помощью goto реализовать умножение двух произвольных матриц?
мне это представляется возможным только так:


А теперь с функциями (даже без классов):


И какой же вариант более простой и легчечитаемый? 

Это сообщение отредактировал(а) kosmonaFFFt - 22.9.2008, 18:42

Нет, я конечно не ярый фанат ООП, но вы батенька ,slavaentp, похоже немного бередите. Вы мне напоминаете китайцев, которые сначало создают себе трудности а потом их решают. 
Например я не люблю использовать ООП в тех случиях когда без него можно обойтись, ну например какаянито маленькая програмка(обычно системная утила) - я стараюсь реализовать все на api, используя процедурный подход.  а когда речь идет о чем то более глобальном...например база данных. зачем создавать себе трудности, лопатить кучу документации, зачем изобретать велосипед, когда можно воспользоваться готовым классом и при необходимости дорабоать его. 
ну а уж слова по поводу того что функция - это ненужная вещь, я задам лишь один вопрос...вы когданибудь писали программы на нсеколько тысяч строк??!!  разбираться в такой мешанине кода это наверно веселое занятие...когда гораздо удобнее все фуки раскидать по юнитам, и при необгодимости вызывать их из главной программы.

 ООП позволяет тебе писать меньше кода на больших проектах. Вопросы есть?

Добавлено через 2 минуты и 51 секунду
Есть такие штуки, как полиморфизм. Они уменьшают количество кода.
Есть такие штуки, как инкапсуляция. Они повышают читабельность кода.
Есть такие штуки, как шаблоны проектирования. Они уменьшают количество головной боли при разработке.
Есть такие штуки, как фреймворки. Они в разы сокращают количество кода по сравнению с C-style библиотеками.