Собственно, обращаюсь к знающим людям, поскольку еще на первых порах с С++ не могу понять краеугольные камни ООП.
И так, допустим, имеем базовый класс :

выводим из него производный класс:

А теперь внимание вопросы:
1.имеется ли доступ к private-членам базового класса из производного?
2.если производный класс наследуется как private, то public-члены базового становятся недоступными для производного и становятся его public членами? например член priv (тот, что в секции private объявлен базового класса) в классе derived будет приравнен к его public-членам и будет виден в дальнейшей иерархии классов?
3.Доступ к protected-членам имеется во всей иерархии классов (допустим base->derived1->derived3->derivedN, в этом самом N я могу использовать protected члены базового класса?)?


4. Правильно ли я понимаю, что в методах производного класса могу использовать методы базового класса?
прим:

Нет
Нет. При private наследовании члены public и protected из родительского класса станут private для наследника, и их ни в каких дальнейших наследниках уже использовать не удасться
Да. (Хотя есть нюансы)

Да, но только те, которые доступны (public и protected)

Спасибо.

только к ООП это имеет мягко говоря слаааааабое отношение...

ООП - Объектно Ориентированное Проектирование. Заметьте, проектирование. Т.е. до программирования как до китая ползком на карачках вперёд попой... на каком языке реализовывать - дело двадцать пятое. Более того скажу - если Вы воспринимаете решение задач как абстрактные рассуждения о классах - то это тупик. Рекомендую почитать одного из основоположников данной технологии решения задач - Гради Буча. Всё доходчиво, и понятно. Именно отвечает на впрос "как перейти от задачи к программированию".

удачи вам
(круглый)

Возможно автору будет полезная эта ссылка http://alenacpp.blogspot.com/2006/03/blog-post_11.html

Спросил у гугла. Ни одного слова "проектирование" на странице нету.

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

А если без далее:ООП.
Термин О.О. проектирование тоже существует...

Только «там» применяется в виде OOD (o. o. design), а «тут» многие не переводят «design» как «проектирование», а так «дизайн» и говорят.

ООП - устоявшийся термин и в 99% случаев однозначно определяет именно программирование. Объектно-ориентированное проектирование тоже имеет место (как часть процесса программирования), но никогда нигде не встречал, чтобы его обозначали аббревиатурой ООП.

(устало) Вы наверное и ООА не в курсе что это такое???

устоялось у кого? У людей которые никогда книги основоположников ОбъектноОриентированной методики не читали? да это повсеместно есть к сожалению. это как в забытые времена всё что связывалось по сети обзывалось клиент-серверным )) типа, хорошая клиент-серверная программа питер нортон. Замечательно юзает файловую службу сервиса.. ага... ))


удачи вам
(круглый)
ЗЫ
Собственно бох с ними с терминами. Главное желание бы ло бы докапыватся до истины... ))





Вы просто не умеете их готовить...

Гради Буч


Это собственно один из основателей. Рекомендую почитать, и стэп бай стэп хоть ОДИН раз применить. Особенно очень актуально , если разработка ведётся более чем одним разработчиком. Эта методика единственная на сегоднешний момент времени(поправте если есть у вас другая инфа) которая даёт ответ на вопрос, а как собственно перейти от конкретной задаче к коду. Вот именно это она и описывает. А какой язык применять после всего этого - дело двадцать пятое. я например частенько юзаю и азм в частности. могу и си бимоль, могу и плас-плас или скажем фортран..смотря по задаче собственно говоря... Если Вы видите связь ОО только с наследием, полиморфностью и иже терминами - то увы это ОЧЕНЬ маааааааленькая часть всего пирога...


удачи вам
(круглый)

Сообщение отредактировал kolobok0 - May 12 2012, 10:05

Ещё какие термины знаете, не относящиеся к делу? А устали - отдохните.


Читали, читали, не вы один грамотный.



А это-то тут причём? Поток сознания какой-то, извините.


Да, никто не умеет, один вы являетесь, судя по всему, уникальным носителем сакральных знаний.


К Бучу не надо отсылать, этот источник был изучен ещё лет 12 назад. Объектно-ориентированное программирование и средства его поддержки появились задолго до этого труда Г.Буча. Собственно, заслуга Г.Буча в том, что он изложил тему с акцентом на этап проектирования, показал методологию. И анализ, и проектирование являются составной частью процесса программирования, которое помимо этого включает в себя и другие части (другие парадигмы, кодирование и т.п.).

"к делу" оно (ООА) относится наипервейшим образом. потому как всегда впереди на лихом коне. потому как Анализ. Возможно вы не так это понимаете, но хотите вы этого или нет - перед тем как приступить к программированию ВСЕГДА идёт анализ. Он может быть молнеиносным (типа о! знаю как. особенно если в одной голове). Он может быть по уму (например в группе единомышленников - создаются сущности и проигрываются их роли, взаимодействия и т.д. и т.п.). Это может быть по глупому - а нахрена тут думать - пилить надо. Хватить фигнёй страдать!!! Ну и когда челолвек десять потом чертыхаясь: ну и кто эту фигню писал?! как вызвать у парента метод гав? давайте всё начнём заново! или я не буду это юзать, потому как!!! и т.д. (проблемы которые усиливаются при этом - много. можем кстати и про поговорить, если хотите).. Это кстати практически во всех конторах есть. и к сожалению лично я видел единицы фирм по производству софта. всем остальным при случае говорил мягко - это не ваш бизнес... не мучьте ся и пользователей... а пользователей, лично мне очень жалко кстати.. они просто не видят хорошего софта зачастую...оно конечно же даёт бонусы - не привередлив клиент, но как в том мультике: везение, везением - но надо жешь и уметь!


да бох с вами. я с удовольствием расскажу, покажу если есть желание. более того - готов всегда! (як пионэр) к диалогу. к любому...


вот вы же принципиально со мной согласны если так говорите! или очепятались? кстати он один из авторов(возможно и только он - щас уже не помню) - UML. Рэйшенел Роуз думаю знаете...

удачи вам
(круглый)

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

довольно грубо, причем kolobok0 тут не прав. имхо.
+1. Как говориться, без комментариев.

встретив..... допустим незнакомую аббревиатуру "ООП" не спеши в гугл вбивать "ООП", вбивай "гради буч объектно-ориентированный анализ и проектирование"
*ЗАПЕСАЛ*

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

Этта пять!