Ну а толку что еще какой-то товар будет иметь эти же свойства все равно мне придется эти свойства сохранять в таблице в БД?

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

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

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

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

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

Не без этого

Это почему?

Там 52 страницы обоснований. Читать лень или уверенность, что обоснований нет?

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

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

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

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

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

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

Вернее тут тоже есть встроенные классы. К примеру библиотека mysqli или тот же Exception. Однако это мизер, и поборникам ООП в PHP приходится самим изобретать велосипеды, гордо называемые фреймворками.

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

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

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

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

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

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

Распределение труда в моём контексте это использование разных уровней разработчиков (например), если в методологии RUP то эти уровни можно варьировать в определённый момент по разному при этом экономить соответствующие ресурсы.

Этим занимаются менеджеры и архитектора.

Опять 25. Да я не против парадигмы, как таковой. Я просто не вижу выгоды от неё именно в PHP.

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

Тот же самый ZEND фреймворк. Много он упростил? Наинкапсулировал сложностей и тут же нарожал кучу гораздо более других. Какая нафиг управляемость, какая производительность, если вместо одного мануала приходится курить два?

Это очень громкое заявление. Так говорят люди, совершенно незнающие предмета. Вернее знающие его однобоко. Раз Макконнелл сказал так, значит все остальные - дилетанты.

А вот допустим совсем не дилетант думает совершенно иначе. И таких очень много.

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

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

А иначе никакая

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

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

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

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

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

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

С ув. Greg1978

Кстати о фреймворках, я не знал JS и не знаю его досконально до сих пор, но jQuery даёт мне в руки мощный инструмент не зная на чём он построен. Что это даёт?
Я не зная языка программирования (это уже снижает мою квалификацию), но фреймворк я в принципе изучил дней эдак за 3 - 4, его так сказать мануал покурил, и я могу свободно использовать его в своих проектах. Так что же нам дал фреймворк, моё изучение JS до кваифицированного состояния минимум пол года или ммаксимум недели вкуривания мануала?

Ясное дело что функционализм ведёт к упрощению, ну и минус к гибкости.

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

Не вижу препятствий сделать такой тест для процедурки.

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

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

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

Либо это будет фреймворк. А фреймворк хорош только в прикладных языках (да и то спорно). В веб-программировании это зло. Аргументов тут на форуме полно. Повторяться лень.

PS javascript - прикладной язык. Пример с jQuery некорректен.

Дайте хотя бы один многосторонний тест модуля.

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

Ок не буду спорить и всё же это никак не касается свойств языка.
Кстати приставка Script говорит о языке что он скриптовый, как и PHP.

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

Камень в огород Ruby и Python

Дайте модуль, дам тест. Я могу с той же просьбой обратиться.

Вот это больше всего и радует. Что нет "стандартов", которые в ООП у каждого свои. А если стандартов более чем один, это не стандарт уже, а кистень (с)

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

Я не буду сползать с темы ООП на тему фреймворков. Это другая тема. Такая же спорная. Одно скажу - ООП без фреймворка в PHP никакого прироста ни производительности труда, ни производительности приложения не несет.

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

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

По меньшей мере странно, не я ж сторонник процедурного подхода.
А если Вам нужен тест для класса так это пожалуйста

Не надо а то причислят к

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

Читаем в аттаче. Там достаточно аргументов и методологий. И написано это людьми, имеющими мировые имена.

Ключевое слово - создавать)))
А кстати ООП по словам Стерлинга Хьюза

Так что тут фиг знает, кто больше потеет.)

Кстати об аттаче, не ужели до сих пор используется "водопадный процесс", кстати на нём статья и основывается. Однако мы уже далеко за рубежом 2000 года, уже давно рулят другие методологии более эффективные. Вы смотрели год литературы сией статьи?

Так вот и нужно поостеречься в другой раз от безапелляционных заявлений плана

не разобравшись толком в вопросе.

Кто-то приоритетным считает заработать сиюсекундную копейку или устроиться на работу клепать визитки на фреймворке, а кто-то хочет стать Разработчиком. И ему как минимум нужно понять, какие плюсы и какие минусы у разных подходов, чтобы выбрать для себя нужный путь.

Именно такой вопрос задал топикстартер

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

Теперь моя очередь - это голословно. Хотелось бы ознакомиться хоть с одной в противовес.

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

Я уже приводил одну из них, базирующейся на более "старой" UP - это RUP.
Далее - XP и другие agile методики, OpenUP, Scrum, MSF (microsoft foundation) и это только одни из известных, но "водопадный процесс" уже почти потерял силу, он остаётся только в корпоративных "монстрах" и то уже теряет и там силу. Извините опять за оффтоп.
Если Вы используете "водопадный процесс" тогда становится ясно почему Вам импонирует процедурный стиль проектирования.

Меня наверное не слышно

Кстати Вы так и не ответили на мой вопрос по поводу тестирования и наследования процедур.

Возможно
Но это Ваше понимание сути этой дискуссии не навязывайте её другим.
Контекст мануалов и их изучения немного отошёл от темы но не совсем.

Можно, почему же нельзя Есть такая штука, как сериализация (функции serialize и unserialize). И еще читай про "магические" методы классов __sleep и __wakeup - как раз они отвечают за сериализацию и восстановление данных.

--------------------

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

------------------

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

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

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

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

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

А что я должен ответить? Что я при процедурном подходе не смогу унследовать класс для проведения тестов? Там совсем другие способы тестирования. С теми же результатами.

Кстати говоря, как сей класс использовать в отрыве от PHPUnit_Framework?

И еще, для таких тестов не нужны велосипеды, есть Reflection
И если у меня сложный функционал оформлен классом, то легко и просто можно пользоваться им. А если нет, то иными методами трассировки.

Только причем тут ООП парадигма вообще?

Не понял фразу....

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

Ради Бога - аргументируйте. А сказать, что

- это тоже самое, что сказать - подрастешь, узнаешь. Подрос я давно)

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

С phpunit привёл пример так как он один из известных причём уже ставший стандартом.

Вот это в точку. Процедурный с ООП.

Ок, ещё раз извините спокойной ночи!

Так и тут нет примеров. Есть выдернутый из контекста фреймворка класс тестирования, который совершенно излишен и никак не стандартизирован.

Первый раз о таком слышу, каким еще стандартом? Для кого?

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

Так что это никакой не плюс.

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

И по второй ссылке не все так просто.

А меня осадили однозначно. Не будьте таким как twin... Да почему это?
Мне моя позиция и положение нравятся, почему не быть таким...

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

PS И Вам добрых снов.