Volfi4, как раз таки и нет. Конструкция была бы вида собака->есть(еда); что гораздо более логично и проще реализовать. В дву словах: в функции есть, клесса собака мы будем изменять показатель голода и уничтожать переданный по ссылке элемент еда. Вот и все, все сделано по человечески, логично, просто, удобочитаемо. Кстати, всегда поражали программисты которые пишут вот так вот через жопу: еда->есть(собака)...
ООП нужно использовать там где он нужен. В проектах однодневках он явно не нужен. В сложных проектах или в проектах наработки которых будут использоваться в будущем его использовать необходимо, т.к. это облегчит работу с кодом в будущем. Конечно если будут соблюдены элементарные правила чистописания, если классы и методы будут иметь человеческие имена и т.д.
И PHP отнюдь не исключение. Попробуйте открыть исходники любого крупного проекта, везде ООП. Или вы считаете их зацикленными? А когда проект создается уже далеко не первый, всегда будет уже гора кода написанного ранее и наверняка где то там, в этой горе уже пылится процентов 70 того кода который теперь предстоит писать с нуля, только потому что раньше не был использован ООП и разобраться в этой горе довольно трудно.
Добавлено (03.03.2013, 02:51) --------------------------------------------- Stage, если проект построен с использованием ООП и все красиво названо, то он сам по себе становится инструкцией и документацией к себе же. В таком проекте разобраться проблем не составит. Простой пример:
Код
$human->heall(10); // человек лечить 10 $human->item[2]->drop(); // человек вещь 2 бросить
Мы просто читаем что написано и уже понимаем что проиходит в функциях и с кем/чем это происходит. Хотелось бы увидеть аналог этих двух строк без ООП. Так же читабельно будет?
Тупое же узание ООП без расчески из человеческих слов ни к чему хорошему не приведет:
Код
$a->s(10); $a->q[2]->n();
Цитата (Stage)
Такие тезисы выдвигают только ооп-мартышки, нормальные же люди выбирают технологии в зависимости от задачи.
Т.е. ты начинаешь наезды на ровном месте, не приводя ни одного внятного факта и считаешь себя человеком вменяемым? Ммм... Давай приведи преимущества других технологий. Товарищ не мартышка, нормальный ты наш. Какую же задачу ты будешь решать без ООП? Нет, я не спорю, можно и тизерку и игру браузерную написать (мы ведь про пхп) без ООП но сколько ты будешь при этом ебаться ты знаешь? Напиши аналог Ботвы без ООП. Вот знаешь, опыт мне подсказывает, что хрен у тебя что получится. Особенно правки вносить в такой проект через два года... Мои игры
Поверьте все что пишется с использованием ООП можно без проблем написать и без него, при этом часто будет даже меньше проблем чем с ним. А насчет написать аналог Ботвы, как мне подсказал гугл это игра и если вы готовы оплатить временные затраты, то я готов приняться за проект.
Кстати марсоход написан на чистом С без ООП и, если мне не изменяет память, количество строк кода порядка 2.5 милионов. Вы писали проекты сложнее?
Сообщение отредактировал Volfi4 - Воскресенье, 03 Марта 2013, 03:45
Volfi4, ну, начнем с того что код прошивки марсохода вам не покажут, если только вы не ооочень большая шишка и не его разработчик. Так что прочитанное в желтой прессе можно смело выкинуть в корзину и забыть. Ну да, вопрос только в том сколько времени у вас займет разработка. С ООП 3-4 месяца, без в 3 раза больше. Я и не спорю что без ООП можно написать абсолютно то же самое. Вот только размер будет больше и понимаемость кода упадет почти до нуля. Напишите аналог тех двух строк без ООП, так что бы это было компактно, интуитивно понятно и универсально. Мои игры
Volfi4, код делфи? Тут вроде как о пхп речь идет. Ну да ладно. human - это что? Классы ты не используешь, значит это переменная? И содержит она числовое значение хп ОДНОГО человека. Тогда следующая функция является бредом сивой кобылы. Сразу по двум причинам. Зачем в дроп передавать хп человека? И каждый предмет у тебя будет отдельной переменной? Даже не массивом???? А как этот код будет выглядеть если у тебя будет 100 человек и у каждого из них динамический рюкзак? Как ты вообще умудрился связать human и item2?? На уровне подсознания? Т.е. ты условился что предмет из item2 является собственностью переменной human? Мои игры
RUNGOGET2THECHOPAH, Ну зачем же столько бесполезной работы. Функция отвечает просто за исцеление и она нужна в единичном экземпляре. Просто в неё передаем объект исцеления и количество. Если понадобиться можно легким движением руки добавить любой необходимый функционал.
И на будущее, использование классов это не есть ООП, не использовать их неразумно. Они удобный для использования(в качестве хранилищ информации), в отличии от парадигм ООП.
Правильно сказали что тут ООП мартышки. Так что продолжать смысла не вижу.
P.S. К сожалению делфи я не знаю, так что похож код на него или нет сказать не могу.
Volfi4, интересно, как ты собрался добавлять нужный функционал? Твоя функция в качестве объекта исцеления принимает только объект класса human. Захочешь исцелить что-то другое - перегружай метод с другими аргументами и копируй туда код. Если совершишь какую-то ошибку в исходной функции, то исправлять ее придется во всех перегруженных копиях. От этого помогло бы избавиться наследование, но ведь парадигмы ООП (лол) так неудобны, правильно? Короче, мартышка тут только одна. Та, которой хватило ума на использование классов лишь для называния кучки переменных одним словом. Так бы и сказал, что просто НИАСИЛИЛ. PS: никто и не говорит, что ООП - единственно верный универсальный путь (на php скорее даже наоборот, правда на этом говне уже давно в одной лишь рашке пишут, лол), но аргументы, которые тут против него приводятся - просто чушь собачья, я такого дерьмища даже от конструкторошкольников не слышал.
Моя функция принимает объект исцеления а не объект класса хуман.
И к вашему сожалению ООП я, как вы выражаетесь, осилил и довольно давно. Благо начинал изучения ЯП не с PHP а с C++.
А вот насчет того что на PHP никто не пишет вы ошибаетесь. И как сказал не безызвестный Бьерн Страуструп "“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется ".
Функциональное программирование смотрит на вас, как на говно(с). Согласен с Stage, все зависит от целей и проекта. Не следует забивать гвозди айфоном, это очень дорого.
