ООП в ПХП

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

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

Вероятно я чего то не до понимаю, может кто подскажет литературу, наглядное видео.

да наёбка это все. один хуй, что писать электропечь->греть(200 С), или греть(электропечь 200 С) - наёбка полнейшая.

чет я не понял сарказма.

электропечь->греть(200 С)
греть(электропечь 200 С)
но может правильно было бы
электропечь(греть 200 С)

А в PHP ООП c классами и наследованием как полагается или какое-то катрированое типа прототипированого или чисто обьектное?

Lexikon: На хабре читал высказывание, если не понимаешь зачем ООП значит пока нет необходимости

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

Lexikon писал:

но может правильно было бы электропечь(греть 200 С)

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

Lexikon писал:

чет я не понял сарказма.

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

Lexikon писал:

электропечь(греть 200 С)

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

что там за минусист
напиши в чем недовольство?
Тебя чем то обидели?
Расскажи чем?

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

в опп мы оперируем абстракциями, какими то объектами, которые имеют некие состояния и поведения.

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

+ переносимость кода и при правильном проектировании (отдельная история) легкость поддержания кода, когда мы можем менять реализации и т.д. безболезненно для всего процесса.

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

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

сами статьи:
ООП с примерами (часть 1)
ООП с примерами (часть 2)

freeek писал:

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

не путайте ТС все это ему нафиг не нужно, я и сам постоянно забываю что из этого что значит

по простому говоря, в 90% пхпшный ооп юзается для группировки функций.
например:

Код:

class Parser { public static function parse_youporn($settings) {...} public static function parse_tube8($settings) {...} } class Config { public static function get_domain() {...} public static function get_parser_settings($tube) {...} } $settings = Config::get_parser_settings('youporn'); Parser::parse_youporn();

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

а в чем здесь ооп? я не делаю привязки к языку.

группировать функции объеденные общим контекстом как статические методы класса,.. когда это нужно в этом есть смысл, почему нет)

человек заинтересовался ооп, я подсказал) и эта подсказка - песчинка в пустыне, но зато есть вектор в направлении которого можно двигаться)

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


тут, просто, надо знать меру, где он нужен, а где нет.)

freeek писал:

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

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

freeek писал:

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

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

Stek писал:

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

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

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

Всегда обходился без пространства имен, не понимаю нафиг оно в пхп.

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

1. кто не юзает ооп тот лох.
2. кто юзает ооп неправильно тот лох.
3. опп без шаблонов не ооп.

ну как, мы движемся и учимся
расширяем базу знаний

FXIX писал:

... 2. кто юзает ооп неправильно тот лох. 3. опп без шаблонов не ооп.

freeek писал:

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

Всё верно. Без этих вещей запись $object->method() не является ООП.

CABMIT писал:

Всё верно. Без этих вещей запись $object->method() не является ООП.

в таком виде не совсем понятно что это, но тем не менее это не отменяет то, что нужно понимать принципы)

CABMIT писал:

Без этих вещей запись $object->method() не является ООП.

А что это по твоему ?

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

Stek писал:

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

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

freeek писал:

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

namespace это все-таки немного другое.
группировка по какому-то признаку это очень даже ооп.
я уже не первый год периодически подхалтуриваю на мастере и точно могу сказать что наследованиеи пр. - нахер не нужно в 90% задачах мастера

grozny писал:

хз насчет новых типа laravel, надо смотреть.

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

http://habrahabr.ru/post/208904/