namespace - это вроде контейнера, а publc - разрешает доступ как из других namespase-ов, так и внутри того, где объявлен?

ns- это пространство имен.. всегда открыто для доступа из других областей.




Это сообщение отредактировал(а) mes - 30.9.2009, 09:10

mes, такой вариант: поддержка ООП. То есть:
инкапсуляция -- private
наследование -- protected
public -- вроде "побочного эффекта", т.к. оба модификатора в той или иной степени запретительные

     
не понял мысли..

Добавлено через 1 минуту и 30 секунд
П.С. namespace это не class

mes, я сейчас action script3 изучаю, там вместо ns - package  и есть еще один модификатор доступа internal - для доступа только внутри пакета. появились вопросы о смысле модификаторов доступа. Сейчас в голове сложилась такая вот схема. Вроде логично объясняет смысл модификаторов (кроме internal - на это, видимо, есть нюанс виртуальной машины flash'a). 

класс предоставляет клиенту набор услуг. этот набор содержится в его public части

ага, упустил из виду. Не знаю, как у Старуструпа, но в вики нашел определение, что это не только сокрытие, но и предоставление интерфейса.
Тогда получается, что инкапсуляцию обеспечивают private и public. Прямо как инь и янь
А наследование -- protected.

Gunslinger, я не понимаю о чём ты говоришь. давай разбираться.

"это" - это что?

каким образом public обеспечивает инкапсуляцию?

zim22, про инкапсуляцию говорю. Вот: "Инкапсуля́ция — свойство языка программирования, позволяющее объединить данные и код в объект и скрыть реализацию объекта от пользователя. При этом пользователю предоставляется только спецификация (интерфейс) объекта." У с++ по умолчанию private, поэтому нужно еще обеспечить доступ - вот тебе public.

по-умолчанию private для классов(class), public для структур(struct).
***
так в чём проблема? я так и не понял... 

Это сообщение отредактировал(а) zim22 - 30.9.2009, 11:15

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

такого не бывает. почитай книги по "объектно-ориентированному анализу/проектированию".

я сейчас читаю "Объектно-ориентированный анализ и проектирование с примерами приложений." 3 издание. Гради Буч. 
но я очень не рекомендую повторять мою ошибку. русский перевод просто кишит неточностями/ошибками перевода. есть смысл подождать исправленную версию.

след.книгу, которую я буду читать называется "Применение UML и шаблонов проектирования". Ларман. её и рекомендую 

в С++, в отличие от более поздних языков, нет модификаторов доступа для неймспесов, только для классов
то есть ты не можешь с помощью какого-то ключевого слова открыть функцию класса только для классов из данного неймспейса

  Кролик - это не только ценный мех, но и пол-кило легкоуваяемого мяса.
Жуть, не читайте Вики на ночь, а то еще приснится ненароком   
Ни private ни public и ни protected не имеют отношения ни к инкапсуляции ни к наследованию. (Хотя public/private еще можно к инкапсуляции за уши притянуть, но лучше не надо - ушей жалко   )

Ощущение такое, как-будто чел знает какой-то язык, и пытается провести параллель. Или еще что-то...

т.е. они - не следствие введения ООП, а следствие увеличения ошибок в коде из-за усложняющихся проектов?


это тоже есть.

Добавлено через 2 минуты и 41 секунду

ок. повтыкаю как время будет

Они - особенности реализации языка С++. Имеют отдаленное отношение к инкапсуляции (позволяют скрыть детали реализации от пользователя класса)
Возможны и другие методы реализации инкапсуляции

xvr, что значит особенности? "Мы так захотели" или "На то были причины"?

Я об этом же. В результате напоминания zim22 пришел к выводу, что модификаторы доступа - не часть ООП, а следствие ООП, так сказать его поддержка. Т.е. эволюционный процесс: программы разрастались, взаимосвязи усложнялись. В итоге придумали ООП. Разрабатывать и писать стало проще, однако человеческий фактор никуда не делся: изменение значений переменных чужих объектов, в результате - их некорректная работа. Так же с доступами к чужим наследникам и наследников друг к другу.


Это сообщение отредактировал(а) Gunslinger - 30.9.2009, 18:17

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

я отношу модификаторы доступа именно к этому. Я понимаю?

mes, я не пойму, я непонятно написал перед твоим постом или ты не читал?

Скорее 'так получилось'   

читал, и  именно поэтому написал ниже пост. 



Пост писался, не для уточнения того, что модификаторы относятся к реализации, а то что  реализации "одного и того же" ООП могут очень сильно различаться.
Это связано как с особенностями самого языка, так и со взглядом авторов на ООП, быть может есть еще и другие причины.


Я так понял, что Вы говорите, что вначале внедрили ООП в язык, а потом, вследствии людского фактора, добавили туда модификаторы доступа.
хотя в принципе и отражает реальность, но мне кажется потеряна суть происходившего.
имхо лучше так : было известно что надо добиться инкапсуляции объекта, но в связи с особенностями C++ решили для достижения этой и некоторых других целей, использовать модификаторы доступа.
Вполне могли поступить по-другому, например, считать все содержимое класса приватным, а доступность открывалась бы через интерфейсы.

P.S. вышесказанное приведено в грубом упрощении. 

Это сообщение отредактировал(а) mes - 30.9.2009, 20:51

Да, именно так. Далее вы привели еще один вариант. В итоге получилось 2 хронологических варианта:
1. Модификаторы ввели после ООП, для уменьшения ошибок доступа.
2. Модификаторы ввели вместе с ООП. Как я понял по вашему предположению - для поддержки реализации ООП.

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

Это сообщение отредактировал(а) Gunslinger - 1.10.2009, 08:24

Есть еще третий вариант,  модификаторы появились до того, как язык получил более менее полную подержку ООП 


Бьерн Страуструп - Дизайн и Эволюция C++
  

про первое появление модификаторов есть?

Ну смотря что именно подразумевать под этим вопросом- там в общих чертах, расказывается почему выбрана такая модель защиты..

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


Это сообщение отредактировал(а) mes - 1.10.2009, 11:33

То есть модификаторы все-таки не следствие ООП (вариант 1)? Вы про предшественник с++ говорите?

Да, прообразом "C++" послужил "С с классами"


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



Это сообщение отредактировал(а) mes - 2.10.2009, 11:55

mes, теперь понятно. Спасибо.
Всем спасибо, вопрос решен.