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

Приведите пожалуйста несколько примеров задач, где потребуется многократное(частое) использование наследования. Как много может быть классов в среднем в ваших программах ? Каков хотя-бы порядок, 10, 50, 100 ?
Подскажите пожалуйста книгу с теоретическими аспектами объектно-ориентированного программирования. Что касается реализации меня полностью устраивает автор упомянутый выше, BS и стандарт.


PS
Что вы используется для построения диаграмм между классами ?

Dima TСамый универсальный пример применения наследования: графические интерфейсы (окошки, контролы и т.д. и т.п.)

В остальном у меня "программирование с использованием классов".

Спасибо :)
Графические интерфейсы не очень интересны :(

Спасибо, я посмотрю эту книгу

wstМне кажется или вопрос опять звучит как "вот явление, я хочу его называть так"? То есть наверняка есть какие-то определения, близкие к тому, чтобы считаться общепринятыми, но в отличие от математики знание определений настолько глобальных вещей разработке помогает крайне редко. Ни одна задача (кроме учебных где явно прописано требование ООП) этого самого ООП не требует для решения в обязательном порядке, то же можно сказать и просто о наследовании.
К тому же некоторые формулировки исходного вопроса вроде "а есть только программирование с использованием классов" выглядят так, будто предполагают определенную ущербность подобного подхода по сравению с неким ООП-стилем, причем без доказательства или хотя бы обоснования.
По классам - у меня выходят сотни если Java (практически на любой чих), 2-5 если С++ (ибо бизнес логика ниже js/python/java не опускается).

P.S. Если уж на то пошло, то "квадрат, ромб и прямоугольник" - давняя дисциплина специальной олимпиады в разрезе кто от кого происходит и пример почему не стоит слишком уж заморачиваться с ООП ради ООП.

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

PS
А Java тут не авторитет/пример. Сколько классов потребуется(и будет задействовано) чтобы написать программу с выводом любого сообщения на какой-нибудь поток? Сколько классов потребуется чтобы написать программу факторизации? Думаю 0 и 1 не будут ответами ни на один из этих вопросов.

MasterZiv Традиционный пример -- любая графика. Рисунки граф. примитивов. Граф.объект, четырёхугольник, трапеция, ромб, прямоугольник, квадрат.
(причём уже тут --множественное наследование, квадрат -- и ромб, и прямоугольник)


ну вот.. Я думал что должно быть что-то ещё..

maytonБизнес-сущности. Плательщик. Платёж. Услуга. Традиционно их описание лежало в БД.

А где в данном примере будет наследование ?

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

Зимаргл Абстрактная теория годится только для хелловорлдов.

а потом у нас спутники падают, или что-то там упало год назад. Без понимания теории невозможно программировать качественно, и это не я говорю(хотя и сам так считаю), это говорит BS, и Павловская, например. Да и не только они