[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Злокачественная ООПухоль головного мозга.
twin
Сегодня 1-е апреля и все, что тут написано, можно интерпретировать двояко. Можно принять как шутку, а можно серьёзно задуматься.

История такова. Я, как добросовестный программист, изучил тонкости ООП в теории и часто сталкиваюсь с ним на практике. Но только в рамках чужого кода. Сам никогда не применял этот подход в своих разработках, мне это интуитивно претит. Я имею ввиду не классы, а именно сам подход к проектированию приложений.

Но вот появилась задача написать учебное пособие (ООП для чайников).
И я впал в полную прострацию. Я не могу найти оправдание применению этой парадигмы. Хоть застрели.

Основными доводами, оправдывающими этот подход являются (что смог нарыть в Гугле):
1. Скорость разработки.
2. Поддержка
3. Уменьшение объёма кода.
4. Повторное использование.
5. Расширяемость
6. Эффективность

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

Поддержка Вот одно из высказываний по этому поводу:
Цитата
объектно-ориентированный код легче поддерживать так как
он следует весьма жёстким соглашениям написания кода и пишется в самопоясняющейся форме.
К примеру, когда разработчик дополняет, перерабатывает код, или отлаживает его, он может легко найти внутреннюю структуру кода и поддерживать код время от времени.
полная бредятина. Это где же видано, что ООП было самопоясняющимся? Приложение, написанное в рамках переплетений разных наследований жестоко запутывает следы. На распутывание этих арабесок уходит масса сил и времени, мне по долгу службы это известно очень даже не по наслышке. Последующая поддержка такого кода - сущий ад. Потому что см.п1 - при разработке ставка делалась на скорость, а не на прозрачность кода. Даже комментировать дальше не стану - для меня это аксиома.

Уменьшение объёма кода.
Смотря как и что писать. Гостевая книга, написанная на ООП будет гораздо более объёмна, чем на процедурке. Если проект действительно большой, то можно сэкономить пару сотен строк кода. Разница по различным оценкам может достигать 20-30% в пользу ООП.
Но. Этот довод приводится людьми, у которых уже начались метостазы и они не могут себе представить, что программа может быть написана не единым, неделимым листингом, а локальными участками. Потому что объем кода важен только в оперативной памяти. Для дискового пространства несколько мегабайт памяти - полный пшик. А вот то, что приложение, написанное цельным куском (зачастую в ООП так и делается) грузится в оперативку все - мимо ушей. Так что этот довод так же терпит полное фиаско.

Повторное использование.
Смотри пункт 1. Потому что повторное использование в прямой конфронтации со скоростью разработки. Что бы написать универсальный класс нужно очень много времени. На разработку, тестирование и так далее. Люди, идущие по этому тернистому пути рано или поздно приходят к мысли о написании не универсальных классов, а супер-пупер CMS или фреймворка. И вот тогда рождаются монстры типа джумлы и им подобным. Ни один уважающий себя программист не станет брать за основу чужие разработки целиком, а значит время, потраченное на этот мираж, пойдет коту под хвост. Есть несколько публичных решений, которые действительно облегчают разработку. Тот же PHPmailer или PCLZip или ImageMagick и так далее. Но положа руку на сердце - делал ли кто нибудь наследников от этих классов? Нет. А потому что это не имеет смысла - классы самодостаточны. Так на кой тогда ляд сдался полиморфизм? Именно для того, что бы было нельзя использовать класс вне контекста. Так о каком повторном использовании речь?

Расширяемость
То да. Конечно. Аргумент. Мол классы расширить - раз плюнуть, а вот процедурку раз написал - все. Зацементировалось. Никак не расширить. Полный бред. Больше скажу. Написать расширение на процедурке может гораздо больше народу. чем на ооп. В связи с мутностью последнего. А значит по логике - процедурный подход более расширяем, чем объектный. Так что увы. Некатит.

Эффективность
Этот довод приводят люди, у которых ООПухоль мозга была врожденной. И они вообще не представляют, как работает эта вся схема. Никогда ООП небыло экономичнее и быстрее процедурки. И никогда не будет. Это тоже самое, что делать гоночный грузовик. Да, наш КаМАЗ на Дакаре показал как то, где раки зимуют. Но любая девятка сделает его за милу душу не напрягаясь. Потому что это разные классы машин. Так и тут - неповоротливый ООП подход никогда не будет эфективнее процедурки.

Так вот в свете этих моих умозаключений теперь дилема - писать или не писать этот курс. Вернее писать я буду, но блин, скажите кто нибудь внятно - для чего?

Единственный довод, который я могу как то принять - крутость. Не каждый процедурщик знает ООП, но каждый ООП'ист знает процедурку. Значит он круче по определению.

Фуууух. Спустил пар.







Спустя 27 минут, 38 секунд (1.04.2010 - 09:13) glock18 написал(а):
twin
пора бы уже выучить, что в пхп нет
Цитата (twin @ 1.04.2010 - 05:46)
переплетений разных наследований


Цитата (twin @ 1.04.2010 - 05:46)
С этим не спорят даже самые прожженые мастера ООП.

зато я спорил не раз уже.

Цитата (twin @ 1.04.2010 - 05:46)
Для дискового пространства несколько мегабайт памяти - полный пшик

ага, а работать человек по всей видимости тоже будет с пшиком, а не несколькими мб. ну конечно, это же так мало - поддерживать такую партянку будет проще, чем нормально написанное приложение.

PS:
в общем то, меня уже в свое время достало спорить с тобой об этом каждый раз. приводишь постоянно одни и те же не имеющие под собой почвы доводы.

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

Спустя 7 минут, 58 секунд (1.04.2010 - 09:21) Michael написал(а):
Сегодня 1-е апреля и все, что тут написано, можно интерпретировать двояко. Можно принять как шутку, а можно серьёзно задуматься. smile.gif

Что ни говори сам мир объектен и предметен:
Человек - объект
кошелек в его кармане - объект
10 купюр по 10$ у него в кошельке - 10 объектов
человек что делает - идет (метод)
собака, которую он выгуливает, что делает - бегает(метод)

Когда пишешь программу все эти категории приходится моделировать средствами языка программирования(ЯП). И ищешь конструкции, которые облегчат этот процесс.
Сами только переменные и функции - очень мало и никак не связаны с реальностью. Поэтому уже давно в ЯП были введены объектные конструкции которые облегчают моделирование.
С помощью только процедурного подхода моделировать изначально сложнее и код будет выходить сложнее. Как минимум везде двумерные массивы на входе/выходе функций или захламленное глобальное пространство. И нормальную программу написать сложнее.

Верно написанная на ООП программа должна читаться легко, т.к. ее части отражают реальные элементы системы.

По сути использование объектов - это всего лишь использование более развитых структур данных( процедурный подход остановился на массивах записей, которых часто не хватает).

Спустя 8 минут, 8 секунд (1.04.2010 - 09:29) seine написал(а):
Ого, ну ты даешь) Разбил в пух и прах все доводы))
Я читал, что код в ООП более устойчив к ошибкам и безопасен, чем процедурный. Правда это никак не аргументировалось, а давалось на веру.
Думаю ты и этот довод разнесешь без проблем ;-)

Спустя 1 минута, 31 секунда (1.04.2010 - 09:31) twin написал(а):
Цитата
пора бы уже выучить, что в пхп нет

Это образное высказывание. Но ветвление то есть, а оно ни чем не лучше.

Цитата
ага, а работать человек по всей видимости тоже будет с пшиком, а не несколькими мб. ну конечно, это же так мало - поддерживать такую партянку будет проще, чем нормально написанное приложение.

Ты знаешь - да. Легче поддерживать большую портянку, но когда весь код перед глазами. А в "нормально" написанном приложении реализации разбросаны по файлам и пусть объем меньше, но общую картину представить гораздо проблематичнее, чем увидеть воочию.

Цитата
приводишь постоянно одни и те же не имеющие под собой почвы доводы.

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

Цитата
вообще сильно возражаю против того, чтобы человек ни разу не писавший ооп-код хоть как-то высказывался в таком тоне против самой парадигмы

Да, я ни разу не делал этого. Но для того, что бы знать о вреде наркотиков совсем не обязательно их пробовать. Высказываюсь я не сам по себе, а аккумулируя те доводы, которые приводятся авторитетными людьми. Вот несколько:
Цитата
Стерлинг Хьюз : 
У меня такое чувство, что всё ООП состоит из превращения уже имеющихся задач в новые. И уже только потом дело доходит до их решения. Конечно, такой подход многое упрощает, но он ужасно неэффективен для разработки небольшого набора взаимосвязанных программ, что, собственно, и является сутью программных разработок для Web.

...Я предпочитаю использовать процедурную логику, кроме случаев инкапсуляции сущностей. Другими словами, когда я хочу описать объект, я использую именно объект. Я против того, чтобы использовать ООП для создания огромных, абсолютно абстрактных моделей, вкладывая всю логику в сам объект. 
Такие модели, особенно применительно к Web, получаются намного более сложными сами по себе, чем проблемы, для решения которых они создавались.

Цитата
Эрик. С. Реймонд.
Объектно-ориентированные языки поддерживают создание структур с большим количеством связующего кода и сложными уровнями. Это может оказаться полезным в случае, если предметная область является действительно сложной и требует множества абстракций, и вместе с тем такой подход может обернуться неприятностями, если программисты реализуют простые вещи сложными способами, просто потому, что им известны эти способы и они умеют ими пользоваться.

Цитата

Симдянов И.В
Создать чистые классы - это тяжёлая работа, требующая тщательного проектирования - при создании Web-приложений, часто с очень малыми сроками реализации на это нет времени и вся мощь ООП сводится на нет тем, что код просто не возможно читать. Соблазн срезать на повороте для того, чтобы увеличить эффективность очень велик - программа получается запутанным клубком.

PS Это вовсе не значит, что ООП не следует использовать в PHP, но лично я не видел задач, где бы ООП был эффективнее, чем процедурный подход. Хотя я сам очень люблю OOП и применяю его при программировании на С++, в PHP предпочитаю использовать процедурный подход - код проще, эффективнее, время разработки меньше


Цитата

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


Доводов за объективных нет. По крайней мере я не встречал таких, которые бы выдерживали критики.

Спустя 2 минуты, 28 секунд (1.04.2010 - 09:33) twin написал(а):
Michael
Цитата
Верно написанная на ООП программа должна читаться легко, т.к. ее части отражают реальные элементы системы.

Покажи мне пример - я заткнусь. smile.gif
Я не встречал таких. По крйней мере, что бы читалось легче процедурки.
Разрабатывать - да на первый взгляд проще, но об этом я написал.

Спустя 3 минуты, 26 секунд (1.04.2010 - 09:37) stepan написал(а):
По мне так лучше отталкиваться от поставленной задачи для выбора метода написания.

Спустя 8 минут, 20 секунд (1.04.2010 - 09:45) twin написал(а):
DIII
Цитата
Я читал, что код в ООП более устойчив к ошибкам и безопасен, чем процедурный. Правда это никак не аргументировалось, а давалось на веру.
вот именно. На веру. Потому что аргументировать это нельзя. По большому счету механизмы одни. Можно ошибок наделать и там и там. Нельзя сравнивать, что безопаснее, трамвай или электричка. Ногу оттяпают оба за милу душу.

Спустя 1 минута, 49 секунд (1.04.2010 - 09:47) twin написал(а):
stepan
Цитата
По мне так лучше отталкиваться от поставленной задачи для выбора метода написания.

Разумеется. Если задача стоит написать класс - процедуркой зто сделать можно конечно, но смотреться будет очень глупо.
Речь идет о проектировании приложения в целом. А тут от поставленной задачи ничего не зависит.

Спустя 19 минут, 1 секунда (1.04.2010 - 10:06) glock18 написал(а):
ну да, так и представляю заказчика, который хочет, чтобы ему "класс" написали.

Спустя 6 минут, 24 секунды (1.04.2010 - 10:12) stepan написал(а):
Цитата (twin @ 1.04.2010 - 06:47)
А тут от поставленной задачи ничего не зависит.

Как раз вот это тут нужно первостепенно учитывать.

Спустя 2 минуты, 6 секунд (1.04.2010 - 10:15) stepan написал(а):
Споров по этому поводу было много. Ты сам указал:
Цитата (twin @ 1.04.2010 - 05:46)
Смотря как и что писать.

Я думаю закасчик не скажет - мне нужен календарь написанный на ООП, что бы была возможность из него сделать мега сайт laugh.gif

Спустя 1 минута, 58 секунд (1.04.2010 - 10:17) Michael написал(а):
Цитата (twin @ 1.04.2010 - 08:33)
Покажи мне пример - я заткнусь.  smile.gif
Я не встречал таких. По крйней мере, что бы читалось легче процедурки.
Разрабатывать - да на первый взгляд проще, но об этом я написал.

Так, а конкурс - забыл уже?
Первые 4-е победителя - используют ООП.
Все "проигравшие" - написали на процедурках. Почему? А потому что не рискнули в виду "сложности" сделать что-то серьезное. Да, читается легко, так и сделано немного.

Кстати работа №2 ( самая серьезная процедурками) весьма запутанная.

Спустя 3 минуты, 48 секунд (1.04.2010 - 10:20) Oyeme написал(а):
У начинающего объектного программиста велик соблазн разработать программу в более привычных для него структурных понятиях.

Критериями самооценки своей работы в основном являются корректность, устойчивость и быстродействие программы.
В результате у учащегося формируется недопонимание ООП, возникают трудности с восприятием новых идей в ООП, закладывается основание будущих проблем с проектированием крупных программных систем, проблем его профессионального роста.

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


Разрабатывая проект для банков,оплаты счетов..итд
Без ооп просто не обойтись wink.gif
Я тут говорю о поистине огромных проектах.
Ты создашь в сотни, а то и в тысяч строк лишнего кода,процедурами тут просто не обойтись.

Программа перестала считаться лучше, если в одной 10 строк в другой 50.

Не могу представить себе,когда у тебя десятки ,а то и сотни глобальных переменных biggrin.gif И тебе надо то туда вызавать то туда biggrin.gif

У программирования на объектно-ориентированном языке масса преимуществ, причем это относится не только к созданию более эффективного кода, но и к модификации и расширению возможностей уже имеющихся систем.

Спустя 1 минута, 11 секунд (1.04.2010 - 10:21) twin написал(а):
Цитата
ну да, так и представляю заказчика, который хочет, чтобы ему "класс" написали.

Есть такие.))) Нахватавшиеся верхушек. Обязательным условием разработки ставят ООП парадигму. Им плевать на доводы - нужно чтоб "круто".
Тут stepan прав - никуда не деться. smile.gif
Цитата
Как раз вот это тут нужно первостепенно учитывать.

Учитывать нужно многие факторы. Но если делать не индусские пряности в приступе жажды наживы, а озаботиться возможными последствиями для заказчика, то стоит семь раз отмерять, прежде чем придти к какому то мнению.
У меня пока небыло такого, что бы я не смог убедить заказчика в своей правоте.
Цитата
Так, а конкурс - забыл уже?
Первые 4-е победителя - используют ООП
.
Не путай ООП парадигму и классы как структуру. Я против классов ничего не имею. А вот против длинных наследований - всегда. На конкурсе тоже кстати.
А победили не из за этого. Просто уровень действительно разный. Если бы стаяла задача сделать это только на процедуре - не думаю что расстановка сил изменилась бы.

Спустя 46 секунд (1.04.2010 - 10:22) glock18 написал(а):
Michael
да ты чее, смотри, щас твин скажет, что эти работы придерживались не ооп, а его парадигмы... ща, погодь тока чуток.

Аччерт, он написал быстрее. Ладно, оставлю так, я знал.

Спустя 2 минуты, 39 секунд (1.04.2010 - 10:25) stepan написал(а):
Michael Вот про это можно по подробней. Я не зря указал что жури нужно строже быть, и не зря я написал на процедурном - в задании было указанно вот что:
Цитата
совместимость c разными версями PHP.

А теперь берем и смотрим все конкурсные работы в PHP 4 ...
Но речь не об этом dry.gif

Спустя 3 минуты, 17 секунд (1.04.2010 - 10:28) twin написал(а):
Oyeme
Куда ты попер? Я разве что то говорил против парадигмы в целом? В прикладном ПО это очень полезная весчь.

Я говорил исключительно про веб-технологии. А тут уж извини, твои доводы мимо кассы.
Или ты хочешь сказать, что громадные проекты типа гугла, одноклассников или им подобным разработаны как единое целое? Чушь.

И вообще, это самый большой флаг, которым размахивают аппологеты - "громадные проекты".

Назови мне хоть один, в котором ты принимал участие.
Я уверен, что 99,99% сдесь собравшихся знают о таких только из книжек.
Нет таких проектов в вебе. Не существует. Любой большой проект разнесен по разным программам и даже серверам.

Не катит.

Спустя 5 минут, 50 секунд (1.04.2010 - 10:34) glock18 написал(а):
Цитата (twin @ 1.04.2010 - 07:28)
Я уверен, что 99,99% сдесь собравшихся знают о таких только из книжек.

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

Спустя 4 минуты, 33 секунды (1.04.2010 - 10:39) Oyeme написал(а):
twin
Любую можно wink.gif

Скажем тебе сказали написать программу свзанную с потоками перевозок грузов.
Ну ты же не будешь писать программу на ассамблере?. wink.gif
Никто не говорить что нельзя - просто не разумно laugh.gif

Я тебе в приват напишу. wink.gif

Спустя 25 секунд (1.04.2010 - 10:39) glock18 написал(а):
Oyeme
вещь говоришь, а ты твин прекрати всем тыкать их недостаточной крутостью. это не кул. приводи нормальные доводы, а не

Цитата (twin @ 1.04.2010 - 07:28)
И вообще, это самый большой флаг, которым размахивают аппологеты - "громадные проекты".


Цитата (twin @ 1.04.2010 - 07:28)
Назови мне хоть один, в котором ты принимал участие.
Я уверен, что 99,99% сдесь собравшихся знают о таких только из книжек.

это еще круче. откуда у тебя такая уверенность? ты что, всех тут знаешь? знаешь чем они занимаются в "свободное от форума время"??

Цитата (twin @ 1.04.2010 - 07:28)
Или ты хочешь сказать, что громадные проекты типа гугла, одноклассников или им подобным разработаны как единое целое? Чушь.


это еще один пункт из общей картины идиотизма. и еще один момент, показывающий твое непонимание ооп в принципе. как то не вижу ничего общего между "ооп" и "разработаны как единое целое".. ха-ха.

Спустя 39 секунд (1.04.2010 - 10:40) Michael написал(а):
Цитата (twin @ 1.04.2010 - 09:21)
Не путай ООП парадигму и классы как структуру. Я против классов ничего не имею. А вот против длинных наследований - всегда. На конкурсе тоже кстати.

Ну как же, те кто весь функционал инкапсулировали в классе уже используют парадигму ООП (не учитывая конечно работу дедушки мороза smile.gif ) .

А с чрезмерным наследованием, я что не согласен ? Согласен. Да и в книге четырех тоже про это говорят.

Цитата (twin)
А победили не из за этого. Просто уровень действительно разный. Если бы стаяла задача сделать это только на процедуре - не думаю что расстановка сил изменилась бы.


Очень даже могла измениться.

Цитата (stepan)
А теперь берем и смотрим все конкурсные работы в PHP 4 ...

та ну, такое скажешь, может еще и в PHP 3.




Спустя 12 минут, 4 секунды (1.04.2010 - 10:52) stepan написал(а):
Цитата (Michael @ 1.04.2010 - 07:40)
та ну, такое скажешь, может еще и в PHP 3


Пункт указан значит нужно его соблюдать

Спустя 1 минута, 37 секунд (1.04.2010 - 10:53) twin написал(а):
Цитата (glock18 @ 1.04.2010 - 07:34)
Цитата (twin @ 1.04.2010 - 07:28)
Я уверен, что 99,99% сдесь собравшихся знают о таких только из книжек.

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

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

PS вижу - возразил. Но как обычно в стиле "бугага, ты не знаешь всех тайн, а я вот мол плавал"
Конкретнее можно?

Я скажу конкретнее.
Коли не писать программу целиком, весь смысл парадигмы теряется. Ты можешь конечно написать кучу базовых классов, нарожать от них потомков, рассовать по файлам и считаеть это верхом девелопинга. Полный маразм.
То же самое, только на порядок проще и прозрачнее можно сделать процедурно.
Цитата
это еще круче. откуда у тебя такая уверенность? ты что, всех тут знаешь? знаешь чем они занимаются в "свободное от форума время"??

Я более чем уверен, что никто из собравшихся не имеет отношения к таким проектам, которые по заверениям ярых популяризаторов имеют статус "громадный" Потому что таких в природе нет. Есть идиотские, но они только подтверждают правило как исключения.

Спустя 15 минут, 24 секунды (1.04.2010 - 11:09) twin написал(а):
Цитата
Oyeme
вещь говоришь, а ты твин прекрати всем тыкать их недостаточной крутостью. это не кул. приводи нормальные доводы,
не заметил там вещей. и не тыкал я никого, наоборот. Считаю что гордиться тут нечем. Применение ООП везде где ни поподя - это не крутость, это именно та ООПухоль, которая в сабже.Доводы я привожу конкретные, куда еще то... А вот против пока нормальных не вижу.

Спустя 2 минуты, 21 секунда (1.04.2010 - 11:11) Michael написал(а):
Вот twin веселится как на праздник то laugh.gif

Спустя 4 минуты, 37 секунд (1.04.2010 - 11:16) glock18 написал(а):
до сих пор не понимаю, почему используется именно слово "громадные". очевидно, что любой громадный проект размеров гугла уже курил бы в сторонке, будь он выполнен без ооп. потому речь вовсе даже не об огромных проектах, а проектах средних и больших размеров с листингом в 100-200 тысяч строк кода. 

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

Спустя 19 минут, 26 секунд (1.04.2010 - 11:35) twin написал(а):
Я не допускал никаких концептуальных ошибок.
Ошибку допускаешь как раз ты и тебе сочуствующие.
Я просто пытаюсь найти оправдание тому, что привнесено в PHP извне, под давлением людей, лоббирующих фреймворки.

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

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

Так что доводы свои по поводу моего неправильного понимания оставь на случай, если я начну хаять парадигму в сях к примеру. Но не дождешься. smile.gif

Спустя 36 минут, 10 секунд (1.04.2010 - 12:11) glock18 написал(а):
парадигме вообще по барабану что за язык. то что пых слабенький для нее - естественно большой проект будет требовать многого. но из этого тоже есть выходы.

ооп 4й пыхи вообще отдельная история, и ее точно эффективной никак нельзя было назвать. а ошибку ты допустил, более того, я тебе ее указал выше.

Спустя 14 минут, 47 секунд (1.04.2010 - 12:26) Mizka написал(а):
Цитата
Абсолютно уверен, что гугл написан никак не на PHP. Это же касается и всех остальных, более менее крупных проектов. Потому что как только проект становится действительно крупным, PHP теряет актуальность.

Цитата

Но поперло - давайте замутим как у всех - наследования, абстракции... Глюки и муть.

Возможно это и делалось как раз для того что-бы PHP не позиционировался дальше как язык для писателей сайтов визиток и средних проектов, а мог выйти на уровень с JSP, ASP.NET (что достаточно сомнительно)?

Спустя 5 минут, 32 секунды (1.04.2010 - 12:32) twin написал(а):
Цитата
парадигме вообще по барабану что за язык

Парадигме да, а вот языку нет.
Весь этот сыр бор из за чего.
Я начал уже давно писать про ООП в PHP. Тут. И если до полиморфизма я как то еще выкручивался, описывая подходящими примерами эти явления, то вот интерфейс описать не могу.
Вернее могу конечно, но никак не могу найти достойный пример, где действительно он был бы нужен. Ведь это заплатка. А заплатка пришивается на дырку. А я стараюсь учить так, что бы не было дыр.

Именно в PHP классическая парадигма и является злокачественной опухолью. Потому что не имеет смысла - раз, реализована криво - два.

Вот и вопрос - а стоит ли вообще заниматься популяризацией?
Пока ответ для меня очевиден. ООП в классическом понимании для PHP - зло.

И очередное отсутствие каких либо внятных обоснований его присутствия я не вижу ни тут, ни где бы еще.
Тайно надеялся, что меня натычут носом. Не судьба.

Цитата
Возможно это и делалось как раз для того что-бы PHP не позиционировался дальше как язык для писателей сайтов визиток и средних проектов, а мог выйти на уровень с JSP, ASP.NET (что достаточно сомнительно)?

Да не надо ему туда, есть своя ниша и вполне достаточно. Нельзя объять необъятное.

PS Кстати, вот последний проект, который я сейчас переписываю с жутких блудолистингов на процедурку. Кода там гораздо больше, чем 200 т. строк как оказалось. Я просто раньше их никогда не считал.
Это считается крупным или средним проектом?

Спустя 8 минут, 13 секунд (1.04.2010 - 12:40) Mizka написал(а):
Мне кажется не корректно считать крупность проекта по количеству строк. Тут наверно лучше смотреть на задачу проекта, его бизнес план, перспективы расширения, затраченные ресурсы...

Спустя 5 минут, 6 секунд (1.04.2010 - 12:45) Mizka написал(а):
Цитата
то вот интерфейс описать не могу.

что именно в твоем понимании есть описать интерфейс? описание возможностей работы с конкретною сущностью (объектом или классом)?

Спустя 4 минуты, 18 секунд (1.04.2010 - 12:49) twin написал(а):
Цитата
Мне кажется не корректно считать крупность проекта по количеству строк. Тут наверно лучше смотреть на задачу проекта, его бизнес план, перспективы расширения, затраченные ресурсы...


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

Спустя 2 минуты, 1 секунда (1.04.2010 - 12:51) twin написал(а):
Цитата
что именно в твоем понимании есть описать интерфейс? описание возможностей работы с конкретною сущностью (объектом или классом)?

посмотри, в каком ключе я описал допустим то же наследование.
Для интерфейса кроме заплатки никаких ассоциаций не нахожу. sad.gif

Спустя 1 минута, 40 секунд (1.04.2010 - 12:53) sergeiss написал(а):
Эка вас как всех плющит-то....

Спустя 57 минут, 18 секунд (1.04.2010 - 13:50) Mizka написал(а):
Цитата
посмотри, в каком ключе я описал допустим то же наследование.
Для интерфейса кроме заплатки никаких ассоциаций не нахожу. 

Ну и повесть на домиках:).
Возможно так и задумано, но чуть исправлю так как твоя статья о наследовании, вот к примеру:

class Crazy_party extends Kinder_garten
{

...

protected function drinkBeer()
{
return $this->beer;
}
}


class Cold_cellar extends Crazy_party
{
public function drinkBeer()
{
return 'Ураа, '. parent::drinkBeer() .'!' ;
}
}

Твой пример не совсем хороший, так как это демонстрация overrid-а метода родительского класса, а суть наследования, что объект класса Cold_cellar и так может вызывать метод drinkBeer(), даже если бы ты не переопределил его в Cold_cellar классе.

Спустя 17 секунд (1.04.2010 - 13:50) Michael написал(а):
Цитата (twin @ 1.04.2010 - 11:32)
Кода там гораздо больше, чем 200 т. строк как оказалось. Я просто раньше их никогда не считал.

Может все таки поменьше? Или это на основе какой-то cms/cmf и ты этот код посчитал?

Спустя 8 минут, 50 секунд (1.04.2010 - 13:59) twin написал(а):
Цитата
Твой пример не совсем хороший, так как это демонстрация overwrit-а метода родительского класса, а суть наследования, что объект класса Cold_cellar и так может вызывать метод drinkBeer(), даже если бы ты не переопределил его в Cold_cellar классе.

Мой пример просто очень прост. Я все там и писал для того, что бы дать толчек. А дальше хоть трава не расти. Я лично для себя не вижу причин использовать это на практике)))
Хотя если сможешь сделать такой же простой и грамотный пример - не откажусь. smile.gif

Цитата
Может все таки поменьше? Или это на основе какой-то cms/cmf и ты этот код посчитал?

Я не считал конечно. Простой прикидкой. 104 папки в среднем по 20 файлов в каждой, в среднем по 300 строк кода в файле уже 600 000. Ну пусть я ошибся в 2 раза, все равно больше.

Спустя 11 минут, 2 секунды (1.04.2010 - 14:10) Mizka написал(а):
ну вот к примеру:

abstract class Show{

public $message;

public function showMessage()
{
echo $this->message;
}

}


class SMessage extends Show
{

public function setMessage($str)
{
$this->message = $str;
}

}


//example of usage
$obj = new SMessage();
$obj->setMessage('Hello world');
$obj->showMessage();

Спустя 6 минут, 57 секунд (1.04.2010 - 14:17) twin написал(а):
Нееет. smile.gif Это слишком академично. И черезчур просто. К тому же совершенно бессмысленно. В том и затык, что бы найти хоть какую то пользу в этом.

Спустя 32 минуты, 33 секунды (1.04.2010 - 14:50) Mizka написал(а):
ну вот к примеру разрабатываешь ты онлайн игру, в ней есть несколько персонажей, так же есть действия которые могут исполнять все персонажи (ходить, летать, жрать...), а так же каждый вид персонажа имеет какие-то особые навыки, так вот... в базовом классе описываешь действия, которые могут делать все игроки, а в его потомках описываешь уже дополнительные действия для каждого типу персонажа, так создав экземпляр чайлд класса, каждый будет обладать и своими конкретными навыками и общими... вот тебе пример на реальном проекте с пользой smile.gif

Спустя 19 минут, 44 секунды (1.04.2010 - 15:10) twin написал(а):
Не понял я сначала. Все там верно у меня. Просто ты не читал или не вник. Я на этом примере показал, как работают доступы к методам. В родитенльском классе метод drinkBeer() имеет уровень protected, а в дочернем public
Этот пример для демонстрации инкапсуляции. Этот метод не может быть вызван снаружи, а может быть только переопределен или вызван из наследника.

А персонажи - дело конечно хорошее, только слово "наследование" больше подходит к "наследству", чем к ходить, летать, жрать. smile.gif

Спустя 8 минут, 55 секунд (1.04.2010 - 15:19) sergeiss написал(а):
twin - твою бы энергию, да в мирных целях... Вон в том же С++Билдер - одни только классы сплошь и рядом. И цепочки наследований куда длиннее, деревья родственников куда ветвистее.... wink.gif Изучай!

Спустя 6 минут, 1 секунда (1.04.2010 - 15:25) twin написал(а):
Изучаю помаленьку)) Там таки да - это имеет смысл. Глупо было бы писать прикладное по процедурой, когда давно уже разработаны все нужные библиотеки.
Но тут совсем другое дело. smile.gif

Спустя 7 часов, 2 минуты, 57 секунд (1.04.2010 - 22:27) krasilich написал(а):
Немогу прочитать тему полностью. Мозги кипят... А кипят они от того, что я наконец-то пошел на работу. И вот по работе мне нужно работать с кодом, который написан на "чистом" ООП (даже за использование массивов ругают, насколько я понял). Код с использованием паттернов. Так вот, одно из "замечательных" свойств системы, это то, что она позволяет инстанциировать n-ое количество синглтонов=)) И не то что бы это была ошибка проектирования, или что-то не то накодили. Все ок. Просто есть способы вот так вот сделать=))
И это далеко не все. Так как это только первый рабчий день, и мне пообещали еще много чего интересного=)

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

ИМХО.

Спустя 10 минут, 48 секунд (1.04.2010 - 22:38) Joker написал(а):
Вроде эксперты а спорят из за какого то ООП как дети малые) Ведь все ровно каждый из вас останется при своём мнении.

Спустя 4 минуты, 1 секунда (1.04.2010 - 22:42) twin написал(а):
krasilich

Я вас умоляю. biggrin.gif
Все читать и не нужно было, достаточно этого в первом топике:
Цитата
Да, можно было бы с этим согласиться. Но только в том случае, если пишется чистая парадигма. Как в Си. То есть когда можно взять любой класс из написанной программы и вставить его в другую.
или это из цитат
Цитата
Создать чистые классы - это тяжёлая работа, требующая тщательного проектирования - при создании Web-приложений

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

Спустя 6 минут, 11 секунд (1.04.2010 - 22:48) Joker написал(а):
Хотите конкурс?) делается просто ставиться задача и она реализуется двумя группами (людьми) и после критерии кто быстрее сделал, у кого меньше ресурсов жрет, и после на основе этой работы сразу вторая изменить то то то... и из этого будет последняя оценка чью работу быстрее изменить под новые нужды слабо на спор такой конкурс, хоть весело будет. а то все чот говорят чот говорят а на примере докажите, проигравший соглашается что способ победителя лучше.

Спустя 5 минут, 39 секунд (1.04.2010 - 22:54) twin написал(а):
Кстати, я таки придумал пример для интерфейсов. Поправьте плиз, если я ошибаюсь:

Сначала, как водится, пример из жизни. Вот ситуация. Допустим опытный и очень занятой программист всю ночь играл в кваку работал над проектом. И его подающий надежды сын ему помогал. Как только забрезжил рассвет, оба обессиленные, но с чуством исполненного долга, свалились спать.

А утром жена, собираясь на работу, оставляет такую записку:
Цитата
Оболтусы, как проснетесь:
1. Убрать носки из под дивана
2. Съесть котлеты на плите
3. Помыть за собой посуду


Ей не важно кто и как это будет делать. Ей важно, что бы все было реализовано.
Вот квартира - это базовый класс. Оболтусы - производные классы. А жена - интерфейс. Она определяет то, что обязаны выполнить её чада. Заметьте - она ничего не делает сама и не дает подробных инструкций. Ей не важно, кто как будет есть котлеты. Гретые или холодные. Она просто раздает абстрактные задания, невыполнение которых повлечет неминуемый варнинг.

Спустя 1 минута, 47 секунд (1.04.2010 - 22:56) twin написал(а):
Joker
Это спор риторический и абстрактный. Доказательства тут невозможны. Слишком много побочных факторов. Скорость набора текста, свободное время и так далее.
Тут можно рассуждать только теоретически.

Спустя 1 минута, 17 секунд (1.04.2010 - 22:57) krasilich написал(а):
Нехочу я такую жену, с варнингами... особенно если котлеты не сьедены...

Спустя 1 минута, 31 секунда (1.04.2010 - 22:59) twin написал(а):
Дык и я не хочу... А куда деваться. biggrin.gif
ООП оно и в браке ООП.
Одни неприятности. laugh.gif

Спустя 5 минут, 59 секунд (1.04.2010 - 23:05) Joker написал(а):
Цитата (twin @ 2.04.2010 - 00:56)
Тут можно рассуждать только теоретически.


да ладно сказки то рассказывать, испугались вы все smile.gif

Спустя 5 минут, 40 секунд (1.04.2010 - 23:10) krasilich написал(а):
Да, испугались. Все равно победит дружба. Как и во всех наших конкурсах=))

Спустя 1 минута, 2 секунды (1.04.2010 - 23:11) Joker написал(а):
Цитата (krasilich @ 2.04.2010 - 01:10)
Все равно победит дружба. Как и во всех наших конкурсах=))


Поэтому и странно, всегда дружба а боитесь))) может вы дружить друг с другом не хотите?)

Спустя 1 минута, 16 секунд (1.04.2010 - 23:13) krasilich написал(а):
Мы ж программисты, елки-палки, какой дружить, ты шо....

Спустя 7 минут, 27 секунд (1.04.2010 - 23:20) twin написал(а):
Никит, а вот ты сам взял бы и создал экспертную комиссию.
Не только из экспертов, а так называемую фокусную группу. И провел бы сравнительный анализ. Независимую экспертизу.
Разработку оставим за кадром, я лично считаю этот параметр не самым важным. Даже если и есть разница по времени, она несущественна. А вот остальные критерии да.
На этом форуме есть гостевая книга от glock18. Моя на процедурке тут
Обозначь критерии оценки, создай экспертную комиссию и в путь.
Сам просил недавно интересного и полезного дела.

Спустя 8 часов, 55 минут, 59 секунд (2.04.2010 - 08:16) phz написал(а):
Чуть не в тему. Можно ссылку на гостевая книгу glock18, не могу найти не как.

Спустя 2 минуты, 9 секунд (2.04.2010 - 08:18) twin написал(а):

Спустя 3 минуты, 23 секунды (2.04.2010 - 08:22) phz написал(а):
Дякую

Спустя 1 час, 31 минута, 15 секунд (2.04.2010 - 09:53) Mizka написал(а):
Цитата
Не понял я сначала. Все там верно у меня. Просто ты не читал или не вник. Я на этом примере показал, как работают доступы к методам. В родитенльском классе метод drinkBeer() имеет уровень protected, а в дочернем public
Этот пример для демонстрации инкапсуляции. Этот метод не может быть вызван снаружи, а может быть только переопределен или вызван из наследника.

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

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

Попытайся сам вникнуть чуть глубже во все это, а потом пересмотришь свои взгляды.. п.с. я не утверждаю, что они изменяться smile.gif

Спустя 1 час, 7 секунд (2.04.2010 - 10:53) twin написал(а):
Да не в том дело, что ООП плох. Я этого никогда и не говорил. Я всегда говорил одно:
В веб-технологиях (особенно в PHP) ООП ничем не лучше процедурки. А зачастую гораздо хуже. Под ООП я понимаю именно Объектно Ориентированное Программирование. То есть программирование, полностью сориентированное на использование объектов и ничего другого.
Я не против классов как таковых, я против того мегабреда, который получается в результате попыток сделать крутую объектно ориентированную программу.
Цитата
А если вернуться к пониманию интерфейса работы, то это с использованием на практике приходит, и как-бы взгляд тогда на все это совсем другой становиться.

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

По поводу интерфейсов - написал таки. smile.gif

Спустя 7 минут, 18 секунд (2.04.2010 - 11:00) twin написал(а):
Oyeme
Цитата
Разрабатывая проект для банков,оплаты счетов..итд
Без ооп просто не обойтись
Я тут говорю о поистине огромных проектах.
Ты создашь в сотни, а то и в тысяч строк лишнего кода,процедурами тут просто не обойтись.

А ну ка, чтоб не быть голословным, накидай ка примерчик, где я не смог бы обойтись процедуркой.
Я съем свою шляпу, если не сделаю тоже самое процедурно, используя меньший объем кода.

Спустя 55 минут, 34 секунды (2.04.2010 - 11:56) DedMorozzz написал(а):
Цитата
1. Убрать носки из под дивана
2. Съесть котлеты на плите
3. Помыть за собой посуду

В случае интерфейса, это должен реилизовывать каждый, если я не ошибаюсь, а не сумарно что бы было реализовано. пускай кто-то выполнит 0%, но он должен эти 0% так или иначе выполнить. Ибо он имплементирует интерфейс этот

Спустя 7 минут, 56 секунд (2.04.2010 - 12:04) twin написал(а):
Там вроде так и написано... Покажи, что трактуется неоднозначно плиз

Спустя 2 минуты, 59 секунд (2.04.2010 - 12:07) DedMorozzz написал(а):
Цитата
Ей не важно кто и как это будет делать. Ей важно, что бы все было реализовано.
Т.е. Отец ест котлеты(кто), а как - холодными. А сын моет посуду, мочалкой. Все таски выполнены. Но при этом отец не мыл посуду, ну и так далее...

Спустя 2 минуты, 12 секунд (2.04.2010 - 12:09) twin написал(а):
Сеньк. Действительно неоднозначность))) слово всеми пропустил.

Спустя 1 минута, 15 секунд (2.04.2010 - 12:10) twin написал(а):
Ан нет. Вот дословно
Цитата
Ей не важно как они это будет делать. Ей важно, что бы все было реализовано обоими и в полной мере.

Спустя 7 минут, 18 секунд (2.04.2010 - 12:18) DedMorozzz написал(а):
Странно у мну так:

Спустя 2 минуты, 52 секунды (2.04.2010 - 12:20) twin написал(а):
А, так ты не там смотришь))) Вот тут полная версия.

Спустя 10 минут, 10 секунд (2.04.2010 - 12:31) DedMorozzz написал(а):
Цитата
что бы все было реализовано обоими и в полной мере.
Мысли о птичках: А разве обязательно в полной мере? smile.gif можно веть сделать 0% и всё будет норм. Т.е. просто описать пустую ф-ю. Мол отец с сыном договорились, надо сделать то-то и то-то, мол придёт проверит. В результате сын мыл полы, а отец посуду. А при этом скажут что они ВМЕСТЕ убирались.
Это про "в полной мере"

Спустя 12 минут, 54 секунды (2.04.2010 - 12:43) twin написал(а):
Ну мысль. Спасибо. smile.gif

Спустя 3 часа, 32 минуты, 48 секунд (2.04.2010 - 16:16) twin написал(а):
Не могу успокоиться. biggrin.gif
Как хорошо, что я начал писать этот курс. Одно дело - читать учебники и принимать все на веру. Другое - попытаться самому объяснить происходящее.

Сейчас, описывая интерфейсы, понял одну вещь, с которой сам не сталкивался, и о которой стеснительно умалчивается в учебниках.

Вот Michael привел классическое описание объектной структуры
Цитата
Что ни говори сам мир объектен и предметен:
Человек - объект
кошелек в его кармане - объект
10 купюр по 10$ у него в кошельке - 10 объектов
человек что делает - идет (метод)
собака, которую он выгуливает, что делает - бегает(метод)

Так примерно везде и пишут. Подозреваю, что копипастят просто друг у друга.
Но это очень некорректное сравнение. Это попытка описать сферу на плоскости. Мир намного многограннее. И программы тоже.

А вот такая структура:
Объект - человек.
Свойства - руки, ноги, голова.
Метод - танцует.

женщина extends человек

красавица extends женщина
умница extends женщина

Объект - программист
Свойства - логика, знания, терпение
метод - пишет программы

phpпрограммист extends программист
Postgreпрограммист extends программист


Вопрос. Как теперь описать olgatcpip, умную, красивую женщину, которая пишет программы на php и Postgre? А в перерывах еще и неплохо танцует?

Может я чего непонимаю, только на процедуре я сделаю это тремя строчками, а как тут на хваленой парадигме? Гибкой и удобной?

Спустя 3 минуты, 47 секунд (2.04.2010 - 16:20) glock18 написал(а):
в пыхе нет множественного наследования, но в парадигме есть. так что
Цитата (twin @ 2.04.2010 - 13:16)
а как тут на хваленой парадигме? Гибкой и удобной?


все элементарно. в пыхе, конечно, все получится не так просто.

Спустя 1 минута (2.04.2010 - 16:21) DedMorozzz написал(а):
Цитата
женщина extends человек
хм....разве? Чёт обычно они не наследуют всех качеств)))

Спустя 3 минуты, 59 секунд (2.04.2010 - 16:25) twin написал(а):
В том и дело, что все не надо. А ведь придется. Потому что никак по отдельности. biggrin.gif

Спустя 5 минут, 11 секунд (2.04.2010 - 16:30) twin написал(а):
glock18
Цитата
в пыхе нет множественного наследования, но в парадигме есть.

Если ты еще не обратил до сих пор внимание, повторю. Я рассматриваю ООП парадигму применительно к PHP Остальное меня сейчас волнует мало.
Цитата
все элементарно. в пыхе, конечно, все получится не так просто.

Что и требовалось доказать. То есть все заявления, что процедурный подход все усложняет, а объектный упрощает - фикция.
А так же профонация - гибкость объектного подхода. Чем дальше я пытаюсь раскопать, тем интереснее всплывают факты.

Очень мне повезло с наставником, сразу сказал - плюнь на эти условности. smile.gif

Спустя 7 минут, 38 секунд (2.04.2010 - 16:38) glock18 написал(а):
Анннеее. что это за

Цитата (twin @ 2.04.2010 - 13:25)
В том и дело, что все не надо. А ведь придется. Потому что никак по отдельности.


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

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

Спустя 14 минут, 8 секунд (2.04.2010 - 16:52) twin написал(а):
Цитата
в том, что и от чего и почему и состоит проектирование

Не катит. Вопрос глубже - не в проектировании, а в расширяемости. Да и проектировать большой ресурс тоже не так то просто. Ты Гугл в пример приводил. Мол если бы не ООП, они бы курили бамбук. А вот представь, объект "человек" для своих нужд проектирует нью-йоркский офис. А объект "женщина" - московский. Им такое доверять нельзя, все красавицы у нас. smile.gif

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

Вот. К чему я и вел все это время. Классы хороши только как пространства имен. Я и говорил сто раз об этом. И сам активно использую.
А вот всякие наследования и прочая муть (парадигма в контексте) - зло.
Отсюда и сабж ЗЛОкачественная ООПухоль. smile.gif

Спустя 42 минуты, 39 секунд (2.04.2010 - 17:35) HardWoman написал(а):
Прошу меня не бить. пытаюсь разобраться с наследованием. В свое время столкнулась по моему мнению с очень тяжелым проектом. Некая поисковая система/доска объявлений - очень большая детализация и колосальное количество путей необходимых в сортировке по поиску.

Порядка 50 тематических направлений, каждое с разным уровнем вложенности массивов и различному количеству сортировк по дополнительным сущностям.

Самая большая сложность состоит в том, Что не просто к каждому массиву может принадлежать некий метод и свойство, но и конкретному элементу массива может принадлежать некоторое собственное свойство. И если учесть, что в массиве может быть до 200 элементов и к каждому свои свойства и методы. И то что по идее связи, которые мне бы надо бы хранить в базе - описываются как класс с последующим расширением. В результате я получаю колосальную простыню, где родительский класс - Доска объявлений, и собственно специфические элементы массива, тоже описываются как классы.

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

Спустя 4 минуты, 1 секунда (2.04.2010 - 17:39) DedMorozzz написал(а):
Цитата
Ведь я правильно понимаю, что код работает в пределах одного файла и не подключает классы, хранимые в других файлах?
Автоматически - нет, но такие решения существуют, к примеру класс Autoloader, но там нужно соблюдать название файлов и классов, так называемое "соглашение ПЕАР"

Спустя 57 минут, 55 секунд (2.04.2010 - 18:37) Adil написал(а):
Почему тишина? Вы еще не окончили спорить, а мне так интересно за чашечкой чая читать этот спор) Каков окончательный вердикт?)

Кстати меня всегда интересовал один вопрос, точнее кто как считает.

Писать классами, можно считать писать ООП? Просто используя классы как контейнер для функций, без наследований,полиформизма и т.д.?

P.S. ИМХО: впрочем классы, составляющая ООП, но с другой стороны это не ООП.

Спустя 31 минута, 51 секунда (2.04.2010 - 19:08) twin написал(а):
Принято делить программирование на парадигмы. Хотя тут и кроется самое большое зло. Нельзя разграничивать эту сферу. От того и споры вечно.

Парадигм условно три.
1. Императивное (в обиходе - быдлокодинг. когда код идет одним потоком)
2. Функциональное (когда программа делится на функции)
3. Объектно ориентированное.

По эволюции ООП стоит на последнем месте, что часто приводит веб-программистов к неверному выводу, что ООП это вершина мироздания.

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

На самом деле самый оптимальный вариант - комбинировать все три. Но тут нужно расставить приоритеты.
От того и весь холивар.

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

Если действие не очень сложное, но повторяющееся, однозначно нужно описать его функцией.

Если действий несколько в одном флаконе - разумеется класс.

А вот механизмы наследования и полиморфизма использовать нужно очень аккуратно, иначе можно так набуробить, что не разгрести до второго пришествия.

Лично я (и не только) считаю - им вообще не место в PHP. От них одни неприятности.

Спустя 2 часа, 40 секунд (2.04.2010 - 21:09) sergeiss написал(а):
Цитата (Adil @ 2.04.2010 - 19:37)
Писать классами, можно считать писать ООП? Просто используя классы как контейнер для функций, без наследований,полиформизма и т.д.?

Как уже неоднократно заметил twin в этой и в других темах smile.gif, писать надо так, чтобы было максимально функционально и эффективно, удобно и понятно для программера.
Я тоже для себя выработал такой подход к программированию еще до того, как начал ПХП заниматься. И перенес его на ПХП.
Поэтому те же классы иногда использую как структуры на Си. То есть, как удобное хранилище для сложных наборов данных. Иногда чистое хранение, а иногда и с мелкими функциями для обработки данных. Ну, а иногда и не с мелкими функциями smile.gif - то есть как класс, но без наследования.

Короче говоря, не надо уподобляться Эллочке-людоедочке "ах, в Париже ЭТО уже не носят!" smile.gif А надо делать так, как эффективно.

Спустя 26 минут, 4 секунды (2.04.2010 - 21:35) Семён написал(а):
Ребят к чему весь этот холивар? На мой взгляд без разницы как писать, главное чтобы это работало быстро и без ошибок.

Спустя 3 минуты, 37 секунд (2.04.2010 - 21:39) sergeiss написал(а):
Цитата (Семён @ 2.04.2010 - 22:35)
Ребят к чему весь этот холивар?

А поговорить? wink.gif

Спустя 1 минута, 9 секунд (2.04.2010 - 21:40) krasilich написал(а):
Цитата (Семён @ 2.04.2010 - 20:35)
Ребят к чему весь этот холивар? На мой взгляд без разницы как писать, главное чтобы это работало быстро и без ошибок.

В том-то и дело, что функции работают медленно и с ошибками, а twin этого не понимает=)

Спустя 18 минут, 31 секунда (2.04.2010 - 21:58) twin написал(а):
biggrin.gif

Спустя 23 часа, 26 минут, 59 секунд (3.04.2010 - 21:25) krasilich написал(а):
Кстати, трушное ООП действительно работает без ошибок.
Там программы вываливаются с эксепшенами=)

Спустя 10 минут, 50 секунд (3.04.2010 - 21:36) twin написал(а):
Цитата
Там программы вываливаются с эксепшенами=)

Это не значит что ошибок нет. smile.gif
А трушки твои тормозят неподецки. Лучше учиться писать аккуратно, чем на них надеяться. В ключевых местах никто не запретит и свой дебаггинг делать.

Спустя 59 минут, 43 секунды (3.04.2010 - 22:36) Гость_vtos написал(а):
Ребят, всем здравствуйте!
Ну а что мешает сочетать оба подхода - процедурный и объектный?
Допустим, есть страница, которая требует постраничной навигации. Практически на любом сайте есть "постраничка". Взяли и разработали класс с постраничной навигацией, воткнули объект этого класса на нашу страничку. Все остальное можно написать на "процедурке" - ради Бога!
А потом при следующей разработке, взяли объект этого же класса и воткнули в уже новую разработку - главное, этот самый класс с постраничкой разработать так, чтобы его можно было воткнуть на любой сайт без какого-либо изменения кода этого класса вообще.
А остальные "потроха" сайта (или другого web-приложения) пишите в процедурном стиле, особенно, если сайт не сложный совсем! Точно так же можно поступить с объектом "хлебных крошек" - этот объект можно тоже на любой сайт втыкать. То есть в участки кода, написанного процедурно, можно вставлять объекты классов. Для web-программирования - это то, что нужно, imho.
Так, например, устроен phpMyAdmin. Там есть несколько объектов, которые это приложение использует для своей работы, все остальное написано процедурно!

Спустя 36 минут, 46 секунд (3.04.2010 - 23:13) krasilich написал(а):
Гость_vtos

Это не ООП, это программирование "с классами".

Спустя 14 секунд (3.04.2010 - 23:13) Adil написал(а):
Гость_vtos ТС не говорит не использовать ООП.. он говорит что можно отдельными классами пользоваться.. он против парадигмы ООП говорит.. писать классами и писать объекто ориентированно ИМХО разные вещи..

Спустя 41 минута, 23 секунды (3.04.2010 - 23:54) twin написал(а):
Цитата
Ну а что мешает сочетать оба подхода - процедурный и объектный?

krasilich прав, это процедурный подход и есть. Описывать все на своих местах. Класс там, где удобно класс, функцию там, где функцию. А где и просто процедуру.

ООПухоль заключается в том, что непозволительно ничего кроме классов.
Это клиника.

Я готов доказать несостоятельность подхода.
Могу поспорить, что любой код, написанный таким образом, я перепишу на процедуру так, что будет объем кода меньше - раз, проще и прозрачнее - два и оптимальнее - три и никаких конфликтов - четыре. Давайте код, посмотрите.

А все потому что я не зажат рамками. Захочу и наследника рожу, если сильно прижмет. А вот ты, krasilich, сможешь у себя на работе функцию прописать в глобальном пространстве? То-то.

Клиника. tongue.gif




Спустя 21 минута, 47 секунд (4.04.2010 - 00:16) krasilich написал(а):
twin
Цитата


Давайте код, посмотрите.


Ох, не подписывал бы я NDA дал бы=))) Хотя, есть опернсорцная версия движка, вот скачай и перепиши, покажу отделу, оценим=))

Спустя 8 минут, 16 секунд (4.04.2010 - 00:24) twin написал(а):
Ага, щас я вашему отделу движок оптимизировать возьмусь biggrin.gif biggrin.gif
Ты мне сам напиши пример, такой, чтобы обосновать смог. Почему ты считаешь, что иначе нельзя.
А я постараюсь доказать что можно. И нужно.

А движок, который вы там целым отделом несколько лет запутывали в клубок махера я не идиот переписывать)))

Спустя 11 часов, 50 минут, 29 секунд (4.04.2010 - 12:15) Гость_vtos написал(а):
Кстати, на irbis-team.com отличный материал по ООП! Все просто и очень доходчиво. Жаль, что я все это прочитал уже после того, как изучил ООП по заумным книжкам... dry.gif В любом случае, twin - спасибо!

Спустя 23 минуты, 28 секунд (4.04.2010 - 12:38) twin написал(а):
Изучить это обязательно нужно. Это вопервых новый уровень логики, во вторых, новые знания, в третьих возможность разматывать те клубки шерсти, которые напутаны в супер-пупер движках а'ля krasilich

Я наверное несу крамолу, посягая на святое, но не могу смотреть спокойно на стереотипы. Мне безразличны брэнды и имена, если там творится хаос. Будь то
eCommerce, джумла или даже ZEND-фреймворк. Если это написано под гнетом кнута и зажато в рамки - плевать на флаг.

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

Я этому учусь и к этому призываю.

Спустя 59 минут, 13 секунд (4.04.2010 - 13:38) Гость_vtos написал(а):
Есть еще один момент. Ранее php рассматривался как язык для создания динамических web-страниц и это были именно web-страницы и именно в рамках web-сайта, и ничего более. В настоящее время (да и уже давно, наверное) все чаще и чаще можно встретить такое понятие, как "web-приложение". Это уже не web-сайт, это именно приложение, но сделанное под web-технологии. И вот для таких приложений уже вовсю используют связку php+mysql, а с помощью технологии ajax делют такое приложение таким же, как и обычное desktop-приложение (ну, "таким же" - это с точки зрения пользователя, конечно).
И если при разработке web-сайтов преимущества использования ООП очень сомнительны, то вот для таких web-приложений (примером может быть система учета студентов в пределах ВУЗа) вопрос использования ООП стоит по-другому. Даже если язык разработки - php, то вот для таких web-приложений уже стоит задуматься о моделировании всей структуры приложения на классах, их объектах, реализации наследования, ну и пошло-поехало... Это мое скромное мнение...

Спустя 3 минуты, 59 секунд (4.04.2010 - 13:42) krasilich написал(а):
Гость_vtos
Не парься, twin напишет тебе мега-функцию и все будет ок=)

Спустя 6 минут, 38 секунд (4.04.2010 - 13:48) Гость_vtos написал(а):
biggrin.gif та не, twin же не отрицает, что есть моменты, когда использование ООП не будет той самой ООПухолью... Я вот думаю, что подобные web-приложения - как раз один из таких моментов...

Спустя 1 час, 46 минут, 29 секунд (4.04.2010 - 15:35) Семён написал(а):
Моих знаний пока не хватает, чтобы писать ООП, приложения, пишу классами, мне так удобнее и быстрее, как бы думаю придёт с опытом и необходимости пока нет.
Сейчас модули выглядит так (простой пример): инициализация постраничной навигации у комментариев + вывод материала + вывод древовидного меню :

REQUEST_URI:
http://example.com/test/demo/

mod_test/helper.php


<?php DEFINE ......

//TEMPLATE
$config["tpl"] = patch;
$config["tpl_layot"] = patch;


if(URL_P2 == 'demo') {
/* http://example.com/test/demo/ (URL_P1=test,URL_P2=demo, эти переменные проверяются и definятся ранее в отдельном коннекторе: */

//Получаем комментарии:

$core->Comments(
.....

'com_table' = '?_comments_1' //Вытаскиваем комментарии из таблицы ?_comments_1
'com_own' = '?_comments_own' //Принадлежность комментариев к таблице материалов и публикаций.
'on_page' = 5 //По 5 комментариев на страницу
'page_delim' = 6 //Разрыв между постраничкой < 1 2 3 4 5 6 >
.....
((


$core->Content(
.....

В таком же духе как и комментарии
.....
((


$core->Navigator(
.....

В таком же духе как и комментарии
.....
((


$example_var = 'Пример переменной';
$core->template->assign("EXAMPLE_VAR",$example_var);
$config["tpl_layot"] = patch_to_demo_layot;

}

?>


Соответственно шаблон test.tpl:
.............
{include file="LAYOT"}
.............


demo_layot.tpl:
.............
Под модуль demo:
<hr>
Значение переменной: {$EXAMPLE_VAR}
.............


Движок работает со Smarty TE
Модули строятся очень быстро... всё меняется в одном месте.
Идея мне кажется очень похожа на то о чём говорит twin

Спустя 5 минут, 52 секунды (4.04.2010 - 15:41) twin написал(а):
Цитата
И если при разработке web-сайтов преимущества использования ООП очень сомнительны, то вот для таких web-приложений (примером может быть система учета студентов в пределах ВУЗа) вопрос использования ООП стоит по-другому. Даже если язык разработки - php, то вот для таких web-приложений уже стоит задуматься о моделировании всей структуры приложения на классах, их объектах, реализации наследования, ну и пошло-поехало... Это мое скромное мнение...


Цитата
та не, twin же не отрицает, что есть моменты, когда использование ООП не будет той самой ООПухолью... Я вот думаю, что подобные web-приложения - как раз один из таких моментов...


Неа. Неправы оба и все. Тут вот в чем вопрос. Сделать это на ООП, как говорится, и дурак сможет.
Но это будет удобно только разработчику.

Я пытаюсь доказать, что процедурно написанный код будет оптимальней.
ООПухоль заключается в том, что люди, изучившие тонкости последней по эволюции парадигмы, начинают позиционировать себя, как людей, мыслящих ООП. Это клиника по определению. Так же, как и явление сектанства.



Человек, попавший в объятья секты каких-нибудь белых братьев, считает все, что противоречит их устоям: чуждым и враждебным. Совершенно забывая, откуда он туда пришел.

А пришел он из обычной жизни. Где было все - и плотские утехи и более другие грехи.

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

А если религия ООП, то это конечно на их совести. Никто запретить на может - свобода совести задекларирована государствами


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

Или те, кто по долгу службы жрет горстями гастал от изжоги. smile.gif

Спустя 39 секунд (4.04.2010 - 15:41) twin написал(а):
Семён
не сейчас.)))

Спустя 25 секунд (4.04.2010 - 15:42) glock18 написал(а):
Цитата (Семён @ 4.04.2010 - 12:35)
Идея мне кажется очень похожа на то о чём говорит twin

думаю, нет smile.gif думаю, что в понимание twin'а эта идея гораздо больше походит на ооп, чем на его. хотя, конечно, чтобы точно сказать нужно видать что в этом core - сами параметры говорят о том, что там че-то недецкое делается. так что думаю, что twin согласится с моим предположением smile.gif

Спустя 17 минут, 4 секунды (4.04.2010 - 15:59) Семён написал(а):
Ну идея, да ООП всё равно. модульность, роутинг, присутствует.
Но у меня нет всяких контроллеров... smile.gif вся обработка действий в модуле smile.gif)

Спустя 46 минут, 34 секунды (4.04.2010 - 16:45) Гость_vtos написал(а):
Цитата
Но это будет удобно только разработчику.


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

Спустя 28 минут, 40 секунд (4.04.2010 - 17:14) krasilich написал(а):
Раз уж зашла речь о документировании кода.

twin, просвети, как документируется процедурный код?

Вот для ООП я знаю PHPdoc и UML диаграммы, а вот для процедурного подхода не могу придумать ничего кроме банальных комментариев. (ну впринципе можно и диаграмму последовательности составить).

<сарказм>И стоит ли вообще применять стереотипное документирование в процедурном подходе или оно тоже загоняет в рамки и делает код не оптимальным? biggrin.gif </сарказм>

Спустя 37 минут, 7 секунд (4.04.2010 - 17:51) Гость_vtos написал(а):
Ну по-любому процедурный код тоже документируется, да хоть простым описанием каждого файла - и то уже в помощь...
Я к тому, что если объектную модель должным образом документировать, то она уже становится понятна не только самому разработчику. И к тому же, если разработчик будет помнить о том, что любой созданный им класс будет документирован, и все связи этого класса с другими классами тоже будут документированы и описаны, то слепо плодить массу наследований он уже не станет, и будет более тщательно проектировать приложение... Хотя. все это в идеале, конечно...

Спустя 19 часов, 2 минуты, 9 секунд (5.04.2010 - 12:53) twin написал(а):
Цитата
Вот для ООП я знаю PHPdoc и UML диаграммы, а вот для процедурного подхода не могу придумать ничего кроме банальных комментариев.

Крайне редко приходилось мне видеть нормальную документацию любого, хоть процедурного, хоть ООП кода. Обычно все заканцивается на уровне тех же банальных комментариев.
Так что какая разница, что не документировать? biggrin.gif
Ну а коли ООП нужен только для документации... Странный подход. Сначала все запутать, а потом написать талмуд...

PS
Цитата
twin, просвети, как документируется процедурный код?
А я не уловил, в чем принципиальная разница? PHPdoc одинаково приятно работает и для процедурки.

Спустя 1 месяц, 3 часа, 40 минут, 31 секунда (5.05.2010 - 16:34) zarafar написал(а):
С удовольствием прочитал всю тему smile.gif Жалко примеров очень мало реальных, в поддержку приводимых аргументов, чтобы было наглядно понятно.

Сам уже долго не могу понять, как же его ООП в php применять, чтобы наступило долгожданное чувство эйфории, которое обещают по сравнению с функциональным. Мягко себя уговариваю, что просто еще не переварил до конца.

Например попадает мне в руки проект, который кто то "умело" долго у усердно писал. Но писал процедурками + классы. Как бы коряво он не был написан, я почему то, когда открываю такой проект, сначала пугаюсь, но через пол часа я уже знаю, что откуда лезет и зачем.

И например открываю проект написанный с применением ооп. Если документация в плачевном состоянии или её нет, приходится очень долго курить сорцы, в которых как то все очень мутненько для восприятия.

Объективности ради замечу, что сам еще не пишу ООП, работал только с чужим кодом.

Спустя 18 минут, 28 секунд (5.05.2010 - 16:52) Семён написал(а):
А вот такой аргумент, что если ООП проект очень ну очень хорошо документирован?
Я бы отдал предпочтение ему.

Спустя 11 минут, 57 секунд (5.05.2010 - 17:04) twin написал(а):
То есть если выбирать между ооочень хорошо документированным ООП и недокументированной процедурой?
то да. biggrin.gif

А если серьёзно, почему, можешь объяснить?

Спустя 1 месяц, 24 дня, 21 час, 38 минут, 13 секунд (30.06.2010 - 14:42) linker написал(а):
Цитата
Да какое же это удобство - писать такой монструозный класс, когда тоже самое можно сделать несколькими строчками?

Если вы не заметили, то у меня нет одного универсального класса, есть базовая абстракция и есть потомки, которые работают каждый по своему, но вот общаться с этими потомками можно одинаково. Один ко множеству, гораздо лучше чем множество ко множеству.
Цитата
Нельзя разделить функционал на модули.
Опа, вот это номер, а что мешает разделить по файлам класс новостей, класс статей, класс база данных и пр. Это чем-то отличается от модульности? Да, отличается, но только: строгий и постоянный ручной инклуд и автоинклуд по возникшей необходимости, что удобнее каждый решает сам.
Цитата
Масштабируемость - чушь полная. Особенно в плане наследований. Когда это простая цепочка - да. Немного скрашивает разработку. Но сильно путает последующее обслуживание.
Кривые руки написавшего и малоопытность того, кто потом обслуживает, вот и весь сказ. Не бывает плохих программ, бывают ТОЛЬКО плохие программисты.
Цитата
Отказоустойчивость. Легко решается все это процедуркой на самом деле.
Другой вопрос - а надо ли оно?
Для хоумпаги оно нафик не надо, а вот серьезном приложении, которое работает реал-тайм под высокими нагрузками, это ой как нужно. Это можно понять, только когда в списке портфолио появится что-то более стоящее чем просто портал или он-лайн магазинчик.
Цитата
Абстракции - та еще штучка. Если код не документирован, отследить цепочку полиморфизма бывает весьма и весьма проблематично.
Нафика, помоему не сложно понять из class Child extends Parent {} , что класс Child наследуется от Parent, при наличии удобного IDE весь ваш трудоемкий процесс копания сырцов в Notepad, быстро и удобно представляется в удобном иерархическом виде. Видимо вас обошли стороной блага цивилизации.
Цитата
На кой мне наследовать какую то хрень, попадая в зависимость от этого класса?
smile.gif это не зависимость, а банальная бизнес-логика. Новости как не крути, всегда останутся новостями, хранилище данных (база данных, xml, csv и пр.) не изменит никогда своей сути, человек желтый, красный, черный, белый все равно останется человеком и при этом не изменит своему отряду млекопитающих. Программирование - это не только тискать клаву. Без абстракции и логики об этой профессии лучше забыть навсегда, либо тихой сапой штамповать сайты визитки и не рассуждать о высоких материях.
Цитата
декларируется как заслуга ООП, а на самом деле решается в несколько раз проще процедурно
smile.gif угу, 100% гарантия, что через пару дней по реализации такого проекта, вы забудете свое процедурное программирование как страшный сон. Скажем так, это издательская система, само издание - это: 6 изданий (есть ежедневка, есть еженедельки), 16 филиалов по России и 8 зарубежом. Все это дело верстается и день и ночь (часовые пояса). Собственно веб-часть - это продолжение InDesign и InCopy, а также прочий воркфлоу. Сами понимаете, что ваши слова "а нужна ли она эта отказоустойчивость" отправляются, не задерживаясь, в топку, вместо с прочим процедурным программированием.
Цитата
Ты так и не видишь сути проблемы.
Это вы кажется не видите моих слов, о том, что ООП необходимо только там, где без него действительно не обойтись, а это может узнать, только на этапе проектирования.
Цитата
Вспомни эту беседу года через три-четыре.
вы видимо спутали меня с желторотым кодером, который только узнал, что такое ООП. Я вас разочарую, разработкой софта я занимаюсь без малого уже 15 лет.

Спустя 1 час, 44 минуты, 29 секунд (30.06.2010 - 16:27) twin написал(а):
Блин, переехали. Ну ладно, раз такое дело..
Цитата
Если вы не заметили, то у меня нет одного универсального класса, есть базовая абстракция и есть потомки, которые работают каждый по своему, но вот общаться с этими потомками можно одинаково. Один ко множеству, гораздо лучше чем множество ко множеству.


Давай сравним.
Что предлагаешь ты.
1. Иметь в составе приложения абстрактный базовый класс для работы с БД. (считаем оперативную память и скорость инициализации)
2. Иметь кучу наследников. ("мертвый" код, который никогда не будет работать в данном приложении)
3. Прописать где то в приложении вызов автолоада, который этого наследника будет искать и подключать каждый раз, когда потребуется коннект. (опять оперативка и скорость)
4. Инициализировать объект наследника (все тоже)
5. Обязать всех разработчиков и себя лично использовать в приложении вместо штатных функций плана mysql_query() или pg_query() использовать методы своего класса, обрекая весь разрабатываемый функционал работать только с этим классом (к вопросу о повторном использовании)
6. А так же поместить эти штатные функции в обертку метода (опять память и ресурсы)
Это по твоему разумению один ко множеству.

Что предлагаю я.
1. Определиться, с каким хранилищем информации будем работать.
2. Выбрать отвечающий задаче файл с функциями работы с базой данных в отдельный файл и жестко (на стадии разработки) подключить его там, где требуется коннект.

Всё. Никаких накладных расходов, никакого мертвого кода и никаких тормозов.

Это не множество к одному. Это один к одному. Комментарии излишни помоему.

Цитата
Опа, вот это номер, а что мешает разделить по файлам класс новостей, класс статей, класс база данных и пр. Это чем-то отличается от модульности? Да, отличается, но только: строгий и постоянный ручной инклуд и автоинклуд по возникшей необходимости, что удобнее каждый решает сам.

Да вот. Опа. Если у тебя это вызвало такое удивление, то о каком
Цитата
серьезном приложении, которое работает реал-тайм под высокими нагрузками

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

Вот смотри. Допустим сайт логистики. Имеем группу транспорт. По твоей логике класс. Требуемые для дальнейшей работы общие свойства:
масса
расход топлива
зарплата водителя

Нам требуется грузовой транспорт. Нет проблем. Делаем наследника, добавляем свойства:
1. грузоподьёмность
2. вместимость кузова.

Теперь требуются автобусы. Опять наследник:
1. количество посадочных мест
2. стоимость билета.

Все гладко и красиво.

А теперь дальше. Есть еще один базовый функционал - городской транспорт. Другой класс. Основные свойства:
1. маршрут следования
2. расписание

Наследниками могут быть трамваи, электрички, автобусы, тролейбусы, метро. Довольно большая группа со своими специфичными свойствами, достойная отдельного класса.

Внимание - вопрос.
Как описать маршрутку?

Если мы делаем наследника от второго класса, маршрутка оказывается без водителя и расхода топлива. Если от первого - без маршрута и расписания.

Выход? Спихать все в один класс или в каждом реализовать полный функционал.
Первый путь перечеркивает такую задекларированную прелесть как разделение функционала, второй требует повтора кода. За что боролись, на то и напоролись.

Это хорошо, если на стадии проектирования. А как быть с расширяемостью? Если эти классы уже реализованы и только потом потребовалась маршрутка?

Кстати, приложение
Цитата
которое работает реал-тайм под высокими нагрузками,
требует экономии ресурса и высокой скорости, чему никак не отвечает твое решение о классе бд. Да и других тоже. Так что это бааальшой вопрос, для чего болше подходит ООП. На мой взгляд как раз для межсобойчиков плана хоумпаги, как ты выразился. Высоконагруженные ресурсы учитывают каждую микросекунду и каждый байт оперативки.

Я уже говорил, что переписал один проект с ООП на процедуру и он получил выигрыш в ресурсоемкости в 30!!! раз. Теперь на тех мощностях, где падал один сайт, расположено больше 20 таких же.
И не нужно говорить о криворукости. Нормально было все сделано.
Это неизбежность. Иначе сделать на ООП было довольно сложно.

Цитата
Не бывает плохих программ, бывают ТОЛЬКО плохие программисты.
А бывают еще и хорошие. Дорогие. Которым как раз под силу распутать этот клубок. Но платит то владелец сайта. И только потому, что кто то сэкономил пару дней на разработке, посчитав это удобным и крутым.

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

Это никакая не бизнесс-логика. Это обычные банальные штампы. Человек, это не только желтый млекопитающий. Это еще и мужчина или женщина, поэт или писатель, француз или русский, холерик или сангвинник. Запихать человека в класс и считать, что Бог пойман за бороду - обычные шоры на глазах. Мир намного многограннее, как и программирование. И если решение этой задачи
Цитата
угу, 100% гарантия, что через пару дней по реализации такого проекта, вы забудете свое процедурное программирование как страшный сон. Скажем так, это издательская система, само издание - это: 6 изданий (есть ежедневка, есть еженедельки), 16 филиалов по России и 8 зарубежом. Все это дело верстается и день и ночь (часовые пояса). Собственно веб-часть - это продолжение InDesign и InCopy, а также прочий воркфлоу. Сами понимаете, что ваши слова "а нужна ли она эта отказоустойчивость" отправляются, не задерживаясь, в топку, вместо с прочим процедурным программированием.

видится только с точки зрения ООП, мне остается только искренне пожалеть.
Путей решения масса и ООП никак не возглавляет этот список.

Я чесно говоря действительно ошарашен таким заявлением:
Цитата
Я вас разочарую, разработкой софта я занимаюсь без малого уже 15 лет.

Ну что ж поделать... Бывает и хуже.

Спустя 17 минут, 28 секунд (30.06.2010 - 16:44) waldicom написал(а):
Про маршрутки и транспорт вообще - советую прочитать про Strategy pattern

Спустя 13 минут, 23 секунды (30.06.2010 - 16:58) twin написал(а):
Ну а я о чем?
Цитата
Спихать все в один класс или в каждом реализовать полный функционал.
Стратегия предполагает первое.

Вообще вся эта возня вокруг ООП напоминает мне анекдот про обезьяну и алкаголика. Обезьяна взяла палку и сбила банан. А алкоголик на призыв - думай! ответил - чего думать! Прыгать надо.

Все эти паттерны призваны решить проблемы, которые созданы самим ООП.
Вместо того, что бы бороться с причиной, придумываются все новые и новые навороты, что бы смягчить следствие. А в результате получается слоновость мошенки. smile.gif

Спустя 2 минуты, 14 секунд (30.06.2010 - 17:00) waldicom написал(а):
Цитата (twin @ 30.06.2010 - 15:58)
Стратегия предполагает первое.

Вообще-то не совсем. Даже совсем не.
Но у меня такое чувство, Николай, что тебя в принципе невозможно убедить в том, что ООП имеет правоо на жизнь.
А поэтому зачем спорить?

Спустя 15 минут, 31 секунда (30.06.2010 - 17:15) twin написал(а):
Цитата
Но у меня такое чувство, Николай, что тебя в принципе невозможно убедить в том, что ООП имеет правоо на жизнь.

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

Меня просто бесят такие умозаключения:
Цитата
Для хоумпаги оно нафик не надо, а вот серьезном приложении, которое работает реал-тайм под высокими нагрузками, это ой как нужно. Это можно понять, только когда в списке портфолио появится что-то более стоящее чем просто портал или он-лайн магазинчик.

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

тем более, что чуть раньше предлагалось совершенно нерациональное и противоречивое решение.

Спустя 4 минуты, 48 секунд (30.06.2010 - 17:20) twin написал(а):
По поводу стратегии. Может я действительно не совсем понимаю этот паттерн, но на сколько мне известно, он реализуется одним большим абстрактным классом, в котором присутствуют все методы, реализуемые в наследниках. Причем они там должны быть одинаковыми и вызываться одинаково. Тоесть еще большие рамки.

Или я не прав?

Спустя 50 минут, 53 секунды (30.06.2010 - 18:11) glock18 написал(а):
Очередной человек убеждает Николая в том, что ООП хорошо, если в руках человека с головой. Искренне желаю удачи в этом непростом деле smile.gif

twin
у тебя везде в доводах сквозит, что ооп это "один большой класс с кучей мусора внутри". что касается самого ооп, как и паттерна стратегия - это неверно.

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


сколько мы тут не спорили, Николай непреклонен.

Спустя 4 минуты, 2 секунды (30.06.2010 - 18:15) DedMorozzz написал(а):
glock18, ниужели ты не понимаешь сути святой войны? smile.gif Тут война ради войны. Знаешь сколько я могу привести примеров, почему линукс круче винды. Дык виндоузятники приведут ровно столько же причин, почему винда классная система (: Ибо сей спор ради спора.
Но самое бесполезное тут то, что я буду с полной увереностью, что оппонент мудак не понимает о чём говорит. А мой оппонент будет точно так же уверен в обратном =) И он естесно(спор) закончится тем, что я буду далее пользоватся Линуксом, а "он" - виндой. Да и окружающие не сделают никакого вывода. И тут этот спор вроде бы утихает. Перестают отвечать и вроде бы все успокоились, но обязательно кто-то увидет этот труп(я про тему) и начнёт его эксгумировать, вызвав новую волну...что сейчас и наблюдаем.

Спустя 9 минут, 28 секунд (30.06.2010 - 18:25) twin написал(а):
Ненене. Никакой не ради войны. Ради истины.

Вась, ну скажи, ты серьёзно считаешь, что коннект лучше реализовать таким способом? Чтобы абстрактный класс, куча наследников, автолоад?

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

По поводу стратегии - просвети в двух словах. Как с помощью этого паттерна разрулить ситуацию с маршруткой.

Спустя 2 минуты, 10 секунд (30.06.2010 - 18:27) twin написал(а):
Цитата
но обязательно кто-то увидет этот труп(я про тему) и начнёт его эксгумировать, вызвав новую волну...что сейчас и наблюдаем.
И кто же это был? biggrin.gif biggrin.gif biggrin.gif

Спустя 33 минуты, 21 секунда (30.06.2010 - 19:00) glock18 написал(а):
Цитата (twin @ 30.06.2010 - 15:25)
Вась, ну скажи, ты серьёзно считаешь, что коннект лучше реализовать таким способом? Чтобы абстрактный класс, куча наследников, автолоад?


куча наследников, абстрактный класс, автолоад. а при чем здесь коннект? часто сама система разрабатывается помодульно, что требует, чтобы общение с базой данных велось через модуль, а как следствие в такой ситуации ответ напрашивается сам. и вообще надоедает видеть в скриптах людей mysql_connect повсюду (пардон, "папки" пишут include 'db_connect.php'). так вот это явный случай, когда коннектятся к базе по поводу и без него. вообще все эти вопли вокруг ооп надоели, ибо говорят "медленно, сложно и тп". а вот то, что можно без проблем у людей найти eval в циклах и лишние подключения к базе - это, конечно, не медленно, а "супер-пупер быстро и почему бы не пожертвовать немного скоростью ради 'понятности'". вместо того чтобы лить поток критики на ооп, надо понять что это. вот я более чем уверен, что каждый из тех, кто пишет сейчас оопэшно, писал когда-то процедурно. а того же сказать в обратном соотношении не могу.

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

ЗЫ: очередной раз влез в спор и уже пожалел. дальнейшее мы уже проходили...

Спустя 47 минут, 56 секунд (30.06.2010 - 19:48) twin написал(а):
Да никто тебя в спор не тянул. Я спросил мнение, ты ответил. Но ответил не на вопрос, а опять попытался завуалировать проблему.

Да и ладно, я не буду провоцировать. Тебе неприятно видеть
include 'db_connect.php'; 
мне неприятно видеть

function __autoload ($class_name) 
{
include $class_name . '.php';
}
что собственно одно и тоже, только зачем то обвешано бантиками.

Каждому свое. Тебе нравится воевать с ветряными мельницами с помощью всяких приблуд - твое право. Придумают еще кучу всяких костылей типа lazy load для того, что бы было удобнее спать на гвоздях.

А вот вопрос о стратегии и маршрутках остался без ответа. Так что изучай не изучай, кривизна ООП от этого не уменьшится.

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

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

А я могу.


Спустя 3 часа, 16 минут, 51 секунда (30.06.2010 - 23:05) linker написал(а):
Цитата
но обязательно кто-то увидет этот труп(я про тему) и начнёт его эксгумировать, вызвав новую волну...что сейчас и наблюдаем.
Ну извините smile.gif, дабы не разводить флейма в другом топике, я был вынужден перенести разговор сюда.

В данном случае, а точнее в той теме из которой был перенесен данный разговор, я не предлагал использовать абстрактные классы, ибо там нет в этом необходимости. Речь идет исключительно о тех приложениях, где приходится иметь дело с базами данных не в том узком смысле, в котором вы их понимаете.
Цитата
5. Обязать всех разработчиков и себя лично использовать в приложении вместо штатных функций плана mysql_query() или pg_query() использовать методы своего класса, обрекая весь разрабатываемый функционал работать только с этим классом (к вопросу о повторном использовании)
Я вот все никак не могу понять, какие у вас сложности с повторным использованием класса для работы с бд? Ну перенес я скрипт с реализованным классом в другое приложение и что, в этом другом приложении как-то поменяется процесс соединения с бд? Расскажите, а то вот я все мучаюсь, использую свои библиотеки в разных приложениях без всяких изменений. Скажите может, у меня руки кривые, раз все у меня так гладко получается и работает? Вразумите и тогда я может быть начну для каждого нового проекта заново переписывать классы, чтобы обрести наконец таки везде и всюду предрекаемый вами гемморой.
Суть одного ко множеству, это когда работая с хранилищем данных не имеет значения что это за хранилище и каким образом оно там внутрях работает, важен только результат - получить данные. Но зная, что этот объект есть хранилище (и не имеет значение MySQL, MSSQL, XML...), мы всегда знаем, что можем получить данные одним из публичных методов, причем гарантированно. Абстракция - это описание без реализации. Дочерний класс обязан будет реализовать каждое из описанных абстрактных методов - в этом гарантия. Другой способ интерфейсы, без множественного наследования, очень помогают.

По поводу вашего примера, если считать его в качестве проектной документации, а меня ведущим разрабом, то данную писанину я не задумываясь отправил бы в топку. Что есть логистика - грубо говоря грамотное составление маршрута движения транспортных средств, перевозящих товары и прочее. Значит и грузовой автомобиль, и автобус, и маршрутка и пр. имеют собственно самое основное и главное - маршрут и расписание. Второе, кривое место, все эти транспортные средства имеют общее свойство - вместимость. Третье и четвертое кривое место, что есть стоимость билета? Это - тариф на перевозку, грузовой транспорт тоже имеет свой тариф, а значит во-первых, вы обделили грузовики этим важным свойством, а во-вторых, оно является общим и попадает в базовый класс. Собственно на долю грузовиков приходится только грузоподъемность. Получается следующая иерархия: базовый класс - транспорт, от него две ветки грузовой и общественный. Для простого примера этого будет достаточно. Собственно в дочерних классах остается только реализовать конструкторы
для грузового
public function __construct(..., $LoadCapacity)
{
parent::__construct(...);
$this->LoadCapacity = $LoadCapacity;
}
Установка маршрута и расписания одинаково, расход одинаков, стоимость одинаково и пр. описывается и реализуется один раз в базовом классе.
Когда мы хотим видеть отчет по бабкам, имея массив объектов-машин разных классов, мы не заморачиваемся какого класса транспорт, мы просто пишем $Automobile->ShowPrice(); хотим посмотреть маршруты - $Automobile->ShowRoute(); и т.д. Расширяемость - самолет, пароход нет никакой разницы всегда $Automobile->метод(); Вот и все, каркас реализован и готов к навешиванию всяких фенечек, рюшечек и прочих функциональных причиндалов. Я не силен в логистике, но имхо общую бизнес-логику (в меру своих практически нулевых познаний логистики) я выразил.
Цитата
Я уже говорил, что переписал один проект с ООП на процедуру и он получил выигрыш в ресурсоемкости в 30!!! раз. Теперь на тех мощностях, где падал один сайт, расположено больше 20 таких же.
Если вы переписали Hello world из MVC в банальное
<? echo Hello,chr(0x20),world; ?>

то не спорю.
Цитата
Мир намного многограннее, как и программирование.
А быстро, легко и надежно описать и реализовать эту многогранность позволяет именно ООП.
Цитата
Путей решения масса и ООП никак не возглавляет этот список
Путей решения равно количеству задач, если в одной задаче несколько путей решения, то простое, удобное и быстрое только одно и оно будет на вершине, и опять же это одно решение зависит от самой задачи.
Цитата
Ну что ж поделать... Бывает и хуже.
Понимаете, свет клином на php не сошелся, вы знаете что бывают и другие языки программирования (мой любимый - ассемблер, а еще лучше опкоды)? Так не дай бог, что вам придется столкнуться с каким-нибудь иным средством разработки, тогда поймете, что глубоко заблуждались, когда не хотели выучить и понять, что есть ООП.

Спустя 14 минут, 14 секунд (30.06.2010 - 23:19) linker написал(а):
Цитата (twin @ 30.06.2010 - 16:48)
Да и ладно, я не буду провоцировать. Тебе неприятно видеть
include 'db_connect.php'; 
мне неприятно видеть

function __autoload ($class_name) 
{
include $class_name . '.php';
}
что собственно одно и тоже, только зачем то обвешано бантиками.

....

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

А я могу.

С той небольшой разницей, что пожизненный и повсеместный, мозолящий глаза include('...'); видишь всегда, а __autoload() при редчайшей необходимости.

Насколько я уже понял из разговоров, этим единственным ушедшем от ООП являетесь вы собственной персоной. Но я знаю почему так получилось, вы просто не умеете его готовить, вот и все.

Спустя 16 минут, 39 секунд (30.06.2010 - 23:36) DedMorozzz написал(а):
Холивар, он такой холиварный... Основное его отличие от обычного спора - ЗА и Против всегда хорошие и грамотные аргументы, причём невозможно спорить, говоря, что-то кроме "да это отстой" не владея на достаточно хорошем уровне предметом. Как с одной и с другой стороны. И посему фразы по типу:
Цитата
когда не хотели выучить и понять, что есть ООП.
и
Цитата
Насколько я уже понял из разговоров, этим единственным ушедшем от ООП являетесь вы собственной персоной. Но я знаю почему так получилось, вы просто не умеете его готовить, вот и все.
являются по крайней мере не уместными. Так же холивар подразумевает отсутствие однозначного ответа, что лучше. А данный тред - именно холивар.
вики про ООП
Критика ООП

Несмотря на отдельные критические замечания в адрес ООП, в настоящее время именно эта парадигма используется в подавляющем большинстве промышленных проектов. Однако, нельзя считать, что ООП является наилучшей из методик программирования во всех случаях.
Обычно сравнивают объектное и процедурное программирование:
Процедурное программирование лучше подходит для случаев, когда важны быстродействие и используемые программой ресурсы, но требует большего времени для разработки.
Объектное — когда важна управляемость проекта и его модифицируемость, а также скорость разработки.
Критические высказывания в адрес ООП:
Исследование Thomas E. Potok, Mladen Vouk и Andy Rindos [1] показало отсутствие значимой разницы в продуктивности разработки программного обеспечения между ООП и процедурным подходом.
Кристофер Дэйт указывает на невозможность сравнения ООП и других технологий во многом из-за отсутствия строгого и общепризнанного определения ООП (C. J. Date, Introduction to Database Systems, 6th-ed., Page 650)
Александр Степанов, в одном из своих интервью, указывал на то, что ООП «методологически неправильно» и что «… ООП практически такая же мистификация как и искусственный интеллект…» ([2]).
Фредерик Брукс (Frederick P. Brooks, Jr.) в своей статье «No Silver Bullet. Essence and Accidents of Software Engineering» (Computer Magazine; April 1987) указывает на то, что наиболее сложной частью создания программного обеспечения является « … спецификация, дизайн и тестирование концептуальных конструкций, а отнюдь не работа по выражению этих концептуальных конструкций…». ООП (наряду с такими технологиями как искусственный интеллект, верификация программ, автоматическое программирование, графическое программирование, экспертные системы и др.), по его мнению, не является «серебряной пулей», которая могла бы на порядок величины (то есть примерно в 10 раз, как говорится в статье) снизить сложность разработки программных систем. Согласно Бруксу, «…ООП позволяет сократить только привнесённую сложность в выражение дизайна. Дизайн остаётся сложным по своей природе…». ([3])
Эдсгер Дейкстра указывал: «… то о чём общество в большинстве случаев просит — это змеиное масло. Естественно, „змеиное масло“ имеет очень впечатляющие имена, иначе будет очень трудно что-то продать: „Структурный анализ и Дизайн“, „Программная инженерия“, „Модели зрелости“, „Управляющие информационные системы“ (Management Information Systems), „Интегрированные среды поддержки проектов“, „Объектная ориентированность“, „Реинжиниринг бизнес-процессов“…» — EWD 1175: The strengths of the academic enterprise
Никлаус Вирт считает, что ООП — не более чем тривиальная надстройка над структурным программированием, и преувеличение её значимости, выражающееся, в том числе, во включении в языки программирования всё новых модных «объектно-ориентированных» средств, вредит качеству разрабатываемого программного обеспечения.
Патрик Киллелиа в своей книге «Тюнинг веб-сервера» писал: «… ООП предоставляет вам множество способов замедлить работу ваших программ …»
Если попытаться классифицировать критические высказывания в адрес ООП, можно выделить несколько аспектов критики данного подхода к программированию.
Критика рекламы ООП.
Критикуется явно высказываемое или подразумеваемое в работах некоторых пропагандистов ООП, а также в рекламных материалах «объектно-ориентированных» средств разработки представление об объектном программировании как о некоем всемогущем подходе, который магическим образом устраняет сложность программирования. Как замечали многие, в том числе упомянутые выше Брукс и Дейкстра, «серебряной пули не существует» — независимо от того, какой парадигмы программирования придерживается разработчик, создание нетривиальной сложной программной системы всегда сопряжено со значительными затратами интеллектуальных ресурсов и времени. Из наиболее квалифицированных специалистов в области ООП никто, как правило, не отрицает справедливость критики этого типа.
Оспаривание эффективности разработки методами ООП.
Критики оспаривают тезис о том, что разработка объектно-ориентированных программ требует меньше ресурсов или приводит к созданию более качественного ПО. Проводится сравнение затрат на разработку разными методами, на основании которого делается вывод об отсутствии у ООП преимуществ в данном направлении. Учитывая крайнюю сложность объективного сравнения различных разработок, подобные сопоставления, как минимум, спорны.
Производительность объектно-ориентированных программ.
Указывается на то, что целый ряд «врождённых особенностей» ООП-технологии делает построенные на её основе программы технически менее эффективными, по сравнению с аналогичными необъектными программами. Не отрицая действительно имеющихся дополнительных накладных расходов на организацию работы ООП-программ (см. раздел «Производительность» выше), нужно, однако, отметить, что значение снижения производительности часто преувеличивается критиками. В современных условиях, когда технические возможности компьютеров чрезвычайно велики и постоянно растут, для большинства прикладных программ техническая эффективность оказывается менее существенна, чем функциональность, скорость разработки и сопровождаемость. Лишь для некоторого, очень ограниченного класса программ (ПО встроенных систем, драйверы устройств, низкоуровневая часть системного ПО, научное ПО) производительность остаётся критическим фактором.
Критика отдельных технологических решений в ООП-языках и библиотеках.
Эта критика многочисленна, но затрагивает она не ООП как таковое, а приемлемость и применимость в конкретных случаях тех или иных реализаций её механизмов. Одним из излюбленных объектов критики является язык C++, входящий в число наиболее распространённых промышленных ООП-языков.

Спустя 24 минуты, 28 секунд (1.07.2010 - 00:00) linker написал(а):
DedMorozzz, однозначный ответ существует применительно к конкретной задаче. В данном случае существует крайность, ООП - г. и его нельзя использовать ни под каким соусом. Мое имхо, все зависит от задачи, соответственно под эти задачи расчитываются мощности и ресурсы. Инструмент разработки выбирается на самом последнем этапе, на таком же последнем месте он находится и в программировании в целом.
Если мои слова кажутся резкими, то хочу сразу извиниться, я человек прямой, прошу снисхождения.

Спустя 6 часов, 37 минут, 48 секунд (1.07.2010 - 06:38) twin написал(а):
Цитата
Я вот все никак не могу понять, какие у вас сложности с повторным использованием класса для работы с бд?

Да как же не понятно очевидных вещей то... Ну с чего этот холивар то начался? С того и начался, что человек не смог адаптировать класс пагинатора к своему приложению исключительно по этой причине. Нет стандартов, кто во что горазд. Каждый решил, что с этого момента mysql_query() теперь раз и на всегда должна звучать как db->query(). Или $obj->SQL.
Цитата
Расскажите, а то вот я все мучаюсь, использую свои библиотеки в разных приложениях без всяких изменений.
Вот именно что свои.

С чем я постоянно и сталкиваюсь. Допустим меня просят изменить функционал работающего сайта. Добавить тот же пагинатор. Я открываю код и что вижу... "Тщательно и грамотно" спроектированный клубок полиморфизма с кучей заплаток в виде интерфейсов, абстрактных классов коннекта с автолоадами и разнообразных костылей типа ленивых загрузок, стратегий и прочей ереси. Причем это все "свое и родное".

У меня есть готовый класс пагинатора, но что бы его применить, я должен разобраться в логике предшественника и переписать свой класс под ту дудку, которая показалась разработчику наиболее приемлимой в данный момент.

А всё потому, что кто то решил:
Цитата
я не хочу заморачивать, какая база данных используется в том или ином проекте

Он значит не хочет, а я теперь должен.

С пагинатором - это пример. Конечно не так это сложно. Но задачи то ставятся гораздо серьёзнее. И разгребать этот бедлам приходится на гораздо более серьёзном уровне.

Цитата
Суть одного ко множеству, это когда работая с хранилищем данных не имеет значения что это за хранилище и каким образом оно там внутрях работает, важен только результат - получить данные.
Я знаю что это такое. Я не понимаю для чего это делать с классом БД.
Ну никогда не будет меняться база данных в работающем проекте. Никогда. А если и будет, то вероятность на столько мала, что говорить о универсальности в ущерб оптимальности тут уже даже не смешно, а крайне печально.

Теперь с маршрутками.
Цитата
По поводу вашего примера, если считать его в качестве проектной документации, а меня ведущим разрабом, то данную писанину я не задумываясь отправил бы в топку.
Всё верно. Вот так и рассуждают проектировщики этих абстракций. Мол вот я то самый умный, все сейчас предусмотрю и спроектирую так, что никогда казусов не вылезет. Но.
Цитата
Я не силен в логистике, но имхо общую бизнес-логику (в меру своих практически нулевых познаний логистики) я выразил.
все же есть один казус. Оказывается, для того, чтобы спроектировать приложение на ООП, необходимо сначала в тонкостях изучить логистику? Иначе как. Можно же неверно спроектировать. Примерно так:
Цитата
Значит и грузовой автомобиль, и автобус, и маршрутка и пр. имеют собственно самое основное и главное - маршрут и расписание.
Нет. Не имеют.
Логистика призвана эти самые маршруты организовывать. Тоесть маршрут и расписание - это результат. Не имеет грузовой автомобиль, как транспортная единица, этих свойств. И автобус не имеет.

Есть еще такое понятие как транспортный поток. Это как раз те самые маршруты. Но пихать сюда грузоподъёмность и зарплату водителя как минимум не профессионально. Он расчитывается из количества транспортных средств, пропускной способности маршрута и других, совершенно не относящихся к транспортной единице свойств.

Так что не
Цитата
Получается следующая иерархия: базовый класс - транспорт, от него две ветки грузовой и общественный.

Более того, есть еще куча разных вводных для организации такой сложной сферы действия, как логистика. Это и складское хозяйство, и сопутствующие сервисы и плотность грузопотока и еще куча всего. Да и транспорт транспорту - рознь. Как можно под одни свойства подогнать автомобили, трубопроводный и коммуникативный транспорт? Как это может быть "общественный трубопровод"? Или еще хуже - "грузовой"? Или в базовом классе вообще не нужно никаких свойств определять. Просто транспорт. Чтоб былО. А от него пошли плясать - трубопроводный, общественный, грузовой. Усложнив тем самым их взаимодействие и не получив абсолютно никакой выгоды.

Причем все это должно, обязано взаимодействовать. В любой момент может потребоваться узнать как стоимость перевозки холодильника из пункта А в пункт Б, так и возможность этой самой перевозки в следующую пятницу с альтернативой доставки морским путем с пересадкой на самолет. А обратно вернуть финансовый поток (оплату). Да, да. Это тоже логистика.

Так вот, даже если мы проявим верх мастерства и предусмотрим все, то базовый класс будет либо пустым, либо таким огромным и всеобъемлющим, что его можно легко сравнить с глобальной областью видимости. Только с той разницей, что класс придется каждый раз инициализировать. И гонять танкер для того, чтобы расчитать стоимость билета на маршрутку.

Если бы была возможность множественного наследования, вопросов бы не возникало. Но ООП в PHP сделано однобоко. В расчете на те самые новости и статьи, которые тут упоминались. Когда требуется линейное изменение - это одно. На маленьких функционалах может и прокатит. Но чуть серьёзнее - начинаются выкрутасы.

Есть базовый класс "статьи", делаем наследника "статьи о ООП" и "статьи о процедурках" и радуемся. А как только потребуется сделать сравнительный анализ - придется вызывать оба и мудрить сводный класс. Что я часто и наблюдаю. А это уже не шутки, тут никакие костыли плана lazyload не помогут. Накладные расходы увеличиваются бывает в разы.
Цитата
Если вы переписали Hello world из MVC в банальное
<? echo Hello,chr(0x20),world; ?>
то не спорю.
Причем тут MVC? Как будто его нельзя реализовать процедурно. Что я собственно и сделал, убрав лишнюю обертку и распределив нагрузки. Все то, о чем писалось выше. Если мне требуются данные, я беру данные. А не выдумываю лабиринт пути к ним через тернии абстракций и автолоадов. Структурность кстати совершенно не обязательно подразумевает ООП.

Кстати, все это касается только PHP, я неоднократно об этом говорил.
Цитата
Так не дай бог, что вам придется столкнуться с каким-нибудь иным средством разработки, тогда поймете, что глубоко заблуждались, когда не хотели выучить и понять, что есть ООП.

Я ничего не имею против ООП в С++, с которым в данный момент и "столкнулся". Причем там это действительно круто. И прекрасно понимаю, что есть ООП и как его готовить. Но в сях есть библиотеки, общепринятые, возведенные в ранг стандарта. Расширять их наследниками - одно удовольствие. Чего никак не могу сказать о том полном бардаке, который творится в PHP.
Тем более, что это интерпретируемый язык, да еще и с такой кривой реализацией самого ООП.

Так что далеко не всегда
Цитата
быстро, легко и надежно описать и реализовать эту многогранность позволяет именно ООП.
Всему свое место.

Спустя 13 минут, 17 секунд (1.07.2010 - 06:51) Бла Бла Бла написал(а):
Цитата (linker)
Это можно понять, только когда в списке портфолио появится что-то более стоящее чем просто портал или он-лайн магазинчик

Цитата (linker)
У меня есть проект, который расширился с 1 одного сервера до шести и с 1 базы данных до 13, 6 ftp серверов, около 500 пользователей. При этом работает это дело одновременно

Цитата (twin)
Я уже говорил, что переписал один проект с ООП на процедуру и он получил выигрыш в ресурсоемкости в 30!!! раз. Теперь на тех мощностях, где падал один сайт, расположено больше 20 таких же.


Бла бла бла. Я, Я, Я. А вот Я !!! Да, нет, а Я ...


Апеллируете к своим навороченным работам, а ссылку посмотреть, что там за крутизна реализована - слабо?

Пиз..ть на форуме как говорится не мешки ворочать. wink.gif


laugh.gif laugh.gif laugh.gif А вы знаете, что вот мои например программы на орбитальной станции мир работают ???? laugh.gif laugh.gif laugh.gif

Спустя 1 минута, 12 секунд (1.07.2010 - 06:53) twin написал(а):
Цитата
Насколько я уже понял из разговоров, этим единственным ушедшем от ООП являетесь вы собственной персоной. Но я знаю почему так получилось, вы просто не умеете его готовить, вот и все.

Далеко нет. Я уже говорил об этом. Тот, кто ушел, обычно не афиширует это. Сидит тихо. Потому и складывается впечатление, что ООП - верх девелопинга. О прелестях ООП обычно кричат взахлеб те, кто недавно его освоил и пока не наелся. А кто хлебнул, не хочет даже вспоминать.

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

Спустя 1 минута, 35 секунд (1.07.2010 - 06:54) twin написал(а):
Цитата
Апеллируете к своим навороченным работам, а ссылку посмотреть, что там за крутизна реализована - слабо?
Представится сначала слабо? Я покажу кучу работ, и ту самую с 30 - кратным выигрышем. Но только в личке.

Спустя 32 минуты, 40 секунд (1.07.2010 - 07:27) Бла Бла Бла написал(а):
Цитата (twin)
Представится сначала слабо?

А я что не представился? blink.gif Меня зовут Бла бла бла. По поиску пришел и вот читаю.

Цитата (twin)
Я покажу кучу работ, и ту самую с 30 - кратным выигрышем. Но только в личке.

А вы демагогию развели в личке что-ли wink.gif , со ссылками на свои работы ? Я читаю и мне не понятно - врете вы или нет. Каждому прохожему в личке что то объяснять собрался? Или отмазываешся?

Спустя 32 минуты, 7 секунд (1.07.2010 - 07:59) twin написал(а):
Ты меня на понял не бери. И на слабо тоже. С ананимными бла бла я разговаривать не собираюсь. И уж что то им доказывать - тем более. Таких бла бла - больше 9000. Если действительно есть интерес - зарегайся, представься, покажи сам что можешь. Тогда обсудим.
А на каждого трололо реагировать - себя не уважать.

Выкладывать ссылки на свои работы в теме считаю неэтичным, ибо пиар.


Спустя 10 минут, 33 секунды (1.07.2010 - 08:09) KaFe написал(а):
Где то слышал высказывание, что ПЫХ разрабатывался для создания динамических страничек и не больших веб-приложений.

Я понимаю что такое ООП и для чего оно нужно в нормальных полноценных языках программирования, там действительно без этого сложно обойтись. Но вот в ПЫХе я думаю ООП подход должен быть только в ТЕХ проектах где без этого вообще не катит.

huh.gif И по моему Твин сразу всех в споре уделал, так как он предоставил высказывание авторитетных людей (Я же в гугле пробил, узнал кто они такие laugh.gif ).

PS:Но у каждого свой стиль программирования. Кому то нравится е...ть себе мозг ООП в Пыхе, кому то нравится и что другое. У каждого свой стиль программирования. Дело вкуса и все такое.

Спустя 1 минута, 41 секунда (1.07.2010 - 08:11) KaFe написал(а):
wink.gif Я против ООПухуливания laugh.gif laugh.gif

Спустя 12 минут, 55 секунд (1.07.2010 - 08:24) kirik написал(а):
Цитата (KaFe @ 1.07.2010 - 00:09)
Я понимаю что такое ООП и для чего оно нужно в нормальных полноценных языках программирования, там действительно без этого сложно обойтись. Но вот в ПЫХе я думаю ООП подход должен быть только в ТЕХ проектах где без этого вообще не катит.

Fail..
Вы не считаете php "нормальным" языком?! А python, а ruby а итдитп? То что он "разрабатывался для создания динамических страничек и не больших веб-приложений" это было в 95 году. А сейчас это мощное и популярное средство для создания любых систем. Или все-таки считать facebook "не большим веб приложением"? wink.gif

ЗЫ.
Я "за" ООП в разумных пределах. В случае с коннектом к БД я на стороне Васи; ибо переведя один сайт на автолоад одного лишь подключения к БД - перестал падать сервер БД.

Спустя 10 минут, 24 секунды (1.07.2010 - 08:34) twin написал(а):
Цитата
Я "за" ООП в разумных пределах. В случае с коннектом к БД я на стороне Васи; ибо переведя один сайт на автолоад одного лишь подключения к БД - перестал падать сервер БД.

Так тут вся и песня в том, что ООП не бывает в разумных пределах. Нельзя быть чуть чуть беременным. biggrin.gif
Это Программирование Объектно Ориентированное. А если в разумных пределах - это процедурка и есть. То есть все на своих местах.

А вот с автолоадом БД чото невкурил. Чем же это он помог избежать падений?

Спустя 2 минуты, 20 секунд (1.07.2010 - 08:37) KaFe написал(а):
ИМХО.Я не считаю PHP нормальным полноценным языком программирования. wink.gif Может это глупо, но я так думаю. Вот C его последователь C++ это монстры, настоящие мачо, не то что PHP.

Спустя 2 минуты, 44 секунды (1.07.2010 - 08:39) Бла Бла Бла написал(а):
Цитата (twin)
Выкладывать ссылки на свои работы в теме считаю неэтичным, ибо пиар.

Та я уже в подписи нашел tongue.gif :
Свернутый текст
user posted image


Цитата (twin)
Ты меня на понял не бери. И на слабо тоже. С ананимными бла бла я разговаривать не собираюсь.

Знаешь вы своей мудацкой регистрацией уже всех задолбали. Это не модно. пруфлинк, что не модно wink.gif .

Цитата
доказывать - тем более

а мне ничего и не надо доказывать. я тебя не знаю и ты мне ничего не должен. Ты хотя бы логично заверши свои посты. Сообщения должны быть последовательными, аргументированными. Якнул - пруфлинк. Еще раз якнул - еще пруфлинк.
Так любой(как linker) прийдет в эту твою темку и скажет:
вот я такой крутой, супер попуперски сделал проект(он секретный и не покажу blink.gif ) и там все круто прикруто и вы все собеседники - тупаки ....

Спустя 1 минута, 51 секунда (1.07.2010 - 08:41) twin написал(а):
Цитата
А сейчас это мощное и популярное средство для создания любых систем. Или все-таки считать facebook "не большим веб приложением"?

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

Спустя 2 минуты, 33 секунды (1.07.2010 - 08:44) KaFe написал(а):
Бла Бла Бла я думаю ты вскоре получишь бан по ip-адресу laugh.gif

Спустя 3 минуты, 5 секунд (1.07.2010 - 08:47) twin написал(а):
Бла Бла Бла
археолог, блин. Поищи еще столетней давности линки, там тоже 404 найдешь.
В подписи нет такого, не вводи людей в блуд.
Цитата
Ты хотя бы логично заверши свои посты. Сообщения должны быть последовательными, аргументированными. Якнул - пруфлинк. Еще раз якнул - еще пруфлинк.
Мне не нужно после каждой своей мысли давать пруф на чужие. Когда нужно - даю.
Если ты не можешь мыслить самостоятельно, тем более на столько, что боишься представится, обчем речь. Ссылайся.
KaFe
Цитата
Бла Бла Бла я думаю ты вскоре получишь бан по ip-адресу

не думаю. Правил он не нарушает.

Спустя 2 минуты, 10 секунд (1.07.2010 - 08:49) KaFe написал(а):
Цитата (Бла Бла Бла @ 1.07.2010 - 05:39)
мудацкой регистрацией

Цитата (Бла Бла Бла @ 1.07.2010 - 05:39)
всех задолбали

Цитата (Бла Бла Бла @ 1.07.2010 - 05:39)
и вы все собеседники - тупаки ....

А меня за такое в реадонли кидали на 2 дня

Спустя 47 секунд (1.07.2010 - 08:50) Basili4 написал(а):
Цитата (KaFe @ 1.07.2010 - 09:37)
Вот C его последователь C++ это монстры, настоящие мачо, не то что PHP.

ну что то на не С не С++ не делают такого количества сайтов как на PHP даже PERL который более древний не может похвастаться такой популярности.

Спустя 1 минута, 24 секунды (1.07.2010 - 08:51) kirik написал(а):
Цитата (twin @ 1.07.2010 - 00:34)
Нельзя быть чуть чуть беременным.

Черт, спалился))
Фишка какая - выносим отдльные модули как классы (mysql, cache, ресайз картинок, работа с ФС, ...) а все остальное решаем с помощью процедурного подхода. Так и получается что как будто бы "чуть-чуть")

Цитата (twin @ 1.07.2010 - 00:34)
А вот с автолоадом БД чото невкурил. Чем же это он помог избежать падений?

В проекте использовался кэш (мемкэш), но подключения к БД происходили даже в том случае, если _все_ данные брались из кэша. Отсюда и была проблема "too many connections" во время наплыва посетителей.
А автолоад и вызов подключения к БД только когда совершается запрос (первый) решили эту проблему.

Цитата (KaFe @ 1.07.2010 - 00:37)
ИМХО.Я не считаю PHP нормальным полноценным языком программирования.  Может это глупо, но я так думаю

Ок, я уважаю ваше мнение) Но хотелось бы услышать хоть некоторые аргументы..)

Спустя 2 минуты, 30 секунд (1.07.2010 - 08:54) kirik написал(а):
Цитата (KaFe @ 1.07.2010 - 00:37)
Вот C его последователь C++ это монстры, настоящие мачо

Ясен хрен, простите, монстры) Пхп на них написан.

Спустя 27 секунд (1.07.2010 - 08:54) twin написал(а):
KaFe
Цитата
А меня за такое в реадонли кидали на 2 дня
Ты местный. Тебя воспитывали. biggrin.gif
А эти залетные не стоят такого внимания.

Спустя 3 минуты, 11 секунд (1.07.2010 - 08:57) twin написал(а):
Цитата
А автолоад и вызов подключения к БД только когда совершается запрос (первый) решили эту проблему.
Ясно. Но всеже автолоад тут не совсем причем. Жесткое подключение коннекта там, где есть запрос точно так же решает эту проблему. Я же ни где не написал, что первой строчкой любого скрипта должно быть это подключение.

Спустя 4 минуты, 25 секунд (1.07.2010 - 09:02) kirik написал(а):
twin
Просто с использованием класса (в случае с БД) пропадает необходимость тащить за собой повсюду идентификатор подключения, а автолоад избавляет от лишних инклюдов. Так сказать-код чище становится.

Спустя 10 минут, 32 секунды (1.07.2010 - 09:12) twin написал(а):
Цитата
Просто с использованием класса (в случае с БД) пропадает необходимость тащить за собой повсюду идентификатор подключения, а автолоад избавляет от лишних инклюдов. Так сказать-код чище становится.
Опять таки нефкурил. Если неохота тащить идентификатор - лепим обертку. Но это функция, минимум функционала. Зачем абстрактный класс? Он нужен только для альтернативных БД, а это профонация.
Что касается автолоада - да где же чище то? От инклюдов он не избавляет ни в коем случае, просто подменяет понятия.

Спустя 6 минут, 15 секунд (1.07.2010 - 09:19) kirik написал(а):
Цитата (twin @ 1.07.2010 - 01:12)
Зачем абстрактный класс?

Сори, мож че не понял.. а зачем абстрактный? Обычного хватит, со статическими методами)

Цитата (twin @ 1.07.2010 - 01:12)
Что касается автолоада - да где же чище то? От инклюдов он не избавляет ни в коем случае, просто подменяет понятия.

Ну как сказать.. То-ли для того чтобы работать с бд нужно что-то иклюдить, а потом уже работать; в случае с автолоадом просто работаешь и все.. Там уже автолоад сам за тебя подумает что нужно подключать. На одну операцию меньше smile.gif

Спустя 5 минут, 56 секунд (1.07.2010 - 09:25) twin написал(а):
Цитата
Сори, мож че не понял.. а зачем абстрактный? Обычного хватит, со статическими методами)

Вот собственно кульминация этого холивара.

Спустя 18 минут, 29 секунд (1.07.2010 - 09:43) kirik написал(а):
Цитата (twin @ 1.07.2010 - 01:25)
Вот собственно кульминация этого холивара.

Пардон, не так понял. В случае с абстрактным классом действительно сомнительная "простота".

Спустя 26 минут, 31 секунда (1.07.2010 - 10:10) glock18 написал(а):
Я понимаю linker с абстракцией слоев. Сам такое делал, Николай помнит. Как по мне, особо плюсов или минусов каких-то особых нет. Минус уже говорили - больше кода. Плюс достаточно узконаправленный - если использовать это в фреймворке в совершенно различных проектах, то проблема выбора базы данных будет ограничиваться наличием лайера для нее и знаний разработчика в различных субд. Менять сервер субд в пределах одного проекта приходится все же крайне редко.

Таким образом, если класс идет в частоиспользуемый двиг и разработчик владеет различными субд и для каждого проекта выбирает нужную, то абстракции весьма хороший выбор. "Больше кода - меньше скорость" скажет кто-то, но узкое место уже довольно давно в межсерверном взаимодействии или на стороне sql-сервера в зависимости от особенностей самой системы.

В другом случае пойдет обычный класс с набором статических методов (этакое пространство имен функций).

Спустя 6 минут, 6 секунд (1.07.2010 - 10:16) twin написал(а):
Цитата
Таким образом, если класс идет в частоиспользуемый двиг и разработчик владеет различными субд и для каждого проекта выбирает нужную, то абстракции весьма хороший выбор.

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

Тут просто образ мышления. Если моск работает по ООПэшному, те не важно как это можно сделать лучше. Важно, как сказал linker, "что на входе и что на выходе".

И это касается не только класса БД. Масса других вещей решается проще и эфективнее. Но - религия же не позволит. Это я и называю ООПухоль головного мозга.

Спустя 1 минута, 23 секунды (1.07.2010 - 10:17) sergeiss написал(а):
Горячие эстонские парни! smile.gif Остановитесь на минутку.

По-моему, вы вообще о разном говорите!!! Я уже однажды выяснил этот вопрос с Твином, во время начала этой темы. Большинство, говоря про ООП, говорят просто про использование классов. А Твин, говоря про "парадигму ООП", имеет ввиду немного другое, а не просто "использование классов".

А вот что Твин подразумевает под "парадигмой ООП", я бы и сам еще раз услышал. Тогда я понял smile.gif, но не запомнил точно.

Спустя 6 минут, 29 секунд (1.07.2010 - 10:24) DedMorozzz написал(а):
Если мне не изменяет мой склероз - то грил про переплетение наследований, инкапсуляции и прочего.
Что касается данного треда, то как ни как, но позиция Твина в данном случае - убедительнее. Но если выйти за рамки данного обсуждения, да и вообще форума, то устраиваясь на любую нормальную работу, обязательно, ну просто ОЧЕНЬ ОБЯЗАТЕЛЬНО будут требовать ООП иль знание какого-то фреймвёрка(что собсно тоже ООП). Что бы там в дальнейшем не говорить, что я знаю что появилось раньше яйцо или курица и могу это описать без ООП, процедуркой и будет всё лучше и быстрее - никого не интересует.

Спустя 58 секунд (1.07.2010 - 10:25) twin написал(а):
А вот собственно.

ООП - это образ мышления. То есть все программирование должно быть сориентировано на объекты. Это не использование классов. Использовать их очень даже полезно.
Это построение приложения на основе взаимодействующих и взаимодополняющих объектов. Часто доводящееся в фанатичном применении до полного маразма. Как в случае с классом БД.


Спустя 4 минуты, 20 секунд (1.07.2010 - 10:29) twin написал(а):
DedMorozzz
Вот отсюда и растут ноги. Потому и принято считать ООП верхом девелопинга. Никуда не денешься, если весь коллектив подвержен этой болезни. Ну а знать то оно - естественно нужно.

Я тут о другом. О том, что люди советуют делать (не со зла, они сами так думают) все по этой линеечке. Ведь весь сыр бор разгорелся отсюда.
Ну сделал человек по своему, зачем ему советовать, да еще в такой категоричной форме, то, что очень даже спорно.

Только потому, что так положено. Кем и куда - история умалчивает.

Спустя 14 минут, 59 секунд (1.07.2010 - 10:44) linker написал(а):
Вижу, полемика развернулась не на шутку. Я думаю, прикрою, если скажу. Лично я предпочитаю комбинированный подход, то простое что можно реализовать функциями, должно быть реализовано именно так, сложные структуры и динамику необходимо реализовывать в ООП. Я не знаю как относится к тенденции всеобщего и повального ООПэривания (в javascript как не крути тоже "ООП", а иначе ни как), но по себе я знаю, как оно мне облегчает жизнь и сколько я сэкономил строчек кода, сил и нервов.
За сим, я умолкаю по этой теме.

Спустя 11 минут, 48 секунд (1.07.2010 - 10:56) waldicom написал(а):
Цитата (twin @ 1.07.2010 - 05:38)
Оказывается, для того, чтобы спроектировать приложение на ООП, необходимо сначала в тонкостях изучить логистику?

Вот эти слова очень странно слышать от такого "монстра" программирования.
Это вообще-то как бы того.. не того.. одни междометия, предлоги и че там еще есть.
Меня даже заинтересовало: а как ты пишешь приложения? Или ты только пагинаторы встраиваешь?

Спустя 8 минут, 13 секунд (1.07.2010 - 11:04) sergeiss написал(а):
Цитата (linker @ 1.07.2010 - 11:44)
Лично я предпочитаю комбинированный подход, то простое что можно реализовать функциями, должно быть реализовано именно так, сложные структуры и динамику необходимо реализовывать в ООП...


Насколько я понял, ты говоришь не про ООП ("ООП - это ... все программирование должно быть сориентировано на объекты." (с) twin), а только про использование классов!!! А это совсем другое дело.

Цитата (waldicom @ 1.07.2010 - 11:56)
Меня даже заинтересовало: а как ты пишешь приложения? Или ты только пагинаторы встраиваешь?

Уже перчатки полетели... rolleyes.gif

Пошел за чипсами, попкорном и пепси laugh.gif

Спустя 14 минут, 31 секунда (1.07.2010 - 11:18) twin написал(а):
Цитата
Меня даже заинтересовало: а как ты пишешь приложения?

Ты знаешь, а очень просто.
Мне при проектировании совсем не нужно знать таких тонкостей предмета. Потому что я не боюсь попасть в капкан того, что описал, как ты выразился "междометиями". Проектируется база данных и основные модули, которые заявлены в ТЗ. А если потребуются изменения или дополнения, расширяется все приложение путем организации нового модуля. Без оглядки на общий базовый функционал. По причине отсутствия последнего.

Есть данные, они структурированы. Я просто беру эти данные, обрабатываю их нужным образом и получаю результат.

Если мне понадобится расчитать стоимость танспортировки газа через Украину в Германию, я просто напишу этот модуль. Самодостаточный. И в нем будет только то, что относится к газопроводу. Никаких маршруток и прочего дерьма.

И не нужно мне говорить, что это дольше, чем писать наследника, попутно грея голову, как же присуропить эту трубу к базовому классу, в котором колеса и водители. Зачастую это быстрее.

И плевать я хотел, что это апологетами называется "быдлокодинг". Этот фиговый лист они придумали, чтобы опровдать свою несостоятельность.
Разумеется у меня код не идет одной кашей. Есть четкая структура, шаблоны, кэш (если нужен) и так далее.

Что касается обслуживания - однозначно проще. Все на виду - весь относящийся к делу функционал в одном месте.

Это не касается часто используемых классов и функций. Они собраны в отдельной библиотеке и юзаются по мере надобности.

Да, объем кода несколько увеличивается. Но зато потом, если все правильно структурировано, разобраться в нем стократ проще. И не только мне, любому последователю.

Ну и про оптимальность тоже. Я устал повторяться.

Можно по разному решать проблемы скорости и ресурсоемкости. Можно использовать акселераторы, кэш, ленивые загрузки и так далее.

А можно просто этих проблем не создавать. Тогда и решать ничего не придется.

Спустя 4 минуты, 21 секунда (1.07.2010 - 11:23) waldicom написал(а):
Цитата (sergeiss @ 1.07.2010 - 10:04)
Проектируется база данных и основные модули, которые заявлены в ТЗ

КАК?! Как можно спроектировать БД не зная того, что должен уметь конечный продукт?
Возможно, сейчас у тебя в голове подумалось: "я же написал, что есть ТЗ".
Да, но изучая ТЗ ты автоматически изучаешь тонкости логистики/чего-еще-можно-придумать.
А ты напиши приложение не изучая ТЗ, т.е. не вдаваясь в тонкости.
Задание типа такого: напиши бухгалтерию. Все.

Спустя 5 минут, 42 секунды (1.07.2010 - 11:28) twin написал(а):
Цитата
Задание типа такого: напиши бухгалтерию. Все.

Нет. Такиз ТЗ нет и быть не может. Если есть такая задача, то всё как раз и начинается с разработки ТЗ. Если это конечно не 1С. Любая бухгалтерия специфична. Но базовые исходные данные одни - сальдо-бульдо, приход-расход. Вот так и проектируется БД. А если потом потребуется модуль расчета заработной платы, то соответственно БД корректируется и пишется модуль ЗП.

Если проектировать это объектно, я должен предусмотреть ЗП в базовом классе. Иначе мне придется его потом менять. Полиморфизм. Однако всего предусмотреть невозможно, от того и напряги.

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

Спустя 2 минуты, 34 секунды (1.07.2010 - 11:31) waldicom написал(а):
Присоединился к Глоку.

Спустя 3 минуты, 42 секунды (1.07.2010 - 11:35) twin написал(а):
А ты что, отсоединялся? biggrin.gif
Я что то не заметил как то.

ps Я не ставил цель кого то куда то перетягивать. И тем более не ставил цель делить на лагеря. Этот топик для тех, кто пока на распутье. Им есть о чем задуматься. А нас тока могила исправит.

Спустя 1 месяц, 24 дня, 11 часов, 11 минут, 30 секунд (25.08.2010 - 22:46) linker написал(а):
Цитата
Я написал уже несколько раз про множественное наследование, этого не достаточно?
Это бага или отсутствующая фича? Нужны реальные примеры о фичах граничащих с багами и кривизна ООП в PHP. Множественное наследование, это как сожалеть и ругать свою машину, за то, что в ее комплектации нет двухзонного климат-контроля.
Цитата
Кроме того, прощает многие ошибки. Потому и прост в обращении.
Ты не поверишь, но Си тоже прощает многие ошибки. Просто концепция всех Си-подобных языков - программист должен знать, что он делает, а это требует самого главного - профессионализма.
Цитата
А это в свою очередь требует постоянного поиска альтернатив и истин
Истины нет, альтернатив полно.
Цитата
PHP чем и хорош, что можно постоянно находить новые решения, импровизировать
Да, да и ООП и прочее, все это новые решения и импровизации.
Цитата
А ты со своими парадигмами пытаешься затолкать этот многогранный инструмент в рамку ООП. Это рамка, как не крути, ибо накладывает кучу ограничений.
Я? Где?
Цитата
Тот же PMA написан процедурно, а пользуется и хвалит весь мир. Или это маленький проект?
А ты давно заглядывал на сайт PMA? smile.gif Ну так советую обновить свои знания на счет него.
Цитата
А что ты пишешь на конвеере? Магазины? Дак че их писать, все давно написано. И ООП тут вообще не в строчку
Система документооборота вкупе с программным комплексом по автоматизации процессов электронной верстки крупного Российского издательства на базе Woodwing Smart Connection Enterprise.
Цитата
Ну может конечно ты фреймворк сочинил, то тогда да.
Ты догадлив. А еще я использую DOM XML, который тоже на классах. Существующий уровень абстракции моего фреймворка позволяет работать с большим количеством разнообразных данных не применяя кучи классов и витиеватых наследований и прочего. Вся прелесть в том, что технологий-то может и много, но все они стандартизированы и основаны практически на одних принципах и платформах.
Цитата
Только это еще большая дурь, чем ООП в чистом виде.
Дурь - это копи-паст.
Цитата
Когда один пишет один класс, второй - другой, третий пытается все это в кучу слепить.
ТЫ видимо слабо представляешь, что есть коллективная разработка программного продукта. Все тоже самое можно отнести к процедурному программированию, один наштамповал кучу функций, другой еще кучу, третий еще кучу. Потом эти кучи где-то пересеклись в названиях функций, потом где-то с параметрами намудил, потому что один тащится от глобалсов, другой от кучи параметров и прочее. Вполне.
Цитата
Разработать индивидуальный проект, специфичный - вот я посмотрю, как оно тебе поможет.
Любая специфичность стоит на одном фундаменте. Ты можешь придумывать разные задачи, но все они будут строится на том базисе, который доступен Web.
Цитата
почему же все, кто отстаивает позиции ООП парадигмы, придерживаются одних и тех же аргументов. Как под копирку. Мол вот хорошо написанная программа на ООП - это круто. Вот мол все вокруг не умеют писать на ООП, а потому и плохо всё. А вот, мол, я умею - и все хорошо.
Скажу лишь одно: величайшая глупость строить свое мнение о продуктах, из которых было приготовлено криворуким поваром блюдо. Если капля разума есть, то поймешь.
Цитата
А ты просто как обычно не потрудился вникнуть в аргументы.
Понимаешь, аргументы - это вещи, которые можно потрогать, а аморфные сопли, пускаемые исключительно по субъективным соображениям, таковыми не являются. Я реально не слышал от тебя, ни одного весомого аргумента, что ООП не нужно в PHP и что ООП - это зло. Си не нужно, ибо до него было множество языков, С++ не нужен, ибо Си самодостаточен, Dephi не нужно, ибо есть C++. Слова и языки, понятия разные, вот только суть одна.
Цитата
Может я и не умею готовить, однако я не видел того, кто бы умел
Сочувствую.
Цитата
Самое смешное, обычно вы сами себя же какой и поливаете. Кто, мол, так пишет на ООП?
Если кто-то пишет, то причем здесь я и причем здесь ООП и причем здесь ООП. Читайте абзац про повара.
Цитата
Причем тут флэш теперь? И XML причем? Речь шла о шаблонизации. О том, как разделить PHP и HTML (твои слова), а не о других стандартах.
Про флэш, опять же не я начал, главное что я помог понять, что это было лишним и что флэш тут действительно не причем. А что есть HTML и XML? Видимо они настолько разные, что даже их ничего не роднит.

Спустя 11 часов, 34 минуты, 31 секунда (26.08.2010 - 10:21) twin написал(а):
Ого! Как я пропустил...
Цитата
Множественное наследование, это как сожалеть и ругать свою машину, за то, что в ее комплектации нет двухзонного климат-контроля.

Это не климат-контроль. Это когда в машине нет задней скорости. Конечно, можно развернуться, и АЛГА! Но я бы сильно задумался, нужна ли мне такая машина.
Цитата
Ты не поверишь, но Си тоже прощает многие ошибки. Просто концепция всех Си-подобных языков - программист должен знать, что он делает, а это требует самого главного - профессионализма.
Поверю, почему это нет? Я сам прогаю на сишке и знаю что и как она прощает. Но с PHP то не сравнивай. Конечно каждый должен знать что делает. Но в том вся и разница, что в PHP очень много уже сделано и вполне достаточно.
Цитата
Истины нет, альтернатив полно.
Истин, как и альтернатив полно. У каждого своя правда. Именно потому, что PHP - язык неортогональный. Но программист, буде зажат в рамки фреймворка (а иначе зачем ООП), вынужден играть только по правилам фреймворка. А это рамка, как та её не обзывай и как от неё не открещивайся. Если в классе, который я вынужден слепо использовать по принципам инкапсуляции, вдруг найдется какая то бага, я становлюсь заложником. Ибо не могу контролировать и влиять на процесс. А то, что твои классы идеальны - расскажи кому нибудь из раздела "начинающим". Даже ZEND-фреймворк публикует до 50 поправок в месяц. И это процесс бесконечный.
Цитата
А ты давно заглядывал на сайт PMA?
Ты про какой? Я про PhpMyAdmin. Ну зашел и чё... Ничего нового.

Цитата
Система документооборота вкупе с программным комплексом по автоматизации процессов электронной верстки крупного Российского издательства на базе Woodwing Smart Connection Enterprise.
Ну а о чем мы тогда разговариваем? Я же говорю о свободном программировании. И говорил, что этого не понять тем, кто зажат корпоративными законами и текущим проектом. Естественно тебе придется подстраиваться под систему, куда деваться.
Я же говорил о индивидуальных проектах, с нуля и под ключ.
Цитата
Ты догадлив. А еще я использую DOM XML, который тоже на классах. Существующий уровень абстракции моего фреймворка позволяет работать с большим количеством разнообразных данных не применяя кучи классов и витиеватых наследований и прочего. Вся прелесть в том, что технологий-то может и много, но все они стандартизированы и основаны практически на одних принципах и платформах.
Ну поздравляю. Еще один самый лучший в мире фреймворк... Просто ляля. Конечно же, имея такую платформу можно гордо заявлять:
Цитата
Дурь - это копи-паст.

Он же сам все делает. И корованы наверно грабит. Только я писал уже выше - до поры до времени.
Цитата
ТЫ видимо слабо представляешь, что есть коллективная разработка программного продукта. Все тоже самое можно отнести к процедурному программированию, один наштамповал кучу функций, другой еще кучу, третий еще кучу. Потом эти кучи где-то пересеклись в названиях функций, потом где-то с параметрами намудил, потому что один тащится от глобалсов, другой от кучи параметров и прочее. Вполне.
Нет. Бесполезно что то говорить. Начитались вумных книжек и теперь боитесь собственной тени. Ну надо же - страх то какой, пересеклось название функции! Всё, проект на смарку.
Только это все опять не с той стороны. Пересечься они могут только в общей системе. Когда грузится все и сразу. А когда прект делается модульно - этого быть не может по определению.
Вот и получается замкнутый круг. Чтобы спроектировать ООП приложение, нужно учитывать проблему пространства имен, ибо это единый организм. А для того, чтобы избежать пересечений - используем ООП.
Прогресс.. Используя кулинарную терминологию - нам нужно приготовить обед. Первое, второе и третье. Можно приготовить в разных кастрюльках по очереди, а можно изобрести одну большую с тремя отделениями и готовить все сразу. Наплевав на побочные эфекты. Главное, что бы не распыляться. Моощь.
Цитата
Любая специфичность стоит на одном фундаменте. Ты можешь придумывать разные задачи, но все они будут строится на том базисе, который доступен Web.
ой ли? Не свой ли фреймворк ты к этому базису прировнял? В том и дело, что вариантов больше чем в шахматах на порядки, а ты все заладил: е2-е4. А гамбитов то сонмы и новые придумывать не запрещено. От того и интересно заниматься программированием. Так что если глубже копнуть, возникает вопрос - кто же из нас занимается копипастом?
Цитата
Скажу лишь одно: величайшая глупость строить свое мнение о продуктах, из которых было приготовлено криворуким поваром блюдо.

Да не спорю я. Это ты споришь как раз. Дело в том, что с точностью до наоборот, нельзя судить о продукте по блюду, приготовленном одним искуссным поваром. Китайцы умеют делать конфеты из сала, так давай будем везде кричать, что оно сладкое. smile.gif
Основная масса народу не умеет писать на ООП. А инструмент дан. И изрядно пропогандируется. Натворят с дуру чего попало, потом удивляются сами себе.
Потому как сами понять не могут, чего же такое сотворили. По этому это:
Цитата
Если кто-то пишет, то причем здесь я и причем здесь ООП и причем здесь ООП. Читайте абзац про повара.
относится именно к тебе. Я не стану поднимать тему, где ты сам писал, что за такое руки надо отрывать. И писал это человеку, который тоже постоянно приводит аргументы о плохо приготовленной пище. Впрочем я помню и обратное.
Цитата
Понимаешь, аргументы - это вещи, которые можно потрогать, а аморфные сопли, пускаемые исключительно по субъективным соображениям, таковыми не являются. Я реально не слышал от тебя, ни одного весомого аргумента, что ООП не нужно в PHP и что ООП - это зло.
Аргумент, это утверждение, которое приводится в подтверждение другого утверждения. Его потрогать никак нельзя. Его можно только осмыслить. А этого ты упрямо делать нехочешь.
Я привел много доводов и аргументов, не буду повторяться. В стартовом посте и далее по тексту. И звучали они по всем канонам. Обозначена проблема, рассмотрены последствия, предложены альтернативные пути. Если это для тебя сопли, а вот такие аргументы
Цитата
Это было 15 лет назад, если ты не заметил, то на дворе 21-век и время homepage давно уже прошло. PHP вырос в инструмент профессиональных web-разработчиков и с этим надо мириться.

скала, так о чем разговор. Переливание из пустого в порожнее.

Людям свойственно ошибаться. И в прогрессе тоже. На луну летали - прогресс. Какой толк? Только что тефлон придумали. А наши вообще реки вспять повернуть хотели - во прогресс. Всему слепо верить?

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

Спустя 11 минут, 16 секунд (26.08.2010 - 10:32) Basili4 написал(а):
Опять холиварите? не надоело еще.....

Спустя 6 минут, 56 секунд (26.08.2010 - 10:39) twin написал(а):
А в риторике потренироваться? biggrin.gif
Все холивары имеют именно эту цель. Переубедить в них ни кому ни кого не удавалось. smile.gif

Спустя 4 минуты, 44 секунды (26.08.2010 - 10:44) Basili4 написал(а):
twin
я бы сказал в софистике

Спустя 15 минут, 36 секунд (26.08.2010 - 10:59) Dingo написал(а):
Цитата
Прогресс.. Используя кулинарную терминологию - нам нужно приготовить обед. Первое, второе и третье. Можно приготовить в разных кастрюльках по очереди, а можно изобрести одну большую с тремя отделениями и готовить все сразу. Наплевав на побочные эфекты. Главное, что бы не распыляться. Моощь.

Это шикарные слова biggrin.gif

Спустя 1 час, 30 минут, 26 секунд (26.08.2010 - 12:30) linker написал(а):
Цитата
Но в том вся и разница, что в PHP очень много уже сделано и вполне достаточно.
В сях тоже достаточно сделано, однако это не помешало появлению плюсов.
Цитата
У каждого своя правда.
Истина объективна, а своя правда - это субъективизм.
Цитата
Я про PhpMyAdmin. Ну зашел и чё... Ничего нового.
Я тоже и что даже ООП там в сорцах не заметил?
Цитата
Я же говорю о свободном программировании. И говорил, что этого не понять тем, кто зажат корпоративными законами и текущим проектом.
Ты не поверишь, но я абсолютно не зажат корпоративными рамками, я волен выбирать, что мне нравится и как мне нравится, главное качественный результат.
Цитата
Он же сам все делает. И корованы наверно грабит. Только я писал уже выше - до поры до времени.
Ты не понимаешь сути фреймворка, это не цмс, это удобная обертка позволяющая быстро реализовывать задачи. Он не ставит задачи выводить новости, он не знает что такое меню, что такое форум, комментарий и прочее. Все это может знать цмс, но никак не фреймворк.
Цитата
Когда грузится все и сразу. А когда прект делается модульно - этого быть не может по определению.
Цитата
Разочарую тебя, один и тот же модель может подгребать под себя кучу библиотек.ой ли? Не свой ли фреймворк ты к этому базису прировнял? В том и дело, что вариантов больше чем в шахматах на порядки
Базис атомарен, много ли операций существует при работе с файлами, потоками, сокетами? Я знаю только две - ввод/вывод. Что есть база данных? Хранилище данных, тоже самое можно сказать и про XML и про директорию, хранящую файлы и прочее. А много ли операций можно производить с этими данными? Четыре атомарных: найти, добавить, изменить, удалить. Все это и есть база - фундамент, платформа, на которой можно построить все что угодно.
Цитата
Китайцы умеют делать конфеты из сала, так давай будем везде кричать, что оно сладкое.
Если ты не любишь сало, то причем здесь повар, приготовивший из него конфету?
Цитата
Основная масса народу не умеет писать на ООП. А инструмент дан.
Это личная проблема инструмента? С++ тоже дан как инструмент, вот только народу не умеющего на нем писать еще больше. Еще раз повторяю, не умеешь пользоваться инструментом - не трогай его, если я не умею варить металл, то я и не берусь за сварочный аппарат. Не умеешь водить машину, не садись за руль, а по твоим словам получается, я вот не умею, но сажусь и в этом машина сволочь виновата.
Цитата
Я не стану поднимать тему, где ты сам писал, что за такое руки надо отрывать
Надо отрывать и за "Hellow world" в MVC тоже надо руки отрывать. И за говнокод процедурный тоже надо руки отрывать. smile.gif Я и сам далеко не идеал.
Цитата
Аргумент, это утверждение, которое приводится в подтверждение другого утверждения. Его потрогать никак нельзя.
Аргумент - это неоспоримое утверждение, как аксиома. Он не аморфен, а значит его можно потрогать.
Цитата
Я привел много доводов и аргументов, не буду повторяться
Много рассуждений да, но ни аргументов, ни неоспоримых доводов не было и не будет, ибо исходишь ты исключительно от собственного мнения. А все твои так называемые аргументы и доводы легко перекладываются с ООП на процедурки. Те же яйца, только в профиль.
Цитата
И в прогрессе тоже. На луну летали - прогресс. Какой толк
Если для тебя толку никакого, то это не значит что для других тоже его нет, не слишком ли на себя берешь?
Цитата
Я хочу действительно обоснованных доводов.
Если хочешь, то спустись со своей колокольни.

Спустя 12 минут, 15 секунд (26.08.2010 - 12:42) DedMorozzz написал(а):
glock18 тут не хватет smile.gif

Спустя 1 минута, 51 секунда (26.08.2010 - 12:44) linker написал(а):
DedMorozzz
Да мы просто мозги размять малясь smile.gif

Спустя 1 час, 34 минуты, 37 секунд (26.08.2010 - 14:18) Basili4 написал(а):
и пальцы biggrin.gif

Спустя 47 минут, 42 секунды (26.08.2010 - 15:06) twin написал(а):
Цитата
В сях тоже достаточно сделано, однако это не помешало появлению плюсов.
Естественно. Я же не призываю останавливаться на достигнутом. Но PHP тоже на сях написан. И написан именно для того, чтобы решать специфические задачи для ВЕБ. И написан так, чтобы не нужно было задумываться о том, что веб-приложениям мягко скажем излишне.
В сях есть куча библиотек, все они тоже призваны решать свои специфичные задачи. Однако никому не приходит в голову использовать их все при компиляции.

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

Цитата
Аргумент - это неоспоримое утверждение, как аксиома. Он не аморфен, а значит его можно потрогать.

Хочешь потрогать аргументов? Их будет Вам.
Я просто думал, что то, что я описал абстрактно, любой программист может сам спроецировать на практическую плоскость.

Возьмем к примеру фреймворк. Не скажу какой. В частности нам нужно сделать текстарею. Как любят говорить твои соратники: "пишем незадуряясь:
     $obj = new field_textarea('text', '', true, 'text'); 
$textarea = $obj -> get_html();
echo $textarea[1];

и получаем красоту:
<textarea  name="text"  cols=35 rows=7>text</textarea>
Здорово. Автоматика.
А теперь посчитаем символы. С фреймворком 88 штук, а если пишем тоже ручками:
<textarea  name="text" cols=35 rows=7 ><?php echo htmlspecialchars($text) ?></textarea>
, то 87.
Один ноль в пользу отказа от фреймворка.
Дальше. Померяем время, которое требуется на генерацию ареи с помощью фреймворка: 0.0016 c. И это на генерацию одного элемента.
Второй вариант мерять нечего. Очевидно:
2:0
Идем дальше. Оперативка. Базовый класс и класс-наследник, генерящий этот элемент весят 8 килобайт. Против нуля без фреймворка.
3:0
Да, конечно, в классе есть небольшенькая проверочка. Но разница по величине кода, если написать её процедурно, не соизмерима.

Далше прозрачность. Любой начинающий прогер знает, что такое тег <textarea> и с чем его едят. А попробуй ты сказать, что куда нужно написать в этом синтаксисе, чтобы было корректно?
$obj = new field_textarea('text', '', true, 'text'); 

Ни за что не скажешь, пока доку или сорцы не посмотришь.
4:0
Дальше. Этот фреймворк разбит на кучу классов. Для каждого элемента - свой наследник. Тут одно из двух - либо загружать все сразу, либо гонять автолоад. И то и другое - совершенно излишне и избыточно.
5:0
Продолжать? Для меня вполне достаточно.

Цитата
Если ты не любишь сало, то причем здесь повар, приготовивший из него конфету?

Я люблю сало. Но люблю его с лучком, молодой картошечкой и под графинчик. А конфеты из сала пусть китайцы едят. Все хорошо на своих местах. ООП в объектных языках, процедурка в скриптовых.
Цитата
Это личная проблема инструмента?

Да. Это становится не просто проблемой, а чуть ли не трагедией. Был красивый уютный котедж, приперлись глобалисты и стали пристраивать к нему кучу этажей, мотивируя тем, что небоскреб - это круто. А что он совсем для этого не приспособлен (ни коммуникаций, ни инфраструктуры, ни толкового проекта даже) - никого не волнует. Не пристало в котеджах жить. Прогрессс!! Все живут в небоскребах, и мы туда же.

Цитата
Если для тебя толку никакого, то это не значит что для других тоже его нет, не слишком ли на себя берешь?
Я то тут причем? Не я же допер, что это не окупается? Или я отказался от этого проекта? Есть условия, когда прогресс заводит не совсем туда, куда хотелось бы. И фанатеть от того, что на дворе 21-й век, только потому что он наступил - не для меня. Я хочу ясных и четких аргументов.

Я их добросовестно искал. Результаты в первом посте. Парируй по пунктам, если сможешь.


Спустя 43 минуты, 36 секунд (26.08.2010 - 15:50) linker написал(а):
Цитата
Но PHP тоже на сях написан. И написан именно для того, чтобы решать специфические задачи для ВЕБ
А нафига, когда перловка удовлетворяла все мыслимые потребности?
Цитата
В сях есть куча библиотек, все они тоже призваны решать свои специфичные задачи. Однако никому не приходит в голову использовать их все при компиляции.
А кто тебе сказал, что нужно использовать в каждом скрипте все описанные классы? Чем класс с набором методов запихнутый в отдельный файл отличается от такого же файла, но с процедурками?
Цитата
А ООП в PHP - это откат обратно. Потому что сам язык PHP был придуман для облегчения разработки именно ВЕБ приложений. И развивался он так.
Но в определенный момент кто то вдруг решил, что на нем можно писать огромные цельносварные программы и понеслось.
Чем вызвано такое утверждение, что ООП это откат назад? И почему ООП не облегчает разработку (и не надо про цепочки наследований, это все бред низкокачественного кодинга)?
Цитата
Хочешь потрогать аргументов? Их будет Вам.
88 против 87, ахринеть разница, вот только искать в куче html-говна, вкрапления <?php?> то еще удовольствие. Непонятно зачем так
$textarea =  $obj -> get_html();
echo $textarea[1];
почему массив, имхо это пример из говнокода. Но, теперь представим, что у тебя 50 скриптов и в каждом втиснут твой html-вариант, и вдруг понадобилось срочно везде привязать событие onblur(), тебе придется лазать по всем скриптам и менять код, вместо того, чтобы залезть в класс и изменить только в одном месте. 1 байт потерял, зато потом сэкономил кучу времени.
Цитата
А попробуй ты сказать, что куда нужно написать в этом синтаксисе, чтобы было корректно?
smile.gif если ты используешь этот класс, то ты знаешь для чего оно и как работает. Примеров я приводил достаточно - не зная броду не лезь в воду, а пиши обычным HTML. Ну будет функция например
Цитата
field_textarea('text', '', true, 'text');
что? Стало понятнее, что тут за аргументы? Нет, конечно. Те же яйца только в профиль. Если видоизменить
$obj = new field_textarea('text', '', true, 'text'); 
echo $obj -> get_html();
уже короче, потом я могу написать
$obj->text = $newtext;
echo $obj -> get_html();
а тебе опять придется писать
<textarea  name="text" cols=35 rows=7 ><?php echo htmlspecialchars($newtext) ?></textarea>
и т.д. в результате чем больше проект, тем больше плюсов накапливается за ООП.
Цитата
Да. Это становится не просто проблемой, а чуть ли не трагедией. Был красивый уютный котедж, приперлись глобалисты
Так это коттедж виноват, что приперлись глобалисты?
Цитата
Парируй по пунктам, если сможешь.
Обязательно, но чуть погодя, домой уже пора.

Спустя 57 минут, 49 секунд (26.08.2010 - 16:48) twin написал(а):
Цитата
А нафига, когда перловка удовлетворяла все мыслимые потребности?
А ты писал на ней? Ничего она не удовлетворяла. Потому PHP и обошел её на повороте. Пусть апологеты расширяются на его нестройность и вседозволенность. Но он проще и функциональнее.
Цитата
А кто тебе сказал, что нужно использовать в каждом скрипте все описанные классы? Чем класс с набором методов запихнутый в отдельный файл отличается от такого же файла, но с процедурками?
Мне никто не говорил. Это вы так делаете. Ну да, подгружаются нужные классы в процессе, не спорю. Но проектируется приложение как единый организм. И очень часто так и есть - все грузится сразу. Тот же ZEND или этот фреймворк, который ты обозначил
Цитата
имхо это пример из говнокода.
А ведь это SoftTime FrameWork, его авторы - авторы книги "Объектно-ориентированное программирование на PHP".
Я же говорю - напишите всякой ереси и потом друг друга за космы таскаете. Я уверен - посмотри они твой суперкод скажут тоже самое.

Потому что нормальный код на ООП написать невозможно. PHP для этого не предназначен. Есть виртуозы конечно, могут и на пиле лунную сонату исполнить. Но исключения только подтверждают правило.

Но ближе к телу.
Цитата
Но, теперь представим, что у тебя 50 скриптов и в каждом втиснут твой html-вариант, и вдруг понадобилось срочно везде привязать событие onblur(), тебе придется лазать по всем скриптам и менять код, вместо того, чтобы залезть в класс и изменить только в одном месте.
Воооот. Классический аргумент, заученный из первого букваря по ООП и совершенно не проанализированный. Я часто с такими аргументами встречаюсь.

Так вот. Никогда. Не бывает. Таких. Ситуаций. Это. Фантастика. Не меняются сразу все злементы. Если это стиль - то решается классом CSS. А функционал - никогда.

Ну даже если представить на секунду, что возникла такая потребность.
1. Она может возникнуть один раз в тысячу лет, а скрипт всю эту тысячу будет молотить впустую. В тайной надежде, что вдруг кому-то понадобится onblur() на 50 элементах.
2. Ты собрался менять класс. А как же инкапсуляция? Рожать наследника нельзя - придется менять вывод во всех 50 страницах. Значит пикнула.
3. А если в 50 элементах понадобится поставить onblur(), а в остальных 100 - нет? Класс изменишь - все изменится. Значит таки менять вызов. Чем отличается?
4.
Цитата
вот только искать в куче html-говна, вкрапления <?php?> то еще удовольствие.
А как же вывести элемент из фреймворка? Вот это как?
echo $obj -> get_html();

В чем принципиальная разница? Все равно придется юзать или натив или шаблонизатор. Ибо третьего не дано (говнокод опускаем). Только не нужно приплетать XML, тут речь не о нем совсем.

С функцией да - непонятно. Но ведь и функция тут нафиг не нужна. Не то, что фреймворк ООПэшный. Если это элемент формы, то и надо писать элемент формы, а не какие то хрен пойми
Цитата
$obj = new field_textarea('text', '', true, 'text');
Это же касается и всего остального. Есть конструкция ECHO, так нет, нужно сделать
$obj -> display();

Что за писанина... детский сад.

Цитата
а тебе опять придется писать
<textarea  name="text" cols=35 rows=7 ><?php echo htmlspecialchars($newtext) ?></textarea>
и т.д. в результате чем больше проект, тем больше плюсов накапливается за ООП.
Только не договорил. Плюсов на стадии разработки.
Вот и камень преткновения. В погоне за эфимерной сиюсекундной выгодой не замечается такое бревно в глазу, что становится не по себе. Это сколько же "обманутых вкладчиков", которым подсунули вместо оптимальных скриптов то, что быстрее разрабатывается, но плохо работает...
Пишешь то ты один раз. И экономишь час-день-неделю. Это тоже под вопросом, сам класс тоже написать надо. А работает скрипт потом кучу лет, принося незабываемые моменты заказчику, который иногда хочет изменить чтото на сайте и не может найти спеца, который это все распутал бы. И жрет его ресурсы.
Да конечно - своя рубашка ближе к телу.

Цитата
Так это коттедж виноват, что приперлись глобалисты?
Это глобалисты виноваты, что приперлись. И превратили программирование в штамповальный станок.

Скорее-выше-сильнее! Даешь больше сайтов - хороших и разных! Ударим ООП по бездорожью, разгильдяйству и бюрократизму! Индустриализация!

Думать зачем... Фреймворк подумает.

Спустя 1 час, 1 минута, 35 секунд (26.08.2010 - 17:49) Guest написал(а):
twin
Размышляя о "высоком" ты забыл учесть несколько мелочей. Так бывает, когда полагаешься исключительно на свои знания и сообразительность. С таким потходом можно вполне доказать, что земля квадратная, а все красивые бабы - ведьмы.
ООП удобней! Для того и придумано. Аргументировать и доказывать не вижу смысла, просто на заметку может тебе стоит пересмотреть свои взгляды на эту тему самостоятельно?

Спустя 8 минут, 42 секунды (26.08.2010 - 17:58) twin написал(а):
Guest

Ровно тоже самое могу сказать и обратно. smile.gif

Цитата
Размышляя о "высоком" ты забыл учесть несколько мелочей. Так бывает, когда полагаешься исключительно на свои знания и сообразительность. С таким потходом можно вполне доказать, что земля квадратная, а все красивые бабы - ведьмы.


Вот и сожгли Джордано Бруно, потому что усомнился. smile.gif А говорили - не доказывай. Прими как должное.
Цитата
ООП удобней! Для того и придумано. Аргументировать и доказывать не вижу смысла
Конечно, какой смысл... Ему же сказали: УДОБНЕЙ!

Получается есть два мнения - твоё и ошибочное.

Удобней в чем? Кому? Эй! Алё! Ты вообще читал, что я пишу?
Немного вдумайся, а не повторяй зазубренные проповеди. Я их пачками читал, только все бездоказательно. Нет же смысла доказывать. smile.gif

Спустя 7 минут, 5 секунд (26.08.2010 - 18:05) twin написал(а):
Еще одна ассоциация насчет удобней.
Есть у машин коробка-автомат, и есть ручная. Автомат наварочен, сложен в ремонте и обслуживании, но естественно удобнее.
Но если его поставить на внедорожник - получится парктник.
Так и тут. Не туда его суют. Хотя и удобнее на первый взгляд.

Спустя 6 минут, 21 секунда (26.08.2010 - 18:11) waldicom написал(а):
Цитата (twin @ 26.08.2010 - 17:05)
Автомат наварочен, сложен в ремонте и обслуживании

вы хотите поговорить об этом?

Спустя 3 минуты, 46 секунд (26.08.2010 - 18:15) twin написал(а):
А я что делаю? smile.gif

Спустя 54 минуты, 50 секунд (26.08.2010 - 19:10) Guest написал(а):
twin
ты не прав и не надо меня кусать. Пиши себе по старинке и радуйся жизни. Я думал ты умнее.

Спустя 4 минуты, 16 секунд (26.08.2010 - 19:14) Guest написал(а):
Ассосиации еще какие то невтемачные - это типа должно что то доказывать? Короче, я давно просек, что ты не настоящий самурай и не я один.

Спустя 45 минут, 13 секунд (26.08.2010 - 19:59) twin написал(а):
Пришел, увидел, нагадил наследил. Самурай...

Спустя 46 минут, 36 секунд (26.08.2010 - 20:46) Mizka написал(а):
Цитата
Ты собрался менять класс. А как же инкапсуляция? Рожать наследника нельзя - придется менять вывод во всех 50 страницах. Значит пикнула.

а все же почему низя рожать? smile.gif)))

п.с. возможно я что-то не прочел (уж очень много букв), но наследование не нарушает инкапсуляцию

Спустя 36 минут, 51 секунда (26.08.2010 - 21:23) Mizka написал(а):
Цитата
ты не прав и не надо меня кусать. Пиши себе по старинке и радуйся жизни. Я думал ты умнее.

ООП не означает, что это какие-то инновации, хотя оно и появилось как результат развития процедурного программирования, но это было ещё в 1967 году.
В PHP многие пишут класс с набором методов бездумно... и считают это ООП хотя это действительно бессмысленно. 99% таких тасков можно реализовать процедурным подходом намного эффективнее...

Но если уметь использовать правильно ООП, паттерны проектирования можно действительно упростить разработку. Но лучше об этом не начинать, не хочется втягиваться в долгую дискуссию biggrin.gif

Спустя 15 минут, 55 секунд (26.08.2010 - 21:39) twin написал(а):
Цитата
а все же почему низя рожать?

Ну ты действительно не дочитал. Дело в том, что речь о изменении готового скрипта. А там вызовы уже прописаны. Родишь наследника - что толку. Вызван то другой.

Цитата
В PHP многие пишут класс с набором методов бездумно... и считают это ООП хотя это действительно бессмысленно. 99% таких тасков можно реализовать процедурным подходом намного эффективнее...
Воооот. Золотые слова. А то как этот самурай нахватаются верхушек и считают, что Бога за бороду схватили. А по сути пишут тот же говнокод только с ООП уклоном.
Цитата
Но если уметь использовать правильно ООП, паттерны проектирования можно действительно упростить разработку.
Ключевое слово - разработка. Я о чем и талдычу всегда. Сэкономили немного на разработке и получили продукт, который сложно обслуживать, да и оптимальным никак назвать нельзя.

Устал я повторяться. Ухожу. Я все сказал, кому интересно - 13 страниц спереди. Читайте.

Спустя 21 минута, 9 секунд (26.08.2010 - 22:00) Dingo написал(а):
Цитата
Но если уметь использовать правильно ООП, паттерны проектирования можно действительно упростить разработку.

У, а ООП можно использовать не правильно, это как? все сводится к работе с классами, если архитектура класса написан,как в трактате о паттернах проектирования, то это ООП код, если нет, то извините это просто класс. Если хотите полную ООП жизнь, а не жалкое подобие, то Руби на рельсах вас ждет. wink.gif

Спустя 1 минута, 27 секунд (26.08.2010 - 22:01) Dingo написал(а):
Если же рассматривать классы как ООП, то такое ООП несомненно нужно в PHP

Спустя 16 минут, 57 секунд (26.08.2010 - 22:18) Mizka написал(а):
Цитата
У, а ООП можно использовать не правильно, это как?

дело в том что пхп изначально не объектно ориентированный язык, до 5 версии это было вообще жалкое подобие поддержки ООП. Формально - да... все где присутствует класс/объект это объектно-ориентированное программирование. Дело в том что пхп это язык который предоставляет возможность использовать и ОО программирования и функциональное, что является его + (ну тут субъективное мнение). Функциональное программирование намного проще ОО, не надо забивать гвоздь кувалдой если можно это сделать молотком. Зачем усложнять жизнь smile.gif

Спустя 1 час, 20 минут, 39 секунд (26.08.2010 - 23:39) linker написал(а):
Итак, понеслась душа по кочкам smile.gif...
Цитата
А ты писал на ней? Ничего она не удовлетворяла.

Я начинал с Perl и очень удивлялся нафига нужен PHP. Но потом сообразил, что PHP будет в фаворе, т.c. поймал волну, хотя perl меня всем удовлетворял и не было ничего такого, чтобы можно было в PHP и нельзя в Perl.
Цитата
Мне никто не говорил. Это вы так делаете. Но проектируется приложение как единый организм.
Я так делаю? С чего это ты взял? Сам придумал или кто подсказал такую ахинею? Любое приложение существует как единый организм, разброд и шатания недопустимы, иначе нарушается целостность, а следовательно и сама работа приложения. Фреймворк существует отдельно, как фундамент, на который можно и коттедж водрузить и небоскреб и любой другой гараж, который только заблагорассудится.
Цитата
А ведь это SoftTime FrameWork, его авторы - авторы книги
Мда, странно... видимо аля Поповы.
Потому что нормальный код на ООП написать невозможно. PHP для этого не предназначен
С чего это ты взял?
Цитата
Так вот. Никогда. Не бывает. Таких. Ситуаций. Это. Фантастика. Не меняются сразу все злементы. Если это стиль - то решается классом CSS. А функционал - никогда.
Ты не поверишь, но бывает. Я же сказал, событие onblur или ты и его через CSS тоже менять будешь? Собственно это только пример, вариантов возможного рефакторинга миллионы. Если ты пишешь приложение, то приготовься через некоторое время провести ему ревизию. Даже отлично написанный код нуждается в доработках и оптимизации.

А я как раз хотел про XML. Я опущу реализацию. Банальный пример, для меня, вывод полос. Есть шаблон (один из возможных вариантов описания) для отображения отдельно взятой полосы
<Template Class="TObject">
<Property
Name="FrameLayout" />
<Property
Access="Public" />
<Source>

<![CDATA[<div id="{%Id}" class="FrameLayout">
<span
class="LayoutDescription">{%ObjectModifier}<br>{%ObjectModified}</span><br>
<img
src="{@LayoutLocation}">
</div>
]]>
</Source>
</Template>


Есть сервак, 5 баз данных, каждая из баз данных относится к пяти другим сервакам где происходит основной процесс верстки. Допустим надо отобразить полосы указанного издания, указанного номера.
$Layouts = $ObjectsLocation->apiGetObjects('TLayout', array('ObjectPublication' => $Pub, 'ObjectIssue' => $Issue), array('ObjectCPolosa' => 'asc'));
if (!$Layouts->apiCount()) { /* Нет полос*/ return; }
$Xml = TCore::$Kernel->apiCreate('TXml', array('Location' => FRAMEWORK__TEMPLATES . '/template.layout.xml'));
$LayoutTemplate = $Xml->apiGetObject('', array('Name' => 'FrameLayout'));
$Result = '';
foreach($Layouts as $Layout)
{
$Layout->apiSetArguments(array('LayoutLocation' => $Layout->apiGetPreviewLocation($PreviewSize));
$Result .= $Layout->apiInterpreterObject($LayoutTemplate);
}
echo $Result;

Как видно, основная суть - какие объекты я хочу получить и как мне их отобразить, все остальное - абстракция. Я с XML-файлом $Xml общаюсь точно так же, как и c таблицей в базе данных $ObjectsLocations. Точно также я могу обращаться к CSV файлам, к директориям в которых лежат файлы или FTP и прочее. А теперь перенос написанного в другой проект, например, вывод новостей. Опускаем создание базы данных, таблиц. Изменяем шаблон
<Template Class="TObject">
<Property
Name="NewsTemplate" />
<Property
Access="Public" />
<Source>

<![CDATA[<div id="{%Id}">
<h1>
{%NewsHeader}</h1><br>
{%NewsAuthor} - {%NewsDate}<br>
{%NewsSnippet}
</div>]]>
</Source>
</Template>

Добавляем класс в отдельный файлик
class TNews extends TObject
{
// Более ничего не нужно, все необходимое унаследовано от TObject
}

Правим код
$NewsContainer = $ObjectsLocation->apiGetObjects('TNews', array(), array('NewsDate' => 'desc'));
if (!$NewsContainer->apiCount()) { /* Нет новостей */ return; }
$Xml = TCore::$Kernel->apiCreate('TXml', array('Location' => FRAMEWORK__TEMPLATES . '/template.news.xml'));
$NewsTemplate = $Xml->apiGetObject('', array('Name' => 'NewsTemplate'));
$Result = '';
foreach($NewsContainer as $News)
{
$Result .= $News->apiInterpreterObject($NewsTemplate);
}
echo $Result;

Все, пять минут и мы от вывода полос издательской системы перешли к выводу новостей в каком-нибудь портале. И последний фич, вдруг надо все новости экспортнуть в XML и в совершенно другом месте, например, импортнуть.
Экспорт:
$NewsContainer = $ObjectsLocation->apiGetObjects('TNews', array(), array('NewsDate' => 'desc'));
$Xml = TCore::$Kernel->apiCreate('TXml', array('Location' => FRAMEWORK__TEMP . '/export.news.xml'));
$Xml->apiInsert($NewsContainer);
Импорт:
$Xml = TCore::$Kernel->apiCreate('TXml', array('Location' => FRAMEWORK__TEMP . '/export.news.xml'));
$NewsContainer = $Xml->apiGetObjects('TNews');
$ObjectsLocation->apiInsert($NewsContainer);

Спустя 1 минута, 18 секунд (26.08.2010 - 23:40) linker написал(а):
Теперь попробуй возразить, что ООП не поддается переносу из одного проекта в другой.
Цитата
И превратили программирование в штамповальный станок.
Уж извините, это моя профессия, я этим зарабатываю себе на жизнь и своей семье. Программирование - это не хобби гикнутых единиц. Если ты занимаешься каким-то делом, то это дело должно приносить определенную пользу и иметь некоторый жизненный смысл иначе грош цена такому занятию, лучше вообще ничего не делать - больше пользы будет.

Спустя 18 минут, 9 секунд (26.08.2010 - 23:58) Dingo написал(а):
Цитата (linker @ 26.08.2010 - 20:40)
Программирование - это не хобби гикнутых единиц

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

Спустя 5 минут, 27 секунд (27.08.2010 - 00:04) linker написал(а):
Dingo
Для меня это было хобби, пока я штаны протирал в школе и универе, когда клепал вирусняки под досом, когда разрабатывал свою операционку, но все проходит. Семья, дети, квартира, машина накладывают определенную ответственность и обязанности.
Видимо у вас все еще впереди.

Спустя 5 часов, 48 минут, 3 секунды (27.08.2010 - 05:52) twin написал(а):
Всё, что ты написал про XML, очень специфично и не имеет широкого применения. Здорово, я ничего не говорю, однако это местечковый подход, нельзя его проецировать на весь язык. А именно об этом была речь. Как писать паблик и продакшен проекты.

Вообще самая лучшая работа - это хорошо оплачиваемое хобби. Я именно по этому и занимаюсь программированием. И всячески стараюсь, чтобы кроме денег (а одним из моих заработков как раз является рефакторинг) работа приносила удовольствие. Для денег я уже наработался, когда занимался бизнессом, теперь пора и о душе подумать. smile.gif

Так вот, занимаясь рефакторингом, я могу со всей ответственностью заявить - не бывает таких ситуаций, когда нужно изменить свойства кучи элементов. Если и бывает, то крайне редко. Мне вот не приходилось и я не представляю такой задачи, где это бы могло потребоваться. А вот с ошибками проектирования ООП приложений сталкиваюсь чуть ли не каждый день. А исправлять их куда сложнее, чем ошибки процедурного кода.

Да и собственно сами классы в PHP, если приложение реализовано на ООП, обычно используются единожды, служат в основном какой то упаковкой, для сомнительной красоты в основном и пространств имен. Ибо (повторюсь все-таки) нет при разработке ВЕБ приложений надобности в таком подходе. Если есть необходимость повторного использования участка кода - вопросов нет. Очень удобно использовать класс. Но это не есть ООП. ООП - это программирование объектами. Которые в вебе по определению не могут использоваться многократно за сеанс, так как программа работает очень короткое время и выполняет узкий, обозначенный в данный момент, перечень задачь.

Все опровдание ООП сводится к удобству разработки. Однако это удобство под большим вопросом, так как правильно сказал Mizka - забить гвоздь можно конечно и кувалдой. Может даже и быстрее. Но она совсем для того не предназначена.

Вот ты Кузнецова с Симдяновым прировнял к Попову. А они достаточно известные и признанные личности, авторы множества книг по программированию, лауреаты и имеют степени. И на самом деле очень неплохие книги пишут.
Но вот с ООП - не заладилось. И дело тут не в них вовсе. Дело именно в неприспособленности PHP к решению ООП проблем. Кторые собственно создают сами себе поборники такого подхода.

Спустя 2 часа, 58 минут, 58 секунд (27.08.2010 - 08:51) linker написал(а):
Это не имеет широкого применения только потому, что это моя личная разработка и применяю я ее только в своих проектах. Если широта применения в смысле круг задач, то он безграничен в пределах того, на что способен PHP. Но не рационально распыляться, поэтому основная ниша - разработка Web-приложений.
Цитата
А исправлять их куда сложнее, чем ошибки процедурного кода.
Пример, всем известные глобалсы или статик переменные могут превратить отладку или рефакторинг процедурного кода в чистый кошмар.
Цитата
Да и собственно сами классы в PHP, если приложение реализовано на ООП, обычно используются единожды, служат в основном какой то упаковкой, для сомнительной красоты в основном и пространств имен
Видимо постом выше я зря распинался и показывал как легко перенести классы из одно проекта в другой. Напиши функцию GetNews() - такая же разовая функция как и класс TNews, хотя в моем примере данный класс я могу без изменений переносить из одного проекта в другой, ибо все новости одинаковые, различаются только названия полей в таблице где хранятся новости и их количество, но мне по-фигу, я поменяю только шаблон отображения новостей. А вот тебе придется либо править свою функцию, либо переписывать с нуля.
Цитата
ООП - это программирование объектами. Которые в вебе по определению не могут использоваться многократно за сеанс, так как программа работает очень короткое время и выполняет узкий, обозначенный в данный момент, перечень задачь.
Кто и когда дал такое определение? Задачи бывают разные, не все сводится банальному Hello world.
Цитата
Все опровдание ООП сводится к удобству разработки. Однако это удобство под большим вопросом, так как правильно сказал Mizka - забить гвоздь можно конечно и кувалдой.
Не только удобство разработки, но и как я показал на примере, легкость повторного использования. Hello world забивать кувалдой глупо.
Цитата
Вот ты Кузнецова с Симдяновым прировнял к Попову. А они достаточно известные и признанные личности, авторы множества книг по программированию, лауреаты и имеют степени.
Я рад за них и книги не плохие, только прежде чем писать про ООП, может стоило для начала его не только узнать, но и понять.
Цитата
Дело именно в неприспособленности PHP к решению ООП проблем.
Если сравнивать с ООП-моделью C++, то да, но дело на месте не стоит и PHP развивается, как бы вам это не нравилось.

Спустя 52 минуты, 50 секунд (27.08.2010 - 09:44) Dingo написал(а):
Цитата
Пример, всем известные глобалсы или статик переменные могут превратить отладку или рефакторинг процедурного кода в чистый кошмар.

Глобальные переменные в PHP это шутка авторов, у меня не было ни одного случая когда мне надо было использовать глобальную переменную, обходился константами. Статик же нужны - но очень редко.
Цитата
Не только удобство разработки, но и как я показал на примере, легкость повторного использования. Hello world забивать кувалдой глупо.

Иногда конечно хорошо описать код в классе.
Но по принципам ООП нужно спроектировать ООП модель, и тут начинается, строк получается больше чем просто без класса.
Цитата (linker @ 27.08.2010 - 05:51)
Если сравнивать с ООП-моделью C++, то да, но дело на месте не стоит и PHP развивается, как бы вам это не нравилось.

Вот оно и вот, PHP развивается, потому что кроме PHP ему некуда развиваться, бугагаг laugh.gif Имхо!

Спустя 31 минута, 32 секунды (27.08.2010 - 10:15) linker написал(а):
Цитата
обходился константами

А ресурсы или массивы тоже в константах хранишь?
Цитата
Но по принципам ООП нужно спроектировать ООП модель, и тут начинается, строк получается больше чем просто без класса.

В моем примере очень хорошо видно, что добавление новостей заняло одну строчку class TNews extends TObject {}
Цитата
Вот оно и вот, PHP развивается, потому что кроме PHP ему некуда развиваться
С++ тоже некуда развиваться кроме как С++

Спустя 15 минут, 20 секунд (27.08.2010 - 10:30) Mizka написал(а):
Цитата
А ресурсы или массивы тоже в константах хранишь?

ну а что тут такого... можно вместо define использовать const

const MYCONSTANT = array(1,2,3);

Ладно, уберем тогда это часть smile.gif

Спустя 4 минуты, 49 секунд (27.08.2010 - 10:35) linker написал(а):
Mizka
Ну ты крут, не все что почерпнуто из Java работает в PHP. Да и большинство массивов генерятся автоматически, поэтому в любом случае лажа получается.

Спустя 23 минуты, 13 секунд (27.08.2010 - 10:59) Guest написал(а):
Насчет того, что на php не бывает крупных сложных проектов, где участвует несколько разработчиков и не только php-истов, а и других - не согласен.

Спустя 13 минут, 36 секунд (27.08.2010 - 11:12) twin написал(а):
Цитата
Это не имеет широкого применения только потому, что это моя личная разработка и применяю я ее только в своих проектах.
Вот именно! Именно про это я и пишу. У каждого своя личная разработка, фактически свой язык программирования. И разобраться в нем несравнимо сложнее. чем отловить globals. Если с ним обращаются аккуратно, то он только на пользу.

А вот я никак не могу
Цитата
легко перенести классы из одно проекта в другой.
Потому что один проект пишешь ты, другой - Симдянов. И ни под каким соусом они не стыкуются.

И при рефакторинге проекта приходится полностью разбирать логику разработчика. А она бывает такой мудреной, что ни одна дока не помогает. Куда там глобальным переменным, если все опутано полиморфизмом, абстракциями и и наследованиями.
К тому же доки обычно не пишут. Это же замедляет разработку! Надо быстрее!

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

Удобство ООП сводится только к сиюминутной выгоде разработчика. И то под большим вопросом. Все остальное сводится на нет, что я и описал в первом посте.

Цитата
Если сравнивать с ООП-моделью C++, то да, но дело на месте не стоит и PHP развивается, как бы вам это не нравилось.
В том и беда, что развивается не в ту сторону. Вернее это вина не PHP, а тех, кто решил, что ООП в нем удобно. И развивают каждый на свой манер. А в итоге получается разброд и анархия.

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

Спустя 39 минут, 37 секунд (27.08.2010 - 11:52) linker написал(а):
Цитата
У каждого своя личная разработка, фактически свой язык программирования.
Вот уж не путай понятия. Разобраться что делает тот или иной метод класса не сложнее чем разобраться с функцией, ибо по сути одно и тоже.
Цитата
И разобраться в нем несравнимо сложнее. чем отловить globals. Если с ним обращаются аккуратно, то он только на пользу.
Т.е. надо знать что ты делаешь, так и с ООП - надо знать что ты делаешь и понимать.
Цитата
Потому что один проект пишешь ты, другой - Симдянов. И ни под каким соусом они не стыкуются.
А что, с процедурками как-то иначе? Очень сложно соединить бегемота со страусом, ты не находишь? И это не проблема ООП или процедур.
Цитата
И при рефакторинге проекта приходится полностью разбирать логику разработчика. А она бывает такой мудреной, что ни одна дока не помогает. Куда там глобальным переменным, если все опутано полиморфизмом, абстракциями и и наследованиями.
Я вот постоянно работаю с DOM XML и у меня ни разу не возникало желания узнать логику разрабов. Так же как не возникало узнать логику работы mysql_query(). Не будем далеко ходить DOM XML прям весь опутан полиморфизмом, абстракциями и и наследованиями?
Цитата
К тому же доки обычно не пишут. Это же замедляет разработку! Надо быстрее!
Я не знаю как другие, но у меня все описано тэгами phpDocumentor. Причем в трех уровнят: сначала описание файла в самом начале, потом описание класса, потом над каждым методом.
Цитата
Удобство ООП сводится только к сиюминутной выгоде разработчика. И то под большим вопросом. Все остальное сводится на нет, что я и описал в первом посте.
Я уже приводил примеры ошибочности твоего мнения и не раз, см.выше, причем никаких возражений не получил.
Цитата
В том и беда, что развивается не в ту сторону.
А в какую сторону ему развиваться по твоему мнению? Кроме увеличения числа нативных функций развиваться некуда, ну еще конечно оптимизить и исправлять баги. Но это не развитие - это застой, потому и перла сдохла, так же сдохнет и PHP ибо его место займут питоны, руби и прочие продвинутые инструменты.
Цитата
А по сути, если заниматься этим широко и глубоко, оторвавшись от своего любимого проекта и взглянув глобально, то обязательно приходит осознание, что все это чушь. Не я первый, не я последний.
Быть кустарем, может и приятно, но исключительно для себя любимого. А жить надо, а за бесплатно жить ну никак не получается.

Спустя 27 минут, 5 секунд (27.08.2010 - 12:19) Mizka написал(а):
Цитата
Mizka
Ну ты крут, не все что почерпнуто из Java работает в PHP. Да и большинство массивов генерятся автоматически, поэтому в любом случае лажа получается.

принцип работы статических переменных и методов везде один.
Цитата

А ресурсы или массивы тоже в константах хранишь?

я лишь указал на то что хранить массивы в константах можно. и в этом нет ничего страшного..


Спустя 10 минут, 48 секунд (27.08.2010 - 12:30) Mizka написал(а):
если честно спор у вас бессмысленный... ОО программирование имеет больше возможностей чем функциональное. в функциональном + в его простоте... а что лучше - тут уже зависит от способа мышления программиста - кто что использовал то и будет хвалить...

Спустя 12 минут, 23 секунды (27.08.2010 - 12:42) twin написал(а):
Цитата
Разобраться что делает тот или иной метод класса не сложнее чем разобраться с функцией, ибо по сути одно и тоже.

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

Цитата
А что, с процедурками как-то иначе? Очень сложно соединить бегемота со страусом, ты не находишь?
Совершенно иначе. Ибо процедурщики оперируют в основном штатными процедурами, а вы всякими
$obj -> display();
echo, оно и в Африке echo, а вот у вас с Смдяновым синтаксис совершенно разный.
Кроме того, я свободно могу взять функцию и вставить в другой скрипт. Ибо она не связана ни с чем. Ни с базовым классом, ни с интерфейсами и вообще свободная вещь.
Цитата
Я вот постоянно работаю с DOM XML и у меня ни разу не возникало желания узнать логику разрабов.
У меня тоже. Ибо это стандарт. А вот логику Васи Пупкина, насочинявшего три тонны кода вместо двух строк процедурки приходится чуть ни каждый день. Ибо не доверяю я Васи Пупкину. Ну не доверяю, хоть убей.
Цитата
Я не знаю как другие, но у меня все описано тэгами phpDocumentor.
Я рад за тебя. Но:
1. Не все такие законопослушные
2. В твоих доках тоже надо разбираться сидеть. А значит ты сэкономил на мне. Тебе при разработке легко, а мне при рефакторинге тяжко.
Цитата
Я уже приводил примеры ошибочности твоего мнения и не раз, см.выше, причем никаких возражений не получил.
Да проснись))) Я 13 страниц этим исписал уже. Не веришь мне - в сети полно статей, где показывается несостоятельность утверждения, что есть экономия.
Цитата

Быть кустарем, может и приятно, но исключительно для себя любимого. А жить надо, а за бесплатно жить ну никак не получается.
Это к чиму было сказано? Мож пиписьками померяемся? Доходами я имею ввиду? Сомневаюсь, что ты победишь. smile.gif
Но я точно скажу - в моей работе ООП только мешает.
Цитата
А в какую сторону ему развиваться по твоему мнению?
Не знаю я . Но точно одно - не в сторону питонов. Ибо у питона своя ниша, у PHP - своя. И он скорее сдохнет, пытаясь догнать, чем развиваясь естественно, без этих безобразных потугов.

Спустя 47 минут, 38 секунд (27.08.2010 - 13:30) Dingo написал(а):
Вот я сегодня пытался начать делать сайт на ZendFramework-1.10.8, и сразу бросил это дело, ну это вообще полнейший бред, во первых у меня не получилось сделать то что прописано в мане и где ваш фундамент, который пойдет на любой проект, ошибки в самом начале, даже просто обычным копи пастом из манула. Потом я заглянул в какой то файл и выпал, там комментариев к коду больше чем самого кода.
. Да и притом я вообще офигел, мне что придется учить все эти новые абстракции и как они внутри устроены? избавьте я мазохизмом не занимаюсь.
да на ... я вертел это ООП и фрамеворки на ООП, мне обычного программирования хватит, зачем из PHP делать другой язык, а потом говорить мол ООП сила, главное прочитать про паттерны 520 страниц + в оригинале паттерны ООП программирования это 2000 страниц, потом мне нужно годика 2 тренироваться, и потом я пойму все мощь ООП, зенда и прочего хлама. А стоит ли оно, когда я стандартными средствами и теми же самыми классами сделаю тоже самое, и притом не буду захламлять мозг всякой ненужной мне чушью. Имхо.

Спустя 1 минута, 7 секунд (27.08.2010 - 13:31) waldicom написал(а):
Цитата (Dingo @ 27.08.2010 - 12:30)
А стоит ли оно

Нет, не стоит.... ни разу... точно говорю... ась?

Спустя 17 минут, 50 секунд (27.08.2010 - 13:49) linker написал(а):
Цитата
лишь указал на то что хранить массивы в константах можно. и в этом нет ничего страшного..
В Java наверное возможно, а в PHP получишь фатальный еррор "Arrays are not allowed as constants". Но речь, сам понимаешь, о PHP.

Цитата
Да что вы))) Расскажи это тем, кто не освоил примудрости ООП так как ты. Или сейчас опять начнешь про кривизну рук и высокие материи в области кулинарии? Это называется прозрачность кода.
Если ты нуб, то никакая прозрачность кода тебе не поможет. Все требует определенного уровня знаний и опыта - это неоспоримый факт. Кухарка не сможет управлять государством.
Цитата
Их единицы, а сайтов миллионы.
60%-70% из которых деланы нубами, которые даже на процедурках не могут реализовать банальные вещи.
Цитата
А по сему нафиг это не надо никому на самом деле.
Ну и нефиг тогда программированием заниматься, это не игрушки. А этим высказыванием, ты явно высказываешь мысль, что занимаясь программированием думать не надо и вообще вредно. Ибо можно обойтись и без этого, а спокойно цветочки дома себе выращивать на продажу. В доках всегда и везде нужно разбираться, давно ли ты с упоением курил PHP-мануал? И до сих пор покуриваешь иногда.
Цитата
Ибо процедурщики оперируют в основном штатными процедурами
Видимо у нас разные понятия процедурного программирования. Для меня это
function a($b)
{
echo $b . "\n";
if ($b > 0)
return $b * 2 - 10;
else
return
-100000;
}
echo a(102);
echo a(-239);
echo, return не нуждаются в представлении, а вот функция a() требует осмысления и чтения мануала если есть таковой (не воспринимай буквально, это всего лишь пример). И чем осмысление этого примера отличается от осмысления
class myclass
{
public function a($b)
{
echo $b . "\n";
if ($b > 0)
return $b * 2 - 10;
else
return
-100000;
}
}

$a = new mycalss()
echo $a->a(102);
echo $a->a(-239);
Я мог бы развить сей пример дальше, например, когда нужно запоминать последний результат выполнения метода, а в самом методе это значение используется при следующих вычислениях и прочее. Ничего сложного в этом я не вижу.
Цитата
Кроме того, я свободно могу взять функцию и вставить в другой скрипт. Ибо она не связана ни с чем. Ни с базовым классом, ни с интерфейсами и вообще свободная вещь.
Ну вот попробуй свою свободную и независимую функцию вывода списка новостей вставить в другой скрипт для вывода комментариев. А другую, такую же свободную и независимую функцию, которая работает с файлами, вставить в скрипт, который работает с сокетами. Как получится, тогда и поговорим, что есть свобода, независимость и в каких приделах она распространяется.
Цитата
вот логику Васи Пупкина, насочинявшего три тонны кода вместо двух строк процедурки приходится чуть ни каждый день.
Причем эти две строки процедурки тянут за собой еще кучу других процедурок, которые в свою очередь тоже на чем-то подвязаны. Так или иначе, процедурное программирование существует ради сокращения повторяющего кода и ты, как знаток и любитель просто обязан знать это. А потому треп о твоей свободной и независимой ни от чего функции, извини, попахивает дилетантством (честно не хочу обидеть).
Цитата
Это к чиму было сказано? Мож пиписьками померяемся? Доходами я имею ввиду?
Это сказано к тому, что хорошо жить на энтузиазме невозможно. Свободные художники, в своем большинстве, получают признание только после смерти. А перехриначивать чужие сорцы - только нервы себе портить.
Цитата
Не знаю я . Но точно одно - не в сторону питонов. Ибо у питона своя ниша, у PHP - своя
Если не знаешь, то лучше ничего не утверждать. И какая же ниша у питона?

Спустя 3 минуты, 5 секунд (27.08.2010 - 13:52) linker написал(а):
Млин, что фигня с bb-кодами? Пропадают куда-то.

Спустя 2 минуты, 19 секунд (27.08.2010 - 13:54) linker написал(а):
Dingo
Ну займись выращиванием ромашек на балконе, там вообще ни думать не надо, ни мозг захламлять всякими премудростями.

Спустя 4 минуты, 4 секунды (27.08.2010 - 13:58) Dingo написал(а):
Цитата (linker @ 27.08.2010 - 10:54)
Ну займись выращиванием ромашек на балконе, там вообще ни думать не надо, ни мозг захламлять всякими премудростями.

не.... неинтересно

Спустя 1 час, 6 минут, 1 секунда (27.08.2010 - 15:04) Mizka написал(а):
Цитата
В Java наверное возможно, а в PHP получишь фатальный еррор "Arrays are not allowed as constants". Но речь, сам понимаешь, о PHP.

Да в джаве можно... а вот в пхп блин действительно низя О.о Хотя если по извращаться... smile.gif

Спустя 1 час, 17 минут, 39 секунд (27.08.2010 - 16:22) Guest написал(а):
linker
как всегда на высоте.

не знаю только как у тебя терпения хватает всё доказывать на примерах smile.gif но глаголишь однозначно!

Спустя 2 часа, 17 минут, 26 секунд (27.08.2010 - 18:39) twin написал(а):
Цитата
linker
как всегда на высоте.

секундочку... Если бы он был не на высоте, я бы даже разговаривать не стал бы.
Спор интересен только тогда, когда споришь как минимум на равных, а как максимум с человеком, знающим больше чем ты.
Мне доставляет несказанное удовольствие обмениваться аргументами с человеком, отлично знающим свою область.
Поверь, с тобой я не перекинулся бы более чем парой строк. По крайней мере до того момента, пока ты не высунешься из куста.
Представься, не ссы.
Дальше не читай, тут люди разговаривают, а не анонимные непонятно кто.
linker
Цитата
Если ты нуб, то никакая прозрачность кода тебе не поможет.

Почитай подпись под моим аватаром.
Да, я нуб. И ни сколько не крмплексую по этому поводу.
Ибо нет смешнее зрелища, чем серьёзная рожа на фотографии. Если человек скажет, что он гуру - не задумываясь можно слать его лесом. Он лох.
Нельзя за тот промежуток времени, который отдан нам на жизнь, постичь все премудрости даже одного языка программирования.
Цитата
60%-70% из которых деланы нубами, которые даже на процедурках не могут реализовать банальные вещи.
Этот процент занижен. На самом деле гораздо больше.
На то он и PHP, чтобы дать возможность программировать таким нубам, как я.
Если ты чувствуешь в себе силы на большее - дык и шуруй в рельсы, питон и так далее. Какого хрена вы, крутые прогеры, освоившие всё и вся, лезете со своими идиотскими правилами туда, где вас совсем не ждут?

Ну умеешь ты сделать на ровном месте кочку - молодца. Все завидуют наверно.
Но представлять ООП как прогресс PHP...

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

Хватит словесного поноса, давай поставим точки над i.

Это будет всем полезно. Не исключаю, что и мне.

Спустя 57 минут, 8 секунд (27.08.2010 - 19:36) Dingo написал(а):
Цитата (twin @ 27.08.2010 - 15:39)
Я, в здравой памяти и здравом рассудке вызываю тебя на дуэль.

biggrin.gif Щас точно перчатки полетели

Спустя 1 час, 33 минуты, 10 секунд (27.08.2010 - 21:09) waldicom написал(а):
Цитата (twin @ 27.08.2010 - 17:39)
Определяем функционал, реализуем каждый по своему и сравниваем по любым, за ранее определенным параметрам.

Есть мнение, что раз вы не можете сойтись во мнениях, то оценка написаных приложений ничего не даст. Потому что один скажет: "да ты чееее, ты оценил ООП хорошо, но это же отстой". Другой:"ты оценил процедурки хорошо, ты че, тормоз"?

Это короче капэц

Спустя 5 минут, 59 секунд (27.08.2010 - 21:15) Mizka написал(а):
ну так оценивать может и общественность:) интересно посмотреть на это smile.gif

Спустя 2 минуты, 9 секунд (27.08.2010 - 21:18) twin написал(а):
Цитата
Это короче капэц

Да ну...
Я готов признать свою несостоятельность, если оценка будет объективной.
Для того и предлагаю заранее определить условия.

Предложим все, что накипело и алга.
В судьи кстати - все желающие. Тут уровень не важен.
Конкурсы уже скучно, тем более Вася пропал. Ну давайте хоть так повеселимся.
Я готов принародно сьесть шляпу. smile.gif

Спустя 46 минут, 16 секунд (27.08.2010 - 22:04) waldicom написал(а):
Цитата (twin @ 27.08.2010 - 20:18)
Для того и предлагаю заранее определить условия.

- "Огласите весь список, пжалуста"
- Ликероводочный на сегодня нарядов не прислал

Спустя 6 минут, 28 секунд (27.08.2010 - 22:10) twin написал(а):
Дык пришли)))
Кто мешает?

Спустя 44 минуты, 6 секунд (27.08.2010 - 22:54) Mizka написал(а):
а что.. можете написать логер... задача не тривиальная, интересная и полезная.

Оценка:
-простота интеграции в проект/юзер френдли интерфейс
-функциональность
-оптимальность
-TBD

В конкурсах ещё такого кажется не было smile.gif

Спустя 1 минута, 17 секунд (27.08.2010 - 22:56) Dingo написал(а):
Чур я в судействе, гы tongue.gif

Спустя 24 минуты, 50 секунд (27.08.2010 - 23:21) Basili4 написал(а):
Я тоже в судейство....

Спустя 2 дня, 9 часов, 27 минут, 52 секунды (30.08.2010 - 08:48) linker написал(а):
Цитата
Почитай подпись под моим аватаром.
smile.gif Весьма самокритично, она меня часто сбивает с толку smile.gif я сам не редко пишу говнокод, а потом как дурак сижу и рефачу
Цитата
Этот процент занижен. На самом деле гораздо больше.
Просто я оптимист по натуре smile.gif
Цитата
На то он и PHP, чтобы дать возможность программировать таким нубам, как я.
Это слишком сложно и долго объяснять.
Цитата
Если ты чувствуешь в себе силы на большее - дык и шуруй в рельсы, питон и так далее. Какого хрена вы, крутые прогеры, освоившие всё и вся, лезете со своими идиотскими правилами туда, где вас совсем не ждут?
Я очень трепетно отношусь к PHP, он мне как родной и так обижать его: не серьезный, для нубов, аля бейски и пр., не позволю smile.gif. И зря ты так, ты далеко не нуб, даже не эксперт, а гораздо выше. Поэтому не обижай ПХП.
Цитата
Но представлять ООП как прогресс PHP...
ООП - это общий прогресс. Какой будет следующая ступень, предположить сложно.
Цитата
Я, в здравой памяти и здравом рассудке вызываю тебя на дуэль.
Определяем функционал, реализуем каждый по своему и сравниваем по любым, за ранее определенным параметрам.
Ото оно как smile.gif Выбирайте оружие, сэр.
Цитата
Да ну...
Я готов признать свою несостоятельность, если оценка будет объективной.
Я хоть и принимаю вызов, но мне результат безразличен, ибо я в данном деле полигамный прогер. Давайте задачу, вдруг я ее на процедурах эффективнее реализую smile.gif Шутка, ООП так ООП.

Спустя 4 часа, 43 минуты, 58 секунд (30.08.2010 - 13:32) twin написал(а):
Цитата
Это слишком сложно и долго объяснять.

А я всетаки попробую.

Когда я слышу всякие всхлипывания от таких, как тот мальчик, которого забанили - мол я самурай, а вы все говнокодеры, всегда вспоминается басня про свинью и дуб:
Цитата
          Свинья под Дубом вековым
Наелась желудей досыта, до отвала;
          Наевшись, выспалась под ним;
          Потом, глаза продравши, встала
И рылом подрывать у Дуба корни стала.
          "Ведь это дереву вредит",
          Ей с Дубу ворон говорит:
"Коль корни обнажишь, оно засохнуть может".-
          "Пусть сохнет", говорит Свинья:
          "Ничуть меня то не тревожит;
          В нем проку мало вижу я;
Хоть век его не будь, ничуть не пожалею,
Лишь были б желуди: ведь я от них жирею".-
"Неблагодарная!" примолвил Дуб ей тут:
          "Когда бы вверх могла поднять ты рыло,
               Тебе бы видно было,
          Что эти желуди на мне растут".
                               ______

          Невежда также в ослепленье
          Бранит науки и ученье,
          И все ученые труды,
Не чувствуя, что он вкушает их плоды.


Дело все в том, что они очень быстро забывают, что совсем недавно тот же "Привет, Мир!" вызывал у них приступ дикой паники. И если бы не демократичность PHP, то вряд ли бы он сейчас тут расширялся. Потому что не смог бы осилить более сложный язык.

Вот говорят - прошли те времена, когда PHP служил для создания хомпагов. Мол сейчас это мощнейшее средство ВЕБ разработки. И развивается по всем канонам серьёзных языков программирования.

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

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

Это не прогресс. Это регресс. Он постепенно уходит из своей ниши, причем туда, где и без него тесно. И конкурировать он вряд ли сможет. Даже с той же самой перловкой.

Если бы не проблема обратной совместимости, наверное под лобби ZENDA он давным давно бы стал полностью объектным, как та же JAVA к примеру. Ибо им как раз и свойственны такие мысли - сделать PHP полноценным профессиональным языком.

Их я понять могу - коньюнктура. А вот тех, кто ведется на это - не понимаю.

Понятно - сам прошел от азов до высшего пилотажа - можно и забыть с чего начинал. Хоть трава не расти. Главное я теперь самурай.

Так что
Цитата
Я очень трепетно отношусь к PHP, он мне как родной и так обижать его: не серьезный, для нубов, аля бейски и пр., не позволю
никого я не обижаю. Я просто констатирую факт. PHP самый пригодный язык для начала изучения ВЕБ-программирования. Тем он и хорош. А его пытаются выродить в очередного монстра. Это регресс.

На чем прикажешь начинать учиться новичкам, если PHP встанет в один ряд с питоном, рельсами или JAVA? На перловке? 90% (а то и больше) народу просто не осилит азов.
Цитата
ООП - это общий прогресс. Какой будет следующая ступень, предположить сложно.

Ничего не сложно. Погибнет он и вся недолга. Ибо до полноценного объектного языка ему далеко, а от народа он уходит. Нельзя объять необъятное.

Я рад, что на мой век еще хватит, так как обратная совместимость все же тормозит этот "прогроесс". И не дает свалиться языку в пропасть ООП.
Цитата
Выбирайте оружие, сэр.

Перчатку бросил я, выбор за Вами. smile.gif

Спустя 1 час, 13 минут, 47 секунд (30.08.2010 - 14:46) linker написал(а):
Цитата
Так то оно так, только на чем прикажете эти самые хомпаги делать? Ведь PHP чем хорош - это практически самоучитель программирования.
Он многое прощает, он позволяет решать одну задачу кучей способов, мануал по нему не в пример проще, чем по другим языкам. Именно из-за его структуры. Императивной.
А что же преподносится как прогресс? Вырождение этих качеств и появление других, присущих более сложным (пусть даже более стройным) языкам.
Ты сам себе противоречишь, появление более сложные технологий нисколько не ущемляет возможностей делать так, как тебе нравится ибо сам сказал: "позволяет решать одну задачу кучей способов". Тебя никто не заставляет программить исключительно с помощью ООП. Делай это так, как ты делал ранее.
Цитата
Это не прогресс. Это регресс. Он постепенно уходит из своей ниши, причем туда, где без него тесно. И конкурировать он вряд ли сможет. Даже с той же самой перловкой.
Во-первых, перловка давно слилась, как инструмент веб-разработок. Во-вторых, та ниша, которую занимает PHP в процентном соотношении с другими языками, то PHP явно выигрывает. Если ты хочешь, чтобы ее до конца заняли ASP.NET, Java, Python, Ruby, то можно и дальше орать про регресс и ляпать хоумпаги.
Цитата
он давным давно бы стал полностью объектным
Если сделают его более быстрым, то я не против. Имхо, пора уже разделять его на две ветки, одну (текущую) оставить для хоумпагеров, а вторую начать делать для профессионалов. Тогда все проблемы холиваров сразу решатся.
Цитата
Понятно - сам прошел от азов до высшего пилотажа - можно и забыть с чего начинал. Хоть трава не расти. Главное я теперь самурай.
Ну я начинал с GWBasic и что теперь, может мне к нему вернуться, а фигли забывать-то?
Цитата
никого я не обижаю. Я просто констатирую факт. PHP самый пригодный язык для начала изучения ВЕБ-программирования. Тем он и хорош. А его пытаются выродить в очередного монстра. Это регресс.
Одно другому не мешает. Просто у новичка количество этапов, которые нужно пройти, увеличивается. Глупо переходить к процедурам, если не имеешь понятия о переменных, конструкциях и т.п. Вообще, перед тем как начинать что-то изучать необходимо иметь некоторую теорию, на которой строится любой язык - алгоритмы и логика. Если ты знаешь и понимаешь базу, то нет никакой разницы какой учить язык, ибо язык это всего лишь набор конструкций и синтаксис, если по простому.
Цитата
Перчатку бросил я, выбор за Вами.
Мое оружие ООП smile.gif

P.S. Если программирование - это твоя профессия, то сопли тут не уместны.

Спустя 1 час, 51 минута, 38 секунд (30.08.2010 - 16:38) twin написал(а):
Цитата
Ты сам себе противоречишь, появление более сложные технологий нисколько не ущемляет возможностей делать так, как тебе нравится ибо сам сказал: "позволяет решать одну задачу кучей способов"

Ни в коем случае. Разные способы - я имел ввиду императивный подход.
Когда даны инструменты (Функции) и ты сам волен выбирать, чем пользоваться.
А в объектном языке вариант один.
Так вот в последнее время как раз в эту сторону все и поворачивается.
PDO, фреймворки, смарти уже поговаривают в стандарт PHP внести...

То есть если дальше все будет развиваться по намеченному пути, то скоро в учебниках не будет уже
echo 'Hello, World!';

А будет
    $page->assign('var', 'Hello, World!');

что конечно у тебя не вызывает никаких особых эмоций, а вот многих начинающих вгоняет в ступор.

А ведь к этому и идет все, процедурный подход не айс, фреймворки рулез. Со своим синтаксисом и законами.

Сейчас этих фреймворков тьма. А когда их много, значит нет ничего страшного. А как только какой то из них попадет в стандарт - все. Язык начнет тут же терять популярность. И его нишу может занять другой. Что и случилось с перлом. Ведь перл по сути своей намного стройнее PHP. Ан нет - побили его. Именно демократичностью.

Собственно мы от темы отклонились. Разговор шел не о уровне вхождения. А о разработке и дальнейшем обслуживании проектов на PHP.

Так вот. Тут в чем подвох. Пока нет стандарта на ООП варианты - наблюдается разброд и шатания. Что крайне затрудняет поддержку. А как только появится стандарт - исчезнет простота разработки. И тогда PHP станет языком избранных. Как рельсы допустим сейчас.

И тот и другой вариант - пагубны для языка. Потому я и говорю - регресс.

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

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

Цитата
Мое оружие ООП

Ясен перец smile.gif Теперь нужно выбрать место и условия.
Какой функционал и по каким критериям сравнивать.

Спустя 1 час, 36 минут, 22 секунды (30.08.2010 - 18:14) DedMorozzz написал(а):
предлагаемые критерии:
-Написать скрипт, в который функционал(разумный и "вполне реальный") добавится.
-Легкость переноса(в принципе к чёрту этот пункт, но на скорость скажется)
-Скорость работы(очень удивительный пункт). Проверяется на парочке компов, с одним и тем же ПО.
-?? Простота понимания (тут не могу предложить единого механизма)
-Объём кода (считаем количество значимых символов на калькуляторе).

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

Для чего отдельный человек? Да всё просто. Как раз один из критериев - возможность расширения. Что именно потребуется никто не будет знать (на честном слове). Иначе сразу код будет писаться под это "доп" условие.
Придумать задание - уверен у него выйдет.
Ну а мы запасёмся попкорном и орандж содой.

Спустя 1 час, 2 минуты, 58 секунд (30.08.2010 - 19:17) twin написал(а):
Проблема только в одном. Вася сильно занят, ему не до этих баталий.
А так вполне разумно. По критериям сравнения подработать чуток.

Спустя 10 минут, 28 секунд (30.08.2010 - 19:28) waldicom написал(а):
Пока гуру форума, ООП и процедурного программирования напрягаю серые клетки мозгов, у мну возникла малюсенькая задача на три миинуты для настоящих гуру процедурного программирования.

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

Спустя 17 минут, 6 секунд (30.08.2010 - 19:45) twin написал(а):
Понял ничего. sad.gif

Как то повнятнее можно?

Спустя 8 минут, 8 секунд (30.08.2010 - 19:53) waldicom написал(а):
Повнятнее... Твин, ты вынуждаешь меня написать фразу: внимание,
печатаю м е д л е н н о и с выражением!!!

Есть метеостанция, которая подготавливает метеорологические данные (см выше). Эти данные передаются на другую станцию, на стене которой висят три прибора: термометр, гигрометр и барометр.

Задача спроектировать и написать такую систему.

Спустя 8 минут, 51 секунда (30.08.2010 - 20:02) twin написал(а):
А причем тут PHP?

Спустя 12 минут, 50 секунд (30.08.2010 - 20:15) waldicom написал(а):
PHP - один из многих языков программирования, позволяющий решать насущные задачи.
Задача выше - одна из насущных задач сего бренного мира.
Соединяем. Пишем. Ты на процедурках, кто-то другой на ООП. Сверяем. Проверяем. Думаем. Выводы. Аплодисменты. Занавес.

Спустя 21 минута, 50 секунд (30.08.2010 - 20:36) twin написал(а):
Просто это задача не совсем для него. Вернее совсем не для него.
Написать конечно можно, только зачем микроскопом гвозди то забивать...
Хотя разницы нет по большому счету.

Правда задание совершенно не понятно даже медленно и с выражением.
Я далек от метеорологии. Можно как то поподробнее.

Это сеть станций или как? Почему приборов много, а инструмента три? Они что, среднее значение должны показывать или какие то другие нужны расчеты? Каким образом подключать эти приборы, у каждой группы свой сервер (кольуж это PHP) или как это все видится? Просто сокетами делать может?
В общем ТЗ никакое.

Если брать это задание за основу, нужно все конкретизировать. Или мы сделаем совершенно разные вещи и не сможем даже близко сравнить.

Спустя 1 час, 6 минут, 34 секунды (30.08.2010 - 21:43) linker написал(а):
Эко вы шустрые. waldicom, прочитав твой первый пост я вроде как понял, что есть хрень, которая затребует данные от n-ого количества инструментов и что-то меряет. Прочитав "уточнение" я запутался. Какой поток данных, что куда движется?

А так, насколько понял задачу по первому посту:

1. Получение данных от X-инструментов через некий абстрактный интерфейс (к которому можно подключать/отключать инструменты).
2. Обработка и подготовка данных
3. Отправка на прибор меряющий температуру на следующий день.

Спустя 20 минут, 25 секунд (30.08.2010 - 22:03) sergeiss написал(а):
Цитата (waldicom @ 30.08.2010 - 20:28)
Пока гуру форума, ООП и процедурного программирования напрягаю серые клетки мозгов, у мну возникла малюсенькая задача на три миинуты для настоящих гуру процедурного программирования.

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

Интересная задача!!! Но имеющая к ПХП очень мало отношения smile.gif

Поясняю. Съем данных (в частности, чтение портов, где эти данные поступают на ком) надо делать не средствами ПХП, а средствами другого языка. Например, на Си. Потому что его средствами мы получим (можем получить) вполне достойную программу, которая будет постоянно "висеть" в памяти, мониторить порты, писать данные куда-то в БД.
А на ПХП мы сделаем программу ПРОСМОТРА. Скорее всего, с привлечением аякса. Будет этот скрипт обращаться к данным, уже записанным в БД. И показывать их пользователю. То есть, мы получим "классическую" задачу показа юзеру данных из БД. И тут ООП в ПХП вряд ли нужно будет, только если ООП в JS smile.gif
Почему аякс? Да потому что данные систематически добавляются и их у юзера надо обновлять, и делать это лучше автоматически и красиво.

Вопрос: почему бы не сделать ту самую прогу, которая читает данные, на ПХП? Да можно, наверное... Только зачем делать скрипт, который будет "хронически" работать, 24 часа в сутки? Все равно мы его не покажем юзеру, а сделаем для него тот самый скрипт на ПХП (с аяксом и ООП в JS), который я уже упоминал выше.

Короче говоря. Получаем, что данная задача изначально некорректно поставлена, в том смысле, что для ее решения предложены некорректные средства - вместо ПХП нужен другой язык, но это не тема данного форума.

Если я не прав, по чьему-то мнению, прошу чётко аргументировать!

Спустя 29 минут, 46 секунд (30.08.2010 - 22:33) linker написал(а):
sergeiss
Построить алгоритм работы можно не прибегая к какому-либо из языков. Собственно в данном задании, имхо, требуется эмулировать работу тех или иных девайсов. Вот только ТЗ совсем непонятное.

Спустя 8 минут, 8 секунд (30.08.2010 - 22:41) waldicom написал(а):
ок, проехали.

пысы. какая эмуляция, какие порты, какой ваще аякс? Это типичнейшая задача на Observer-Pattern. И я хотел посмотреть, как её реализуют процедурным программированием.

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

Спустя 4 минуты, 44 секунды (30.08.2010 - 22:46) sergeiss написал(а):
Цитата (waldicom @ 30.08.2010 - 23:41)
какая эмуляция, какие порты, какой ваще аякс

Ну, такие... Я не спорю, что ООП для описанной тобой задачи нужнО... Но я хотел обратить внимание на то, что ПХП для этой задачи не нужно. Twin же не говорит, что ООП вообще не нужно smile.gif Он говорит про ООП в ПХП (именно в ПХП!!!). Вот и надо давать задачи не абстрактные, а ПХП-шные.

Спустя 52 секунды (30.08.2010 - 22:47) waldicom написал(а):
Цитата (sergeiss @ 30.08.2010 - 21:46)
Он говорит про ООП в ПХП.

"Отсюда подробнее...". Так значит вся речь идет о ООП в php?

Спустя 6 минут, 19 секунд (30.08.2010 - 22:53) sergeiss написал(а):
Цитата (waldicom @ 30.08.2010 - 23:47)
"Отсюда подробнее...". Так значит вся речь идет о ООП в php?

"Ну вы, блин, даёте!" (с) wink.gif

Аа что писал twin в САМОМ НАЧАЛЕ ТЕМЫ, с чего он её создал? Даю цитату:
Цитата (twin @ 1.04.2010 - 09:46)
Теперь по пунктам.
Скорость разработки.
Да, можно было бы с этим согласиться. Но только в том случае, если пишется чистая парадигма. Как в Си. То есть когда можно взять любой класс из написанной программы и вставить его в другую.
Но это совершенно не имеет отношения к построению архитектуры конкретного приложения в веб технологиях, так как та же самая скорость разработки требует учитывать только текущие задачи. Некогда отвлекаться на то, что может потребоваться потом. Скорее, скорее, скорее. Над душой злобный шеф и нетерпеливый заказчик.


Из этой цитаты явственно следует, что он говорит именно о "приложениях в веб-технологиях"! И речь идет про ПХП... Потому что мы, вобщем-то, именно на форуме ПХП-программеров и "развлекаемся". Обрати внимание на верх страницы, на название раздела: "Форум PHP программистов ► Разное ► Флейм".

Спустя 4 минуты, 29 секунд (30.08.2010 - 22:58) DedMorozzz написал(а):
цитата несколько не та. Была дето, в которой написано нечто "ООП нужно в таких языках как Си, без вариантов - в ява, но не в ПХП. Ибо... (тут 17 листов)"

Спустя 18 секунд (30.08.2010 - 22:58) waldicom написал(а):
Цитата (sergeiss @ 30.08.2010 - 21:53)
"Ну вы, блин, даёте!" (с) wink.gif

Ну, за рыбалку! (с)

Насчет флейм... Флейм... Флейм... Флуд знаю, бан знаю, кик знаю, флем - не брал не знаю smile.gif

Дизельные моторы это круто, но на пхп легковушках - не, на них нет.

Спустя 6 минут, 31 секунда (30.08.2010 - 23:04) sergeiss написал(а):
Цитата (DedMorozzz @ 30.08.2010 - 23:58)
цитата несколько не та.

Ты предлагаешь мне все 17 страниц изучить? laugh.gif

Цитата (waldicom @ 30.08.2010 - 23:58)
Дизельные моторы это круто, но на пхп легковушках - не, на них нет.

И вот тут тоже не соглашусь! wink.gif Довелось мне однажды месяц поездить на Рено-Клио дизельном. До 140 он ехал без проблем, с 4 человеками "на борту". И с расходом где-то чуть-чуть более 6 литров соляры на сотню smile.gif И это при том, что я достаточно резво разгонялся, ездили на нем город-трасса. По трассе - 110-130 - дело во Франции было, а у них на автострадах 110 ограничение.

Спустя 3 минуты, 36 секунд (30.08.2010 - 23:08) waldicom написал(а):
Цитата (sergeiss @ 30.08.2010 - 22:04)
И вот тут тоже не соглашусь! Довелось мне однажды месяц поездить на Рено-Клио дизельном....

Эммм... это как бы того... Типа сарказм по-поводу "ООП нужно там, но не нужно здесь"

Спустя 41 минута, 58 секунд (30.08.2010 - 23:50) sergeiss написал(а):
Цитата (waldicom @ 31.08.2010 - 00:08)
Эммм... это как бы того... Типа сарказм по-поводу "ООП нужно там, но не нужно здесь"

Хм... А вот сарказма тут не нужно smile.gif Потому что ООП - это как турбирование у того же дизеля smile.gif Которое может быть полезным для дизельного Мицубиси-Паджеро-Спорт (или для Камаза), но будет как-то уже неуместным у легкого Рено-Клио с дизельными движком.

Спустя 13 минут, 50 секунд (31.08.2010 - 00:04) Rivalryzerg написал(а):
Лучше бы попробовали реализовать некий фреймворк или скорее среду для разработки сайтов.
Список возможностей ограничить в разумных пределах, например описать типовые задачи для разработки 90% сайтов, которые мы встречаем в заказах и в своей работе.

Допустим лично меня на 100% не устраивает ни один нынешний популярный MVC фреймворк. У каждого свои плюсы и минусы. По этой причине мы с товарищем начали работу над проектом, который вберет в себя всё лучшее и удобное (на наш взгляд), что предлагают популярные фреймворки, однако будет лишен недостатков, которые им присущи.

Цель или итог: мы получим инструмент, с помощью которого мы минимизируем временные затраты на разработку типовых сайтов и задач в нашей работе.

Итог конкретно к этой теме: сразу будут видны преимущества ООП подхода или процедурного. Я то и так знаю кто победит, но многие пока даже не подозревают насколько ООП подход может быть удобен и по разным параметрам мощнее и лучше.

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

PSS: Ноу оффенс, это лишь предложение.

Спустя 8 часов, 8 минут, 29 секунд (31.08.2010 - 08:12) twin написал(а):
Цитата
"Отсюда подробнее...". Так значит вся речь идет о ООП в php?

Ну вот раз:
Цитата
Именно в PHP классическая парадигма и является злокачественной опухолью. Потому что не имеет смысла - раз, реализована криво - два.

Вот и вопрос - а стоит ли вообще заниматься популяризацией?
Пока ответ для меня очевиден. ООП в классическом понимании для PHP - зло.


два:
Цитата
Там таки да - это имеет смысл. Глупо было бы писать прикладное по процедурой, когда давно уже разработаны все нужные библиотеки.
Но тут совсем другое дело.


три:
Цитата
Да не в том дело, что ООП плох. Я этого никогда и не говорил. Я всегда говорил одно:
В веб-технологиях (особенно в PHP) ООП ничем не лучше процедурки. А зачастую гораздо хуже. Под ООП я понимаю именно Объектно Ориентированное Программирование. То есть программирование, полностью сориентированное на использование объектов и ничего другого.
Я не против классов как таковых, я против того мегабреда, который получается в результате попыток сделать крутую объектно ориентированную программу.


четыре( это не моё, Васино):
Цитата
в пыхе нет множественного наследования, но в парадигме есть. так что
Цитата (twin @ 2.04.2010 - 13:16)
а как тут на хваленой парадигме? Гибкой и удобной?

все элементарно. в пыхе, конечно, все получится не так просто.

а вот моё в ответ:
Цитата
Если ты еще не обратил до сих пор внимание, повторю. Я рассматриваю ООП парадигму применительно к PHP Остальное меня сейчас волнует мало.

Цитата
все элементарно. в пыхе, конечно, все получится не так просто.

Что и требовалось доказать. То есть все заявления, что процедурный подход все усложняет, а объектный упрощает - фикция.
А так же профонация - гибкость объектного подхода. Чем дальше я пытаюсь раскопать, тем интереснее всплывают факты.


пять:
Цитата
Не передергивай. Я не люблю ООП только в php, ибо он крив и совершенно ненужен. А в сишке очень даже.


И еще куча есть.

Так что Observer-Pattern это одно, а подобного рода ТЗ к PHP имеют отношение примерно как паровой двигатель к легковушке, а не дизельный. Или реактивный. Есть и такие разработки, но кто же серьёзно к этому относится?

Спустя 20 минут, 36 секунд (31.08.2010 - 08:33) linker написал(а):
Ну вы зря так, задача реально интересная. Пускай эмулирующая некую замкнутую систему, но все же. Если бы я не был ответчиком, то я бы ее развернул о-го-го.
Ну так будут какие-то предложения?

Спустя 41 минута, 21 секунда (31.08.2010 - 09:14) twin написал(а):
Rivalryzerg
Цитата
Цель или итог: мы получим инструмент, с помощью которого мы минимизируем временные затраты на разработку типовых сайтов и задач в нашей работе.

Итог будет плачевным. Мы получим очередного монстра, который будет глючить на каждом шагу. Даже ZEND-фреймворк не безупречен в этом плане и постоянно вносит исправления.
Минимизировать временные затраты на разработку он наверное и сможет, но только для очень узкого круга лиц. Тех, кто рискнет писать на незнакомом софте.

А вот время на последующее обслуживание увеличит на порядок. Ибо тому, кто возьмется потом рефакторить такой сайт, придется разбираться в этом фреймворке.

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

Я по религиозным соображения не пишу ни на фреймворках, ни фреймворков тем более.

linker
Цитата
Ну вы зря так, задача реально интересная.
Дык я не против. Смущают две вещи - малая практическая польза и расплывчатость ТЗ. Но если интересно, то можно его довести до ума, конкретизировать.

Спустя 31 минута, 10 секунд (31.08.2010 - 09:45) Basili4 написал(а):
Было вроде хорошее предложение написать скрипт логер с разными плюшками. И для дела полезен и даже не сложен. и преимущества и недостатки различных подходов явно покажет.

Спустя 15 минут, 37 секунд (31.08.2010 - 10:01) linker написал(а):
Имхо, полезность тут не важна, мы ж не собираемся где-то использовать полученные результаты. Нужна достаточно простая, нетривиальная задача, которая может не иметь практической пользы, а призвана просто показать плюсы и минусы тех или иных подходов. Задача от waldicom вполне подходит, вот только ТЗ никакое.
Собственно, не нам с twin'ом решать smile.gif

Спустя 3 минуты, 28 секунд (31.08.2010 - 10:05) DedMorozzz написал(а):
Как бы задача, но оффтоп
ТЗ - сделайте всё "заебись". Доп задание, для расширения скрипта - кнопка "грабить корованы".

Спустя 6 минут, 8 секунд (31.08.2010 - 10:11) Basili4 написал(а):
Как так не важна как можно оценить преимущество разработки чего либо ни пользуясь результатом. Задача должна быть проста в реализации. Чтобы избежать ошибок не связанных с особенностью подхода
Иметь все составляющие Веб приложения интерфейс с пользователем, логику, и быть применима на практике для решения повседневных задач. вот когда её захотят масштабировать, внедрить куда то. тогда и полезут все "прелести". А задача ради задачи это только на время.
Оффтоп Бил Гейтс когда показывал какая прелесть его Бейсик он решал практическую задачу с переключением между окнами.

Спустя 33 секунды (31.08.2010 - 10:11) Basili4 написал(а):
DedMorozzz
о уже есть такой скрипт.

Спустя 15 минут, 36 секунд (31.08.2010 - 10:27) Гость_Michael написал(а):
Цитата (twin @ 31.08.2010 - 06:14)
А вот время на последующее обслуживание увеличит на порядок. Ибо тому, кто возьмется потом рефакторить такой сайт, придется разбираться в этом фреймворке.

это если взявшийся не знаком с тем фреймворком( спрашивается: чЁ лезешь тогда? smile.gif ), а для знакомых с тем фреймворком - уменьшится на порядок.
У распространенных фреймворков обширные сообщества - в них и надо искать последующих работников.

Спустя 13 минут, 38 секунд (31.08.2010 - 10:40) twin написал(а):
Гость_Michael

Цитата
это если взявшийся не знаком с тем фреймворком( спрашивается: чЁ лезешь тогда?

Ну как чЁ... Если ты устраиваешься допустим в фирму, а по наследству достается такое?

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

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


На счет полезности задания...
Мне бы не хотелось просто соревнований. Я хочу извлечь пользу по максимуму. И на основе этого написать статью. Или даже серию.
По этому мне такое ТЗ не совсем по душе... А сам придумать не могу, ибо это должен сделать сторонний человек.

Basili4
Что за логер, подробнее плиз...

Спустя 11 минут, 3 секунды (31.08.2010 - 10:51) Rivalryzerg написал(а):
twin, что для вас "знаком с .."? Какими фреймворками вы пользовались, какие досконально посмотрели? Может вы просто не видели достойных "шедевров" которые изучать совсем не надо, т.к. все на ладони?
Думаю это и есть главная причина, почему вы так категорически не принимаете фреймворки и ООП подход в частности.

Вот мне интересно, какой ОРМ вы используете для работы с базой? Или все запросы пишете руками?

PS: обычно такое мнение у людей, кто открыл Zend, посмотрел на этот мегаполис и сделал вывод что все фреймворки такие. Zend я тоже не люблю кстати.

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

Спустя 3 минуты, 47 секунд (31.08.2010 - 10:55) Rivalryzerg написал(а):
Кстати
Цитата
чтобы изменить одну строчку на странице приходится полдня разбирать логику - как же она сформирована

Обычно я такое видел в сайтах, написанных процедурным подходом: что подключается, где лежат классы, где описана та или иная функция - приходится долго и упорно копать, куда же спрятал это все дело программист. Логика в подобных сайтах просто иногда поражает.

Используя популярный фреймворк, я сразу знаю где и что искать, какой контролер открывать и какой метод смотреть. Четкая структура, четкий алгоритм "как делать" ту или иную задачу. На мой взгляд единая структура - несомненный плюс

Спустя 12 секунд (31.08.2010 - 10:55) Michael написал(а):
Цитата (twin)
Ну как чЁ... Если ты устраиваешься допустим в фирму, а по наследству достается такое?

фиг устроишься на фирму если они работают с каким то фреймворком, а ты его не знаешь.

Цитата (twin)
Или к тебе обращаются люди, утерявшие связь с исполнителем? С просьбой рефакторить сайт... Расписаться в полном неумении? Или отправить заказчика искать того, кто знаком с этим самописным шедевром?

Если с самописным - разбираться (если выгодно). Только речь вообще то не о самописных ...
А один из распространенных - да, расписаться в неумении и отправить ... Тот кто умеет, сделает быстрее и вероятней лучше- клиент доволен.

Спустя 2 минуты, 49 секунд (31.08.2010 - 10:58) Michael написал(а):
Цитата (Rivalryzerg @ 31.08.2010 - 09:51)
Может вы просто не видели достойных "шедевров" которые изучать совсем не надо, т.к. все на ладони и не нужно ничего изучать?

Огласите список пожалуйста, очень интересно.

Спустя 6 минут, 5 секунд (31.08.2010 - 11:04) Rivalryzerg написал(а):
Michael, это конечно образное выражение было. Обладать какими-то знаниями все же нужно, но совсем не "пыхтеть полдня". Имея небольшое представление о фреймворке, я могу сразу найти место где поправить код, или место где добавить пару тегов в отображение.

На данный момент мне не один не нравится. Может быть год или два назад я вам назвал бы кейк или симфони.

Сейчас я в восторге от литиума, но он лишь на стадии разработки. ОРМ больше всего понравился в кейке, хотя доктрин помощнее, но и побольше. Модульная система - от зенда. Добротные хелпера я нашел в yii, а lazy-подгрузку классов я бы взял из литиума.

Спустя 26 минут, 19 секунд (31.08.2010 - 11:31) twin написал(а):
Цитата
twin, что для вас "знаком с .."? Какими фреймворками вы пользовались, какие досконально посмотрели? Может вы просто не видели достойных "шедевров" которые изучать совсем не надо, т.к. все на ладони?

Я очень часто занимаюсь рефакторингом. Так что видел много. И самописных и распространенных. Я писал уже об этом.
Довольно плотно пришлось поработать с CakePHP и CodeIgniter. Zend ковырял из любопытства.

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

Michael
Цитата
Если с самописным - разбираться (если выгодно). Только речь вообще то не о самописных ...
так речь и идет о самописном. Новом. И суперпупермегакрутом. Лишенным всех видимых недостатков.

Это очень полезное занятие - изобретать такие велосипеды. По крайней мере оно даёт возможность убедиться в утопичности таких заявлений. И понять настоящую суть фреймворков.

Спустя 3 минуты, 42 секунды (31.08.2010 - 11:34) Rivalryzerg написал(а):
После вашего последнего сообщения - больше вопросов нет) Вы парой строк ответили на все сразу.

Предложение снято. Метеостанции куда круче.

PS: главное не забывать, что тот же кейк писал один человек, сообщество и команда появилось позже.

Спустя 47 минут, 26 секунд (31.08.2010 - 12:22) waldicom написал(а):
Цитата (DedMorozzz @ 31.08.2010 - 09:05)
Как бы задача, но оффтоп
ТЗ - сделайте всё "заебись". Доп задание, для расширения скрипта - кнопка "грабить корованы".

Это не просто 5, это ... это... как сейчас модно говорить стотыщпитсот!!

Спустя 4 минуты, 20 секунд (31.08.2010 - 12:26) linker написал(а):
Ну так будут предложения какие по существу вопроса? Или twin'у придется таки скушать свой галстук smile.gifsmile.gifsmile.gif

Спустя 3 минуты, 15 секунд (31.08.2010 - 12:29) Michael написал(а):
Цитата (linker @ 31.08.2010 - 11:26)
Ну так будут предложения какие по существу вопроса? Или twin'у придется таки скушать свой галстук smile.gifsmile.gifsmile.gif

предложений не будет, пусть кушает галстук. rolleyes.gif

Спустя 22 минуты, 34 секунды (31.08.2010 - 12:52) twin написал(а):
Цитата
Или twin'у придется таки скушать свой галстук

Опять вы попутали. mad.gif
Шляяяпу!!! biggrin.gif

Спустя 3 часа, 53 минуты, 15 секунд (31.08.2010 - 16:45) Mizka написал(а):
Цитата
Basili4
Что за логер, подробнее плиз...

библиотека для журналирования (эксепшенов, сообщений, всего что может понадобится для дебага и не только) в любом виде и в любое место (на что фантазии хватит) smile.gif
Могу дать ссылку на аналоги... но так не интересно smile.gif

Спустя 2 месяца, 6 дней, 2 часа, 45 минут, 15 секунд (7.11.2010 - 20:30) Joker написал(а):
а вот мне интересно кто нибуть слышал о чом то подобном:
Цитата
программист должен использовать то что больше всего подходит под конкретную задачу

я уже пол год пишу на ООП и вижу все его и плюсы и минусы.

у меня один вопрос появляется когда я читал вот эту тему (чесно скажу всё осилить не смог) зачем выбирать ООПешное или Процедурное программирование??

вот мой личный опыт:
у меня есть проект написанные полностью на ООП да пришлось слегка заморочится и спланировать, но остальное писалось проще простого зато.

есть другой проект который весь на процедурках и тоже написался он легко.

есть третий который сочетает и ООП и процедурное, где 70% написано на ООП остальное процедурное.


также сейчас поддерживаю проект написанный на зенде (тот еще ООПешный геморой) но впринципе не зная как он работает даже на 10% отлично справляюсь благодоря ООП.

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

Я довно вынес для себя 2 вещи:
Что использовать ООП или Процедурное зависит от конкретной задачи.
Если проект написал адекватным прогером то хоть то ООП хоть Процедурное разобратся не сложно и не долго, а если не адекват полный то что твин что глок вылятят в трубу что их метод легче.


Итог:
1 вопрос: зачем выбирать ООПешное или Процедурное программирование??
2 вопрос: почему не использовать каждое из 1 вопроса по предназначению.


p.s. php движется к ООПешному программированию) так что делаем выводы что думают создатели php о ООП)

Спустя 13 минут, 16 секунд (7.11.2010 - 20:44) twin написал(а):
От того и вопросы, что не все прочитал. smile.gif

Спустя 7 минут, 11 секунд (7.11.2010 - 20:51) inpost написал(а):
Ну раз вернулись к этому, блесну тогда и я, своим маааааленьким мнением.
Вот изучал JS, это просто прекрасно, DOM дерево - это и есть полная структура объектов на ООП, чего только стоит такой код: document.body.forma.input[0].value - это прелесть, вот так надо строить ООП. А если это маленький, или даже средний сайт, ООП - пустая трата времени. Создать дерево из двух-трёх элементов, и написать в 10 раз больше кода? Разве только чтобы поднять ЧСВ, не более.
Я вижу только возможность использовать ООП в огромных проектах, вплоть даже до создания фреймворка, небольшой копии языка в языке. А с другой стороны как говорят гугл-эксперты: "У нас на сайте есть одна страничка на ПХП, мы ею пиццу заказываем". Для крупных проектов используют совсем другие, более быстрые языки.
Пока ПХП не станет более быстрым языком, то и нет смысла использовать ООП, хотя знать надо, чтобы чинить сайты после других....

П.С. улучшаю сайт после другого чела, так вот, вывод из БД он переводит дополнительной функцией в объект. Теперь вместо обращения $rights['canEditProfile'], приходится писать $rights=>canEditProfile. Разницы никакой, зато перевёл обычный массив в объект, он профессионал! =)

Спустя 9 минут, 53 секунды (7.11.2010 - 21:01) Joker написал(а):
Цитата
От того и вопросы, что не все прочитал.

плиз продублируй я после работы не в силах уже вот ЭТО ВСЕ читать)

Спустя 7 минут, 38 секунд (7.11.2010 - 21:08) twin написал(а):
Ну вот допустим. И там много такого.

Спустя 26 минут, 15 секунд (7.11.2010 - 21:35) Joker написал(а):
простой пример недавно в проекте был.

такая вот предметная область:
пациент.
заявка в СКУ (Санаторно Курортное Учереждение в народе Санаторий)
Путевка.

Пациента можно создать/редактировать(может только тот кто создал) всё легко.
Путевка можно:
создать
редактировать (может лишь тот кто создовал)
утвердить заявку (может лишь человек из СКУ в который посылается Пациент)
отменить заявку (может лишь саппорт или МЗ (Минздрав) )
пометить на отмену (может тот кто создать) - когда заявка помечена саппорт в соей админке должен её оменить или удалить пометку послав сообщение о том что отмена невозможна.
восстановить (может лишь саппорт или МЗ (Минздрав) )

при каждом действии посылается уведомление о действии:
создание (в ску в которое направляет пациент)
утверждение (человеку который создовал)
отмена (и тому кто создовал и в ску которое направлен пациент)
восстановление (и тому кто создовал и в ску которое направлен пациент)

путевку описывать не буду. там еще сложней да и заявки хватит с лехвой.

создание пациента тут все просто форма создание редактировани.

заявка тут уже становится интересней.

вот коль скажи как ты будешь реализовывать?
у тебя есть 1 лишь функция готовая sendMessage((int)$idAuthor,(array)$idToUsers,(string)$title,(string)$message):boolean

и объект User где хранятся все данные по пользователю который сейчас производит дейсвие, авторизация, направление именно на этот скрипт всё делает движок.

Спустя 11 минут, 10 секунд (7.11.2010 - 21:46) Joker написал(а):
фактически я тебе щас предлагаю батл, я в роли заказчика и при этом исполнителя. поскольку у меня проект готов я знаю как реалзованно у меня на ООП, довай буквально за 1-2 часа виртуально создадим проект? можешь сейчас?

Спустя 5 минут, 31 секунда (7.11.2010 - 21:51) twin написал(а):
Любой скрипт, как бы он не был бы реализован, работает с информацией.
Информация где то хранится. Взять её и обработать...
Не вижу никаких затыков в сей задаче. Хоть так её решай, хоть эдак.

Все равно разными действиями занимаертся различный функционал.
Если он сложен, то решу набором классов. Если нет, обойдусь императивным подходом. ООП тут причем?

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

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

Спустя 5 минут, 39 секунд (7.11.2010 - 21:57) Joker написал(а):
Правила батла просты:
1. Рассматривается проект не просто сделал и сдал, а сделал и остаёшься на поддержке минимум 2 года. при этом на тебе еще 4 проекта которые ты поддерживаешь.
2. во время батла каждый учасник пишет какие у него есть объекты(методы в нем, и свойства)/функции
3. помнить весь проект на изусь не льзя, это не реально.

Процесс простой:
1. каждый говорит описывает бъекты(методы в нем, и свойства)/функции и выкладывает не пишет а описывает!
2. 1 учасник придымавает расширение функционалаю
3. оба пишут что они изменять и примерное кол-во времени которые потратят на это.
4. 2 учасник придымавает расширение функционалаю
5. оба пишут что они изменять и примерное кол-во времени которые потратят на это.
и начиная с пункта 2 повторить 5-10 раз сумируется время которое потраченно на изменения.




вот как то так) ну я так это вижу)

Спустя 3 минуты, 39 секунд (7.11.2010 - 22:01) Joker написал(а):
Цитата (twin @ 7.11.2010 - 23:51)
Любой скрипт, как бы он не был бы реализован, работает с информацией.
Информация где то хранится. Взять её и обработать...
Не вижу никаких затыков в сей задаче. Хоть так её решай, хоть эдак.

Все равно разными действиями занимаертся различный функционал.
Если он сложен, то решу набором классов. Если нет, обойдусь императивным подходом. ООП тут причем?

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

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


ну вот я тебе на простом примере попытаюсь доказать, что ООП круче) (хотя я так не считаю) но знаю как доказать)


_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.