Если существует и то и другое, то оно кому-то нужно и кто-то находит оба подхода удобными. И всё-таки может быть есть задачи для которых например prototype-based OOP подходит лучше чем class-based и наоборот. Вот хотелось бы узнать вставал ли кто-нибудь перед выбором между этими подходами и к каким выводам пришёл. Спасибо.

Могу выразить свое мнение: подход ставит перед разработчиком, как факт, язык программирования. А язык программирования выбирается в зависимости от задачи. Так что проблема выбора подхода, IMHO, встать не может.

Я думаю вот это http://htmlcoder.visions.ru/JavaScript/?3 - хороший пример чем prototype-based отличается от class-based.
Суть примера в том, что можно изменить поведение уже существующего класса подключением стороннего модуля, как такое провернуть в class-based языке, я не представляю.
Буду рад, если поделитесь мыслями по поводу java или php аналогий javascript-овскго "SomeClass.prototype.myMethod=function(){...}".

setq, вопрос интересный.

Лично мне кажется, что prototype-based наследование уместно в проектах мелкого уровня, когда есть человек, который держит программу в голове и у него, возможно, есть один-два помощника. Т.е. эти проекты трудно-масштабируемы. И это встаёт проблемой когда мы пытаемся создать большое приложение со сложной логикой.

Главная проблема мне видится в инкапсуляции, которую не учитывает prototype-based наследование. Её можно добиться на простейшем уровне (напр. в JavaScript - c использованием closure), но протащить её через prototype-based наследование весьма затруднительно. Я поставил такую задачу и это сделал для JavaScript (в этой теме), но получившийся в итоге паттерн оказался довольно громоздким, на гране пригодности из-за своей сложности.

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

Вот наследование как раз очень вредит инкапсуляции =)
А с масштабируемостью у такого подхода как раз лучше, расширяемость проще, меньше связей между разными частями системы и тд...
Хуже то, что объекты существуют только во время выполнения программы, это усложняет ее тестирование так как корректность программы написанную на java или С++ можно проверить до запуска, так как есть информация о типах, а программу на lua или Io для этого нужно запустить...