О какой расширяемости идет речь?

Я задал несложный вопрос, ответ на который хотел бы получить:
Неужели нужно создавать экземпляры классов чтобы сервер отдал две склеенные строчки?

В подавляющем большинстве случаев можно просто поставить switch

я смотрю тебе опять кони в астрале, программы писать мешают :D :D :D

результат неодинаковый,
в одном случае это базовая идея для движка, в твоём случае чушь из одной строчки:D

Решение в процедурном стиле существует штуки два как минимум, пусть не такие красивые как в ооп, но они есть. Жду до завтра, потом сам отвечу.

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

но это всё детские шалости, страшнее всех задача с чайниками :D :D :D

Обычная такая расширяемость. Сталкиваюсь постоянно, ты нет?

Я ещё не писал "всё", поэтому уверенно сказать не могу. Я склоняюсь к тому, что всё можно написать в процедурном стиле. Более того, мне нравится идеология Erlang-а, на хабре есть очень хорошая статься на эту тему.

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

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

И ещё. Твой пример:

на самом деле не пример процедурного подхода - тут нет процедур. Просто исходный пример неудачный.

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

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

Есть такое слово - достаточно. Так вот этого мне достаточно.

До недавнего времени я даже использовал всего один файл на php. И это после того, как я на одном проекте сделал их больше сотни. Ахаха :) Это была соц.сеть с почтой и группами, а потом написал все в одном файле, не безразмерном конечно. Ахаха :)

В целом это утверждение относиться в той же степени и к процедурному подходу.

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

Легкость восприятия? Когда это ООП стало легче в восприятии? А не от комментариев ли зависит скорость понимания происходящего в коде?

Насколько мне известно ООП начинает работать только если приложение очень сложное и большое. Но есть проблема, у меня нет сложных приложений для PHP. Уж извините, но их у меня нет. Я не смог придумать ни одного приложения, чтобы начать там использовать ООП.

Какой пример, такой и ответ.

Чтобы небыло батхерта, я могу сказать что в js я использую ООП, много и жирно :) Ну ещё могу сказать, что наверняка бы использовал ооп php в шаблонизаторе, но не уверен, т.к. я не хочу писать на php в последнее время.

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

Cоциальная сеть в одном файле ??? :blink:

Ну любишь процедурный стиль ну дак давай решим хоть одну архитектурную проблему в процедурном стиле.

Ты это признаешь? :) Ты сам себя так назвал. Прости, если это задело твои чувства, но это просто вывод из твоих слов.

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

Хотите поговорить об этом? (с)Зигмунд Фрейд.

Нихуя подобного - вопрос вполне практичный.

Оно есть и в ООП. Всему должна быть мера.

Требую пример.

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

Опять же - всему есть предел. Посмотри пример. Внешне - ООП (конструктор, вся хуйня), но внутри методов нет объектов - они не нужны там! И как ты предлагаешь реализовать буфер в процедурном стиле? PHP-way с кучей методов? Жду ответа.

Как скажешь, это наверное слово заветное такое, после которого я должен кинуться приводить примеры и клясться на надгробном камне?

NodeJS:

Ресурсы посвященные NodeJS:
Руководства по Node.js
БЫСТРЫЙ ВЕБ-СЕРВЕР НА JAVASCRIPT ДВИЖКЕ V8
Node.js для начинающих

Базы данных:
Перевод The Little Redis Book Redis - это NoSQL база данных которая очень хорошо дополняет NodeJS. Мне очень нравится.
The Little MongoDB Book

Статьи:
JUST — JavaScript шаблонизатор
Наглядно о потоке выполнения в Node.js
Разработка WEB-проекта на Node.JS
Полезные инструменты, туториалы и ресурсы
Удаленный вызов процедур в Node.js с использованием Now.js
О WebSocket-ах на примере реализации чата мгновенных сообщений с помощью node.JS Немного устаревшая статья.
Вызываем функции Windows API (и любые другие функции, написанные на языке Си) джаваскриптом из Node.js

CMS:
Calipso is a simple content management system

Не придирайся к словам.