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

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

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

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

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

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

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

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

glock18

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

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

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

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

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

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

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

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

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

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

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

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

UPD
Michael

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

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

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

twin, стоит ли повторять, что речь об ООП в этой фразе? не надо тут о php-подходах типа ПООП или ОПОП (процедурно-объектный )

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