folk,
>> На C++ легче организовать сокрытие данных (вообще-то это вовсе не эквивалентно инкапсуляции, но на этом можно сейчас не останавливаться). Но это вовсе не означает, что сокрытие данных будет практически более эффективно, чем в C.
> На этом нужно остановиться чтобы понять что такое инкапсуляция. Что понимается под сокрытием данных? Это то же самое что и сокрытие информации?
Да, то же самое. Во всяком случае, я на момент написания процитированного сообщения между data hiding и information hiding никакой разницы не подразумевал.
Не горя желанием участвовать в очередном обсуждении терминологии, которое, похоже, сейчас завяжется, хочу только заметить, что некоторые из предыдущих сообщений под сокрытием данных/информации подразумевали сокрытие таковых от глаз человека (это можно увидеть из упоминаний возможности глянуть на переменные, объявленные в секции private). В то время, как для данной дискуссии это совершенно не должно иметь значения, т.к. при обсуждении инкапсуляции и/или сокрытия данных/информации речь идет о возможности получения доступа к "внутренним" структурам с помощью средств языка, в то время как возможность их изучения человеком остается, фактически, всегда.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, Шахтер, Вы писали:
Ш>>Здравствуйте, AndreyFedotov, Вы писали:
AF>>>Здравствуйте, Павел Кузнецов, Вы писали:
AF>>> И всё-таки код не эквивалентен. Действуя по правилам языка — я могу использовать указатель на структуру, что бы получить или изменить значение переменной.
Ш>>Не можешь -- ты не видишь определение структуры, оно скрыто в файле реализации.
AF> Да, так можно поступить — но тогда мигом получаем другие грабли — нет проверки указателей, и элементарно подсунуть вместо одного типа — другой.
Почему же это её нет? Вместо одного типа другой ты не подсунешь.
AF>Что в случае C++ элементарно было бы выловлено на этапе компиляции. AF> Кроме того — сути дела это не меняет — инкапсуляция всё-равно только по соглашению.
Нет, по реализации.
AF>В том же модуле — где расположена структура — все равно элементарно можно получить доступ к содержимому объекта напрямую,
По-моему, ничего страшного нет в том что реализация класса потребит один файл.
AF>а плодить по паре файлов на каждый тип — накладно.
В каком смысле накладно -- по числу файлов что ли? Я не думаю, что тут можно говорить о накладности.
AF> Да и потом — никто и не отрицает возможности инкапсуляции на C — речь идёт только о накладных расходах на неё.
Ну положим, о накладных расходах тут говорить смешно. Другое дело -- удобство.
AF>Так же, как и в случае с ассемблером.
AndreyFedotov:
> ПК> Это в теории. На практике можно наблюдать, что многие библиотеки и API, написанные на C, лучше скрывают детали своей реализации, чем аналогичные библиотеки и API на C++.
> <...>
> ПК>Попробуй, например, доступиться к внутренним структурам Windows — вряд ли это получится сделать легко: Win API достаточно хорошо изолирует тебя от внутренних деталей. А теперь давай посмотрим, скажем, на MFC... Много переменных-членов public, protected, не говоря уже о различных "внутренних" функциях с доступом public, включенных в интерфейс класса просто потому что они нужны самой MFC.
> Сравнение не корректно. Команда, которая делала API Windows — была на несколько порядков опытнее <...>
Я с этим не спорю. Я только привел пример того, что на C вполне возможно писать, не выпячивая детали реализации наружу; плюс пример того, что на C++ инкапсуляция автоматически "сама собой" тоже не возникает. Именно квалификация разработчиков, с моей точки зрения, и определяет "степень инкапсулированности" того, что получится в результате. И именно поэтому я скептически отношусь к заявлениям, скажем, о "большем совершенстве С+ с точки зрения инкапсуляции".
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Я с этим не спорю. Я только привел пример того, что на C вполне возможно писать, не выпячивая детали реализации наружу; плюс пример того, что на C++ инкапсуляция автоматически "сама собой" тоже не возникает. Именно квалификация разработчиков, с моей точки зрения, и определяет "степень инкапсулированности" того, что получится в результате.
Абсолютно согласен.
ПК>И именно поэтому я скептически отношусь к заявлениям, скажем, о "большем совершенстве С+ с точки зрения инкапсуляции".
А вот тут замечу — что речь идёт не о возможностях наделать ошибок (в том числе и с инкапсуляцией), а о потенциале языка — т.е. лёгкости, удобству, возможностях — писать с учётом инкапсуляции. Вот с этой точки зрения C++/C#/Jaba — явно опережают C. Это конечно не подразумевает, что весь софт, написанный на этих языках лучше с точки зрения инкапсуляции, но всего лишь то, что есть возможность его написать и есть написанный софт с прекрасной инкапсуляцией, при том реализация её средствами языка далась проще, чем она обошлась бы на C.
Так что в общем-то исходная посылка, с которой началась ветка, верна — в том смысле, что языки, на которые перещли разработчики за последние 10-15 лет действительно удобнее с точки зрения инкапсуляции. Но от себя добавлю — подавляющее большинство перешло на эти языки из-за чего угодно другого — только не из-за инкапсуляции. Что вобщем-то не помешало им осознать преимущества инкапсуляции позже. Так что можно смело сказать — что перешли они на языки с более удобной поддержкой инкапсуляции незаметно для себя.
Инкапсуляция это все и процедурный подход, ООП, компонентно ориентированное пр., АОП.
А инкапсуляция на уровне классов в языках это слабенькая инкапсуляция.
Сильная инкапсуляция это например у InternetExplorer или у Word'a. CreateApplication, и ковыряем Application через интерфейсы.
А на уровне исходников как не крути но с первой попытки исходники не всегда и работать будут — зависит от опций компилятора итд.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2:
>> Да шишники вот уже 35 лет слона не замечают. Хотя не все. Многие просто чисто интиуитивно переползают на более совершенные с точки зрения инкапсуляции языки вроде С++, Явы, Шарпа...
ПК>Интересно... А в чем, по-твоему, большее совершенство, скажем, C++ по сравнению c С с точки зрения инкапсуляции? Можно примерчик?
Внесу и свои пять копеек в развитие флэйма .
Господа, вы воюете с ветряными мельницами. Практически любой язык включает средства для достижения инкапсуляции. Но одни языки поддерживают их явно (C++), а в других она достигается за счёт дополнительных средств (C). C++, С#, Java — это не показатели идеала и совершенства инкапсуляции. Вы знаете, что наиболее мощная поддержка инкапсуляция характерна для объектных (не путать с объектно-ориентированными) и процедурных языков? Пример? Пожалуйста: Turbo Pascal, инкапсуляция достигается за счёт помещения реализации внутрь специфичного бинарного модуля (с расширением tpu — помните?), во вне смотрит только интерфейс этого модуля, получить доступ к реализации вы не можете никаким способом и это штатные средства, поддерживаемые языком.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, folk, Вы писали:
F>Да еще мой OE иногда загадочно перетасовывает дерево сообщений.
Дык Янус юзать надо.
F>Хотелось показать, что для кода, использующего полиморфный тип, реализация тоже скрыта.
Зависит от реализации. Наверно в общем случае это так, но в общем...
F> И скрыта по объективным причинам, а не потому что хочется безопасности или легкости изменений в реализации. Разве это не справедливо для ФЯ?
Да в ФЯ как раз зачастую присуствует полиморфизм и отсуствует инкапсуляция. Многие ФЯ даже определение типов данных не поддерживают. Взять хотя бы Лисп.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это в теории. На практике можно наблюдать, что многие библиотеки и API, написанные на C, лучше скрывают детали своей реализации, чем аналогичные библиотеки и API на C++.
На практике то же ВыньАпи хэширует хэндлы и использует внутренние таблицы только ради того, чтобы разные умники не вычисляли адреса из хэндлов.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mr. None, Вы писали:
MN> Пожалуйста: Turbo Pascal, инкапсуляция достигается за счёт помещения реализации внутрь специфичного бинарного модуля (с расширением tpu — помните?), во вне смотрит только интерфейс этого модуля, получить доступ к реализации вы не можете никаким способом и это штатные средства, поддерживаемые языком.
Вот именно. Модуль — единица инкапсуляции. И только такая инкапсуляция может быть настоящей. Инкапсуляция на уровне класса с помощью private/protected/public — на самом деле ничего не инкапсулирует, так как все-равно все всем остается видно.
Здравствуйте, Сергей Губанов, Вы писали:
MN>> Пожалуйста: Turbo Pascal, инкапсуляция достигается за счёт помещения реализации внутрь специфичного бинарного модуля (с расширением tpu — помните?), во вне смотрит только интерфейс этого модуля, получить доступ к реализации вы не можете никаким способом и это штатные средства, поддерживаемые языком.
СГ>Вот именно. Модуль — единица инкапсуляции. И только такая инкапсуляция может быть настоящей. Инкапсуляция на уровне класса с помощью private/protected/public — на самом деле ничего не инкапсулирует, так как все-равно все всем остается видно.
Ну и чего? Много видно-то?
С чем я согласен так это с тем что интерфейс к модулю действительно должен быть двоичным. Так проще и удобнее, но с другой стороны у плюсовых хидеров пока есть очень мощное преимущестово в виде инлайнгнвых функций:
class Foo
{
void everything_get( const char *name, void *out );
public:
int foo_get() { int x; everything_get("foo",&x); return x; }
};
Пример слекга надуман но тем не менее, показывает что одна функция может сидеть в классе в DLL и юзатся челой толпой инлайновых хелперов. Повышает производительность однако.
Здравствуйте, folk, Вы писали:
F>Павел Кузнецов:
>> На C++ легче организовать сокрытие данных (вообще-то это вовсе не эквивалентно инкапсуляции, но на этом можно сейчас не останавливаться). Но это вовсе не означает, что сокрытие данных будет практически более эффективно, чем в C.
F>На этом нужно остановиться чтобы понять что такое инкапсуляция. Что понимается под сокрытием данных? Это то же самое что и сокрытие информации?
Инкапсуляция = абстрактный тип данных. С другого конца надо подходить. Тип данных, который определяется набором операций над ним а не структурой. Отличие инкапсуляции в языке С и С++ состоит в том, что абстрактный тип данных (класс) является типом в С++ (со всеми вытекающими — например компилятор обеспечивает контроль и приведение типов), но не является типом в С, где подобная вещь реализуется на уровне соглашений (опять же со всеми вытекающими).
Таким образом, инкапсуляция не поддерживается в С на уровне языка. Хорошо это, или плохо? Вопрос не в том, где лучше и надежнее скрываются данные, меня, например, это волнует мало. А вот то, что ADT не является типом с точки зрения языка — это крайне неудобно.
Здравствуйте, Gaperton, Вы писали:
G>Таким образом, инкапсуляция не поддерживается в С на уровне языка. Хорошо это, или плохо? Вопрос не в том, где лучше и надежнее скрываются данные, меня, например, это волнует мало. А вот то, что ADT не является типом с точки зрения языка — это крайне неудобно.
Особенно в случае языка С — там и так контроль типов слабый по самое небалуйся, считай переносимый ассемблер. Что и подтверждается практикой его применения.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Да: ПК>
ПК>> Интересно... А в чем, по-твоему, большее совершенство, скажем, C++ по сравнению c С с точки зрения инкапсуляции?
ПК>Она в нем есть.
Ну, то очередное передергивание. Из примера совершенно понятно, что я имел в виду.
>> Скажи, ты считашь этот код таким же простым как и приведенный мной?
ПК>Нет. Но в реальных приложениях это имеет весьма небольшое значение. Я с тобой согласен в отношении того, что в C++ легче сокрыть данные, чем в C. Но, к своему сожалению, я часто замечаю, что практически интерфейсы на C более инкапсулированы, чем интерфейсы на C++.
Это общая философия. С тем же успехом могу скзать, что ты просто слишком мало видел С-шного кода. Я начинал программировать когда плюсов еще небыло и даже когда они появились один фиг распространение у них было не сильное. Так вот я очень хорошо насмотрелся на примеры лобового программирования на С.
Да что там далего ходить. Изучи АПИ TreeView/ListView. Все эти LVITEM с значениями задаваемыми масками — это кривейший дизайн приводящий к ужаснешим последствиям. А вот С++-ные обертки к ним очень даже ничего. Так что все зависит от конкретных людей. С++ хотя бы пропагандирует инкапсуляцию. А С это понятие даже не офишировалось. Я не помню ни единого упоминания этого слова у того же Кернигана.
ПК>Если говорить о C++, то, несмотря на то, что "легальными" средствами получить доступ к private части класса нельзя, реально это делается совсем не сложно. Даже легче, чем в коде на C, приведенном выше, т.к. описание класса уже находится в заголовочном файле, и большинство модификаций оригинального кода не будет требовать исправлений в коде пользователя.
Ну, С++ я никогда не считал идеалом.
>> Паш, я устал от демагогии льющейся, с твоей стороны в мой адрес, в последнее время все больше и больше.
ПК>Наверное, мы просто стали чаще бывать в одних и тех же форумах
У тебя забавная манера уточнять. Что бы удовлетворить твои "просьбы" приходится делать кучу нежелательной работы. Причем совершенно не ясно ради чего.
ПК>т.к. никакого особого совершенства C++ в отношении обеспечения инкапсуляции по сравнению с C я реально не наблюдаю.
А это чьи слова:
Я с тобой согласен в отношении того, что в C++ легче сокрыть данные, чем в C.
Нельзя одновременно быть согласным и несогласным. Более того. Совершенно не ясно зачем постоянно пытаться требовать от других обоснований всего подряд. Обоснование столь очевидных и безабидных слов вряд ли можно требовать без каких-то целей. Захотелось что-то сказать? Так скажи не докапываясь к другим и не требуя от них что-то. Ты уж извени, но с каждым новым "требованием" все больше и больше хочется послать куда подальше. Ну, просто по человечески надоело.
ПК> По моему опыту скорее даже наоборот: т.к. "простых" средств для сокрытия данных в C нет, то если кому-то хочется это оганизовать, он вынужден использовать более радикальные подходы, чем в C++, соответственно, получая более эффективные в отношении сокрытия реализации результаты.
Ну, что я тебе могу сказать. Ну, недостаточный значит у тебя опыт. Поглидел бы на реальные системы написанные на С, никогда бы такого не сказал. Ты делаешь свои выводы на базе АПИ от иминитых контор, которые вынуждены использовать С и вынуждены уделять большое внимание инкапсуляции, так как иначе им прийдется поддерживать совместимость на уровне внутренних структур (что неприемлемо для продуктов вроде ОС). Но на С писали не только публичные АПИ к ОС и т.п.
И вообще, все это не относится к делу. Я как бы вообще не делал заявлений о невозможности. Я сказал, то что сказал. А ты начинаешь домысливать и боросться с выводами созданными на этих домыслвах. Я не знаю делаш ли ты это нарочно, но как не крути — это банальный демогогический прием. И если это действительно не нарочно, то просто постарайся так не делать.
ПК>P.S. Тебе больше нравиться переходить к разборкам вместо того, чтобы ограничиться простым ответом на заданный вопрос?
Паш, с демагогией можно боросться только двумя методами:
1. Останавливать ее.
2. Отвечать той же "монетей", но в более более "громко".
Отвечать на явно демагогические вопросы означает идти на поводу у демагогии. Вернись еще раз к своему вопросу и попробуй ответить на вопрос зачем ты задал этот вопрос? Ну, а в следующий раз когда захочешь что-то скзать, то просто говори, а не пытайся поймать кого-то на чем-то и потом высасывать из пальца строчки вроде:
Отчего же, он вполне хорошо проиллюстрировал твою позицию, здорово сэкономив нам время на ненужной риторике. Как видишь, C вполне позволяет писать код, эквивалентный в отношении инкапсуляции коду на C++. Скажем, та же Win API в этом отношении вполне в порядке.
на слова вроде:
Многие просто чисто интиуитивно переползают на более совершенные с точки зрения инкапсуляции языки вроде С++, Явы, Шарпа...
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jedi, Вы писали:
J>ИМХО, Вы перепутали Божий дар с яичницей . J>Инкапсуляция — это один из методов грамотного проектирования, позволяющий снизить связанность между компонентами из которых строится система.
Ничего он не перепутал. Просто действительно средства инкапсуляции во многих современных ООЯ слишком легко обходятся. Те же менеджед-среды вроде дотнета как раз демонстрируют, что это всего лишь проблемы реализации. В дотнете получить доступ к закрытым членам очень не просто. Более того он контролируется защитой рантайм-подсистемы. Так что безопасность и инкапсуляция вещи слабо связанные только в средах прошлого поколения. В будущем они будут практически не отделимы.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Я с этим не спорю. Я только привел пример того, что на C вполне возможно писать, не выпячивая детали реализации наружу; плюс пример того, что на C++ инкапсуляция автоматически "сама собой" тоже не возникает.
Осталось выяснить зачем?
ПК> Именно квалификация разработчиков, с моей точки зрения, и определяет "степень инкапсулированности" того, что получится в результате.
Ну, сказал бы это. С тобой даже бы и спорить никто не стал бы.
ПК> И именно поэтому я скептически отношусь к заявлениям, скажем, о "большем совершенстве С+ с точки зрения инкапсуляции".
Ты как бы даже согласился с этим мнением. Напомнить где? У тебя тут явно какие-то логические проблемы. Ты признашь, что ООЯ обладают более совершенными средствами инкапсуляции, но в то же время пыташся поборосться с ками-то вертрянными мельницами. Странно это.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Да, то же самое. Во всяком случае, я на момент написания процитированного сообщения между data hiding и information hiding никакой разницы не подразумевал.
Вообще-то говорить о данных тут не очень умесно. Инкапсуляция — это механизм абстракции, т.е. средство сокрытие лишних (для восприяти и управления) сведений. А не просто скрытие данных. Скрывать данные просто так глупо. К тому же инкапсуляция это не всегда скрытие данных. Это так же (и я даже бы сказал, сокорее) наложение правил на эти данные. Суть этих правил заставить тип работать как модель некого объекта. Остальное фигня.
Что же касается инкапсуляции и С. Ну, замени инкапсуляцию на любой другой принцип ООП и окажется, что подобные тирады можно быдет высказать о любом из них. Все можно эмулировать на С. Вот только неудобно. И именно по этому разумные люди чисто интуитивно... ну, короче ты понял.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
. Чуть ли не через слово спорные утверждения, а ты что-то не споришь. Так стоило ли докапываться до утвреждений которым ты и противопоставить то ничего не можешь?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jedi, Вы писали:
J>>ИМХО, Вы перепутали Божий дар с яичницей . J>>Инкапсуляция — это один из методов грамотного проектирования, позволяющий снизить связанность между компонентами из которых строится система.
VD>Ничего он не перепутал. Просто действительно средства инкапсуляции во многих современных ООЯ слишком легко обходятся. Те же менеджед-среды вроде дотнета как раз демонстрируют, что это всего лишь проблемы реализации. В дотнете получить доступ к закрытым членам очень не просто. Более того он контролируется защитой рантайм-подсистемы. Так что безопасность и инкапсуляция вещи слабо связанные только в средах прошлого поколения. В будущем они будут практически не отделимы.
Это конечно все верно, особенно точ то дотнет рулит Но вот объясните мне, убогому умом, ЗАЧЕМ нужна ТАКАЯ инкапсуляция? Что аппаратная (или рантайм) защита приватных данных делает хороший дизайн еще более хорошим? Ну не можешь ты писать в чужую память и все этого достаточно для защиты, причем тут вообще инкапсуляция? От ЧЕГО Вы защищаетесь таким способом?
Спасибо заранее.
VladD2,
> ПК> И именно поэтому я скептически отношусь к заявлениям, скажем, о "большем совершенстве С+ с точки зрения инкапсуляции".
> Ты как бы даже согласился с этим мнением. Напомнить где?
Ага, сделай одолжение
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК> Да, то же самое. Во всяком случае, я на момент написания процитированного сообщения между data hiding и information hiding никакой разницы не подразумевал.
> Вообще-то говорить о данных тут не очень умесно. <...>
data hiding — это термин не более того. Используется взаимозаменяемо с information hiding.
> Ну, замени инкапсуляцию на любой другой принцип ООП
Инкапсуляция существует и за рамками ООП. Это, вообще, более-менее общий термин, ООП не ограничивающийся.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Действуя по правилам языка — я могу использовать указатель на структуру, что бы получить или изменить значение переменной. 
.
