Допустим, есть 

Как из этого цивилизованно делается дочерний класс Child, который наследует свойства Parent так, чтобы можно было эти свойства в т.ч. дополнять. 
Т.е. внутри Child.method() вызывать Parent.method() и еще выполнять какой-то дополнительный код, а не переопределять Child.method() с нуля?

40 набла
не оно?

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

это почему же?
при написании сложных javascript-приложений без грамотного наследования не обойтись.

CruorVult, Мне приходилось использовать наследование с вызовом и переопределением методов предков только в некоторых тестовых приложениях с играми. Да и там уровень наследования был не больше 2-х, тоесть можно было обойтись и так, каким-нибудь делегированием.

imho, JS - по моим теперешним представлениям, не самостоятельный язык, а некая прослойка между юзером и сервером, вот на сервере уже полезно навернуть объектную модель просто потому что реализация плагинов через наследование от базового класса достаточно удобна и практична...

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

P.S.
Единственный случай такого применения, который я смог вообразить - создание плагинов для некоей JS библиотеки, занимающейся некими странными вещами... (что интересно такого можно делать на компе юзеа, чтобы потребовалось еще и писать плангины?   ) Но и в этом случае такой подход тащит за собой достаточно неиспользуемого(перекрытого) кода, который не очень-то желательно грузить юзеру...

ksnk, за ссылку спасибо. Читаю...

Насчет того, что где может пригодиться наследование, у меня как раз есть пример из жизни (собственно, он меня и подтолкнул к тому, чтобы завести эту тему).

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

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

Пока видится один уровень наследования, но на это не хотелось бы полагаться.

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

ksnk,  к примеру MVC на клиенте, есть класс Controller, методы которого наследуются другими классами-контроллерами. Но вообще ты прав, более чем 2-йная наследовательность редко применяется.

Это сообщение отредактировал(а) CruorVult - 16.11.2010, 11:56

CruorVult, MVC на javascript, imho - вообще мертворожденная технология. Она достаточно удобно подходит для серверных приложений, с web-серверной спецификой - множество быстроисполняющихся запросов, выдающих отформатированные данные, однако на javscript ее натягивать - мне, например, непонятно как. Все контроллеры или view'хи уже так или иначе реализованы в Dom и JS и городить специальные обертки для них только заради следования технологии MVC считаю жлобством 

Я сейчас делаю проект следующей структуры:
Серверную часть расказывать не буду, скажу только что данные клиент получает только в json.
Есть объект Controller, через который проходят все взаимодействия клиента и сервера. Любые действия на клиенте передается и обрабатывается контроллерм, который формирует нужный запрос  и отправляет на сервер(по средствами ajax-запросов),  либо выполняет другие действия над уже имеющимися данными. Когда получили ответ от сервера Controller анализирует пришедшие данные  и по ним вызываются нужные рисовальщики из объекта View. Задача была - реализовать полностью ajax-овое приложение вот и пришла в голову такая реализация.