ООП или процедурка?

Справедливо в любом случае. Полные правила нового синтаксиса (хм, новые для интернета, так им вообще-то 15 лет уже) - ещё и каждый блок операторов в скобки обрамлять, даже если он состоит из одной строки.

Весь оффлайн мир программирования к этому уже давно пришел. Пара десятилетий и интернет подтянется ;)

dlyanachalas добавил 07.12.2009 в 01:08

Так это же интернет. Об этом и речь, что в интернете не осилили новые веяния до сих пор)) Со стороны смешно смотрится.

dlyanachalas добавил 07.12.2009 в 01:14

Речь идет о том, что в интернете не осилили даже нормальное форматирование кода ещё. А ТС уже в высокие материи подался - в ООП :)

По-моему, ООП в обычных интернет-страницах на php (которые годятся для создания 99,9% всех сайтов, которые есть в сети) смотрится как корове седло. И хотя при программировании на С++ я использую только ООП, при программировании на php, я его не использовал никогда. И даже не порывался.

Просмотр чужих объектов на php вызывает у меня только улыбку) В С++ такое даже объектами бы постеснялся называть))

Вот я наверное по этому тему и поднял... Поглядел вокруг себя - и не увидел достойного применения для ООП в пхп-вебстроительстве. Хотя в топике приводили такие...

Коля Дубр интересно было почитать... Вот только можно:

Хоть какой-нибудь пример??? А то JS никак вообще в голове с ООП не вяжется.

Это полиморфизм.

И еще раз: хотите поговорить про форматирование кода - создавайте тему, обсудим, что такое "нормальное форматирование".

Может Вы просто не умеете его готовить? А функции-то хоть в php Вы используете? Или goto хватает? :)

Наверное, все-таки классов? И-таки чем сишные объекты правовернее, ну, кроме статической типизации, про которую тоже можно поспорить?

Посмотрите всякие фреймворки. Они только с виду страшные, если поковыряться - много интересного найдете :)

Да любой пример :) Хоть бы вот этот:

и т.д. В окружении веб-сервера это все не имеет смысла, в вебе не нужны объекты, висящие в памяти и ждущие событий, в вебе объекты существуют на протяжении долей секунды, от создания до отдачи клиенту. (Возможны исключения, но с ними нечасто приходится сталкиваться). А в JS всю эту кутерьму как раз можно использовать. Подумайте над архитектурой тетриса, например, как бы Вы его стали реализовывать :)

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

Все примеры - это любая вводная глава по ООП и описание отличий от процедурного подхода. Копипастить?

Более точно будет сказать, что "в интернете не все используют форматирование кода которое Вам нравится". Вы действительно настолько не знакомы с разными стандартами, что считаете скобку на след. строке единственно правильным решением?

Вообще "Холивар" про скобочки порадовал. Мы даже сейчас не будем говорить о том, что оба подхода со скобками имеют право на существование. Но господи боже, переформатировать код под удобное восприятие это 2-3 кнопки в бьютифайере каком-нибудь. Что за прошлый век?:)

Кгм. И каких проблем ждать при засорении глобальной области видимости? Аргумент притянут за уши.

Заводим переменную типа $secure_data и спокойно таскаем ее где надо. Проблем при многократном вызове ровно столько же, сколько при ООП-шном vars::$secure_data->variable1 .

Хотите на процедурке упаковать переменные - да нет проблем, function get_var($variable,$value) { static $vars=array(); и все.

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

И вот здесь Вы нас окончательно испугали. Настоящий специалист не имеет "стандарта" мышления. Он может спокойно пользоваться любым из подходов, выбирая тот, который лучше подходит к конкретной ситуации. А уж если специалист не только не может обоими подходами оперировать, но и с коллегами на тему другого подхода затрудняется общаться, то это вообще какой-то бардак.

Нам трудно отвечать за людей, у которых возникнет такое впечатление:) Из наших слов совершенно не следует, что скрипт в целом будет работать в 3 раза быстрее за счет смены стиля.

Кроме того, мы прекрасно знакомы с аргументом "кривой цикл замедлит все куда быстрее чем стиль кодинга и т.д.". Он неплох для тех, у кого кривые циклы:) Если циклы не кривые, то он уже не действует.

Но мысль мы уловили, требуется развернуть исходную фразу, да?

1) Бенчмарки. Посмотреть бенчмарки не сложно, достаточно взять любой простой класс или любой набор функций, переписать их и протестить оба варианта:) У нас точных цифр сейчас нет, но мы это делали.

2) Абсолютные цифры. Ну, как бы понятно что если класс состоит из 1 функции, которая берет 500мб файл, парсит его и возвращает результат, то особой разницы между процедурками и ооп не будет. Но опять же, какой смысл в таком тесте?

3) Сравнение ооп и процедурок по памяти и скорости. Тут имеет смысл что-то выжимать, если вызывается много раз одна функция и/или класс достаточно объемный. Например небольшой скрипт счетчика (да, мы знаем что для счетчиков и прочего в таком стиле пхп не идеален) изначально был на классах, имел честь кушать 8мб и работать около 0.12секунды. На процедурном подходе стал кушать 4мб и работать около 0.08секунды. Просто за счет тупой смены стиля. С нашей точки зрения это worth it. Понятно что на скрипте типа vbulletin такой разницы от смены подхода не будет, будет допустим 128мб и 1секунда против 126мб и 0.99 секунды:) Но опять же, bottle neck можно учитывать, иногда, в меру, не увлекаясь.

А вот здесь согласимся на все 100. Правда немного с другой стороны.

Яваскрипт, особенно аяксовый, очень хорошо подходит для объяснения сути ООП. Когда на странице 20 объектов кнопка, и к каждому по 3 метода - онклик, онмаузовер и онмаузаут и у каждого набор свойств... то достаточно легко становится понятно зачем нужны объекты "элемент страницы", и набор методов и свойств для них. Это просто логично.

В пхп даже процедурный-то стиль не всегда нужен, иногда достаточно "flat coding". Т.к. редко есть объекты, которые нужны по несколько раз и могут по разному вызываться.

p.s.: больше всего любим зендовский бьютифаер. Во первых он 100%-но встроенный и нажатием одной комбинации делается "всё клево". Во вторых у него нравящиеся нам настройки по умолчанию. Второй из любимых - polystyle, но он standalone и его пришлось долго настраивать, юзаем его т.к. изначально встроен во второй наш любимый иде phped от nusphere.

edogs, я в вас влюблен )

неплохо аргументруете.

я чуток поофтоплю: каким бьютифаером вы пользуетесь? я перепробовал мног опод пхп и не могу найти тчото хорошее, одно гавно, хочется чтото наподобие resharper под vs :D

но изза нестрогой типизации это сложно похоже.

Так, чисто для расширения вашего кругозора - описанный мной стиль программирования рекомендован комитетом ANSI C и Microsoft'ом для своих программистов. ;) Знаете таких?

А кто такой edogs - не знает никто :'( .

dlyanachalas, зря вы так :)

это уважаемый человек в нашей ветке :)

... Какая оптимизация, какие бэнчмарки, вы чо?? Это же обычный php, где 99% времени съедает обращение к базам данных и другим сайтам... :((

Ещё раз - позиция очень проста: бессмысленно запихивать несколько функций, необходимых для вывода страницы в какой-нибудь класс типа "myfuncs".

dlyanachalas добавил 07.12.2009 в 07:26

хм...

Ну-ну ;)

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