Могучий ООП, проблемы реализации

[Toxic_Cat]

Могучий ООП, проблемы реализации

Раньше реализовывал все свои сайты и скрипты банально и просто: функции и подключаемые файлы с исполняемым кодом... Конечно при разработке следующего сайта было ОЧЕНЬ тяжело что-то переделать, я уже не говорю про то, что понять логику скрипта годечной давности...

Конечно пошел по книгам и в поиск за ответами, нашел ООП, он обещал решить все мои проблемы... Прошло полтора месяца... Уже какой раз, какой день, какой час я сажусь писать сайт на технологии ООП... Пишу сутки или меньше, потом "спотыкаюсь" жму CTRL+A -> Delete... И пишу заново...

Дайте мне ссылки пожалуйста на учебники по ООП, самое важное это применение ООП уже в проектах на готовых примерах, теории читал уже достаточно:
"Профиссеональное PHP программирование 2-е издание"
"PHP 5 Библиотека профиссеонала"
"Разработка Веб приложений с помощью PHP и MySQL"
Юзал поиск форума по запросам ООП
Читал известные сайты в разделе про ООП

и после всего этого я до сих пор ничего больше чем mysql.class написать не смог...

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

Может вы мне подбросите пару ссылок на скрипты с применением ООП? Сейчас просматривал классы в системе e107 но эт тоже слишком все наворочено для нуба типо меня...

Хочу все реализовывать с помощью ООП, как это делает Курепин.Ру, но я хочу не просто реализовывать а еще и понимать что я делаю, а с эти как-раз у меня проблемы...

Приму с благодарностью любые ссылки и советы

Возможно эта тема попадет в "мусор" но я бы очень этого не хотел...

 

[Фанат]

ООП, он обещал решить все мои проблемы...

тебя обманули

 

[Гравицапа]

Гради Буч - "Объектно-ориентированный анализ и проектирование
с примерами приложений на С++"

Дайте мне ссылки пожалуйста на учебники по ООП,

гугл.ком

как это делает Курепин.Ру, н

что за боги? почему не знаем?

 

[Фанат]

о, как же я не заметил.

Хочу все реализовывать с помощью ООП, как это делает Курепин.Ру

Toxic_Cat
я сейчас открою тебе страшную тайну. Курепин.Ру - чудак. на большую букву М.

-~{}~ 13.12.05 22:29:

у меня есть сильное подозрение, что из тех, кто применяет ООП, 95% делают это неправильно.
Объекты городятся по делу и не по делу.

Объекты сами по себе - не панацея от запутанности кода. Наоборот. Читабельность и поддерживаемость сего снижается.

Toxic_Cat

при разработке следующего сайта было ОЧЕНЬ тяжело что-то переделать

ты не пробовал анализировать - ПОЧЕМУ именно тяжело?
и действовать на основании выводов, а не слушать развесив уши, сказки про ооп?

 

[asm]

Фанат
95% ???
откуда статистика?

 

[Фанат]

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

идиотов, считающих, что есть волшебное слово, которое в корне изменит их жизнь, на замле как раз примерно такое количество.

 

[asm]

Беда ООП в том что многие просто заставляют на нем писать.
А если не понимаешь а надо тут можно такие перлы встретить ))

 

[white phoenix]

Фанат
> идиотов, считающих, что есть волшебное слово, которое в корне изменит их жизнь, на замле как раз примерно такое количество.
есть такое слово - PHP, но я не идиот

 

[Toxic_Cat]

Разве я не обязан писать на ООП все свои проекты? Разве я не должен испытывать чувство стыда за свои прошлые проекты, которые не реализованы на ООП?

Курепина я читал давно и на те времена он был для меня единственным великим программистом на PHP...

Фанат Вы все верно говорите, но как я могу действовать исходя из своих методов когда я не знаю правильно ли я это делаю?

Я читал много споров по поводу нужно ли использовать ООП или нет и когда, но точку поставил именно Курепин, ибо он везде сует свой ООП и у меня сложилось мнение что так и нужно!

Тяжело определиться. Слишком много мнений.

Спасибо Гравицапа, но откукда Вы думаете я взял всю эту информацию? Я просил ссылки по которым Вы "учились".

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

Тогда почему в пятой версии PHP сделали так много нововведений в именно в области ООП?

Наставьте меня на праведный путь. Не подумайте что я делетант, просто я еще не сделал свой выбор...

 

[Фанат]

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

но как я могу действовать исходя из своих методов когда я не знаю правильно ли я это делаю?

ДУМАТЬ надо. АНАЛИЗИРОВАТЬ свои методы. Не чужим умом жить, а своим.
у тебя есть критерий - "тяжело переделать". Ну так должны появляться мысли о том, как сделать проще.

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

сформулируй для себя - в чём проблема? в чём трудность? И решай её. ищи решение. не в волшебных словах и не абстрактной проблемы "трудно переделать", а конкретной.

-~{}~ 13.12.05 23:55:

Тогда почему в пятой версии PHP сделали так много нововведений в именно в области ООП?

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

 

[master_x]

Toxic_Cat
Курепин просто по тупому в каждом своем "туторе" запихивает функции в классы и говорит, что это- ООП. Так делать нельзя! Надо сначала понять ООП а потом уже браться. "ООП делает код красивее, читабельнее и его можно потом использовать в других проектах", знаешь, где-то я читал статью от очень именитого программера и там было подробно рассказано, почему ООП не имеет перспектив (не бейте, читайте дальше), одной из причин по его мнению, было то, что ООП не оправдал надежды в плане послед. использования кода с мин. телодвижениями. В некотором плане могу согласиться с ним, потому, что многие, кто берется за ООП просто не понимают его и получается, что потом их код уже нельзя перенести в другую разработку безболезненно. Если тебя так волнует, то ты не можешь перенести свой код в новое приложение, то почитай про стандарты написания кода, делай свой код в меру универсальным и читабельным. Проектируй основу своих приложений. У меня есть фреймворк, весь написан в структурном стиле, и ничего, весь код охватывает 90% моих нужд и кочует из приложения в приложение.

 

[Toxic_Cat]

2 Фанат и master_x
Спасибо огромное. Думаю я надолго сохраню эту тему и ваши посты у себя на ЖД и буду перечитывать каждый раз, когда буду чудить или сомневаться

Думаю Ваши комментарии следует прочитать многим...

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

Буду учиться анализировать свои ошибки и действия.

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

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

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

 

[Фанат]

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

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

не надо писать сложные функции. чем сложнее функция, тем труднее её неренести.

функция не должна выводить на экран хтмл-код. если она это делает, то переносить её нельзя.

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

шабон опять, волшебным образом, тебе не устроит райскую жизнь.
ты САМ должен думать, какой код использовать в шаблоне, а какой - в коде. ты должен сам минимизировать присутствие в шаблоне кода.

 

[HEm]

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

 

[atv]

Toxic_Cat почитай всётаки Гради Буч - "Объектно-ориентированный анализ и проектирование с примерами приложений на С++" (http://books.kulichki.net/data/c/c/). Она успокоит и позволит понять что ОО Проектирование не такое уж и сложное. Более того, совершенно нет необходимости делать выбор между процедурным и ОО программированием, их вполне можно умело сочетать, так как оба имеют свои достоинства и недостатки.

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

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

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

 

[kruglov]

Еще можно Javой позаниматься, там вообще без слова class программу не напишешь.

 

[_RVK_]

Согласен с Фанатом в том, что ООП не панацея. Только грамотное использование ООП несет выгоду. НО. Как научится грамотно использовать ООП? Только через грязный код. Только через непереносимые классы. Только через тыканье классов куда нужно и куда нет. Только методом проб и ошибок можно наконец научится использовать ООП так что бы небыло "при разработке следующего сайта было ОЧЕНЬ тяжело что-то переделать"

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

А начинать нужно, конечно с кода. И только когда, у тебя возникнут конкретные вопросы, когда ты начгешь понимать что что-то делаешь неправильно, тогда начинай читать литературу, конечно не Курепина а классиков Буча, Страуструпа, Фёллера и др....

 

[whirlwind]

Сейчас уже можно сразу с рефакторинга

 

[Toxic_Cat]

Видимо долго мне еще до Ваших высказываний. Чтобы так помогать людям надо знать суть вопроса. Спасибо.

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

Да, вот Фанат точно подметил одну мою главную проблему: вывод HTML кода все-таки присутствует в моих функциях, конечно это практически на ноль снижает их переносимость, уж легче новую написать.

HEm верно, озарения приходят и я начинаю понимать "Так делать не надо ни в коем случае!"
Но случается это не часто

kruglov спасибо, но Джавой пока не занимался, так как не знаю где и зачем она мне пригодиться.

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

atv Спасибо, как появятся деньги я куплю эту книгу, не люблю читать с Интернета а распечатки это тоже не дело...

Хм. Итог рассуждений один - учиться, учиться и еще раз учиться (с)

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

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

 

[whirlwind]

> хорошая дескуссия на вечную тему

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