Очень Офигенно ПомогаетОбъясните, пожалуйста, на пальцах что такое ООП
Как он может _понимать_, надо это ему или нет, если он не знает _теорию_ ООП??? Теорию ООП надо сначала изучить, а уже после того решать - использовать или нет.если не понимаешь, значить это не твое и забудь про это Очень
мыслить объектами НАДО в любом слукчае. Ибо на ОО подходе строится весь мир.в первую очередь стиль мышления
Зря ты это сказал. Сейчас опять холивары начнутся ООП vs неООП. И всех, кто скажет, что ООП - хорошая практика, назовут "фанатиками", "пионерами", "теоретиками" и т.д. и т.п. Это уже было )))мыслить объектами НАДО в любом слукчае. Ибо на ОО подходе строится весь мир.
А в этом случае он на 100% может исключить (как минимум) объект колесоА когда машина просто не заводится, с каким объектом работаешь? Давай попробую угадать... Замок зажигания?

замечательный ответ!А в этом случае он на 100% может исключить (как минимум) объект колесо

мыслить объектами НАДО в любом слукчае. Ибо на ОО подходе строится весь мир
не столько это, сколько так. Вспомним, например, Александра СтепановаЗря ты это сказал
кстати, есть еще такой момент. Ведь можно и на процедурном языке программировать в стиле ООП. Т.е. все эти class, public, protected... - синтаксических сахарI find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.
пожалуй стоит начать с того, как ты себе представляешь процедурный подход решения этой задачиЧем это удобнее процедурного подхода? На примере построения например обычного информационного сайта "рубрика->подрубрика->страница"
Сейчас опять холивары начнутся ООП vs неООП. И всех, кто скажет, что ООП - хорошая практика, назовут "фанатиками", "пионерами", "теоретиками" и т.д. и т.п. Это уже было

5+!Теорию ООП надо сначала изучить, а уже после того решать - использовать или нет.
а как это, программировать без ООП? http://phpclub.ru/talk/showthread.php?postid=873430#post873430ООП нужно там, где оно действительно нужно. Программировать вполне можно и без ООП и будет не хуже. Быть в каждой бочке затычка ООП не должно.
Это Капитан Очевидность тебе подсказалООП нужно там, где оно действительно нужно.

Хм... А если программировать на ассемблере, будет ничем не хуже чем на PHP?Программировать вполне можно и без ООП и будет не хуже
Alexandre, +1, просто где заканчивается процедурный подход, а где начинается ООП? Можешь прокомментировать это?когда мне нужно написать 10 строчек простого функционала (например для крона или разовых расчетов ) - я не создаю пару классов или один мега класс с методом Run()...
Вот есть у нас набор функций для работы с файлами. Но тут нам понадобилось работать с двумя файлами: создаем структуру, в которой храним информацию о файле и используем ее качестве первого параметра. Это процедурный подход или ООПешный?
+1когда мне нужно написать 10 строчек простого функционала (например для крона или разовых расчетов ) - я не создаю пару классов или один мега класс с методом Run()