<... переходы на обсуждение личности оппонента опущены ...>
> ПК> т.к. никакого особого совершенства C++ в отношении обеспечения инкапсуляции по сравнению с C я реально не наблюдаю.
> А это чьи слова: >
Я с тобой согласен в отношении того, что в C++ легче сокрыть данные, чем в C.
"Легче" != "лучше". Разговоры о большем совершенстве у меня ассоциируются именно со вторым.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, jedi, Вы писали:
J>Это конечно все верно, особенно точ то дотнет рулит Но вот объясните мне, убогому умом, ЗАЧЕМ нужна ТАКАЯ инкапсуляция? Что аппаратная (или рантайм) защита приватных данных делает хороший дизайн еще более хорошим? Ну не можешь ты писать в чужую память и все этого достаточно для защиты, причем тут вообще инкапсуляция? От ЧЕГО Вы защищаетесь таким способом? J>Спасибо заранее.
Что значит не можешь писать в чужую память? Каждый плевок в отдельный процесс не засунуть. Так что очень даже можешь. Сенгодня "чужой" код может быть везде.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Что значит не можешь писать в чужую память? Каждый плевок в отдельный процесс не засунуть. Так что очень даже можешь. Сенгодня "чужой" код может быть везде.
Приехали... Начали с инкапсуляции — пришли к чужому коду.
Как чужой код может вызывать Ваши классы о существовании которых он ничего не знает? (О Reflection лекции просьба не читать). Или Вы боитесь такой ситуации: Вы реализуете какой-то интерфейс и передаете его куда-то в third-party компонент, а он негодяй давай быстро менять Ваши приватные поля. Ай-яй-яй... Бред.
Ответьте на вопрос какое отношение этот имеет к ИНКАПСУЛЯЦИИ.
И где там согласие с "большем совершенстве С+ с точки зрения инкапсуляции"? То что на C++ легче организовать сокрытие данных/информации еще не означает, что получающийся результат лучше, чем то, что делается на C. В общем, все упирается в определение, что же такое "большее совершенство с точки зрения инкапсуляции".
Я был не согласен, подразумевая под "большим совершенством" получение "лучшей" инкапсуляции в результате. И в такой трактовке не соглашусь и сейчас.
Если же ты вкладывал в эти слова наличие в C++/Java/C# больших средств для обеспечения инкапсуляции, то да, я с такой поправкой согласен.
Только я не уверен, что это является причиной того, почему люди "переползают" (если вообще "переползают") c C на эти языки. Впрочем, имхо, тут сложно что-то определенно утверждать без проведения полноценного исследования.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Я с тобой согласен в отношении того, что в C++ легче сокрыть данные, чем в C.
> ПК>"Легче" != "лучше". Разговоры о большем совершенстве у меня ассоциируются именно со вторым.
> А я говорил о качестве инкапсуляции?
Ты сказал о "большем совершенстве"; что под этим понимать — Поэтому я и задавал дополнительные вопросы.
> Еще раз напомню исходную цитату, против кторой ты возражаешь: >
Многие просто чисто интиуитивно переползают на более совершенные с точки зрения инкапсуляции языки вроде С++, Явы, Шарпа...
Чтобы не вести два параллельных разговора об одном и том же, вот ссылка на сообщение с ответом: http://rsdn.ru/forum/?mid=893414
Здравствуйте, VladD2, Вы писали:
>>> А это чьи слова: >>>
Я с тобой согласен в отношении того, что в C++ легче сокрыть данные, чем в C.
ПК>>"Легче" != "лучше". Разговоры о большем совершенстве у меня ассоциируются именно со вторым. VD>А я говорил о качестве инкапсуляции? Или то, что ее можно достичь проще — это хуже? VD>Еще раз напомню исходную цитату, против кторой ты возражаешь: VD>
Многие просто чисто интиуитивно переползают на более совершенные с точки зрения инкапсуляции языки вроде С++, Явы, Шарпа...
Изуительно. Бурные аплодисменты. Зал встаёт, сцена усыпана цветами. Блестящая демонстрация того, что совершенство не связано с качеством. Ещё раз, браво! Философы посрамлены и нервно курят в дальнем углу.
PS. От наглого редактора художественной литературы (подробности тута)
Юноша, прежде чем писать крамолу, достойную жертвенного костра, не худо бы вспомнить правила формальной логики. О русском языке для ясности умолчу. Однако рекомендую впредь чисто интуитивно переползать на более совершенные языки изложения. Коль скоро русский Вам противопоказан.
Спойте, што ли, на С#, а?
Любителей рассуждать о том, что кому позволено или не позволено рекомендовать, отправляю по вышеуказанному адресу (это если без мата, ага).
PPS. С любезного разрешения Геннадия Васильева.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Сергей Губанов, Вы писали: СГ>Вот именно. Модуль — единица инкапсуляции. И только такая инкапсуляция может быть настоящей. Инкапсуляция на уровне класса с помощью private/protected/public — на самом деле ничего не инкапсулирует, так как все-равно все всем остается видно.
Что значит "видно"? Ничего страшного, если я Оберон-модуль декомпильну и увижу все эти потрошки, заботливо спрятанные от постороннего глаза? А на досуге попробуй вызвать в .Net приватный метод другого класса. В том же модуле.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Mr. None, Вы писали:
MN>> Пожалуйста: Turbo Pascal, инкапсуляция достигается за счёт помещения реализации внутрь специфичного бинарного модуля (с расширением tpu — помните?), во вне смотрит только интерфейс этого модуля, получить доступ к реализации вы не можете никаким способом и это штатные средства, поддерживаемые языком.
СГ>Вот именно. Модуль — единица инкапсуляции. И только такая инкапсуляция может быть настоящей. Инкапсуляция на уровне класса с помощью private/protected/public — на самом деле ничего не инкапсулирует, так как все-равно все всем остается видно.
Слушайет, ну не надо выворачивать чужие слова с ног на голову и любую дискуссию сводит к рекламе Оберона! Я и паскаль-то так просто упоминул, с тем же успехом мог Алгол 60 вспомнить (просто я с ним знаком только по наслышке и не совсем уверен в его истинной модульности). Я где-нибудь сказал, что private/protected/public ничего не инкапсулирует? По-моему, как раз наоборот, читай внимательно: "Практически любой язык включает средства для достижения инкапсуляции. Но одни языки поддерживают их явно (C++), а в других она достигается за счёт дополнительных средств (C)."
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Павел Кузнецов, Вы писали:
>> А я говорил о качестве инкапсуляции?
ПК>Ты сказал о "большем совершенстве"; что под этим понимать — Поэтому я и задавал дополнительные вопросы.
Большее совершенство языка означает ровно одно — то что свои задачи язык решает лучше. А задача языка — облегчить написание программ. Отсюда совершенный язык позволяет лешче реализовать необходимые задачи. Соотв. более совершенный язык с точки зрения инкапсуляции позволяет легче и проще эту инкапсуляцию реализовать. А качество инкапсуляции — оно от языка слабо зависит, оно зависит от рантайма.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, VladD2, Вы писали:
>>>> А это чьи слова: >>>>
Я с тобой согласен в отношении того, что в C++ легче сокрыть данные, чем в C.
ПК>>>"Легче" != "лучше". Разговоры о большем совершенстве у меня ассоциируются именно со вторым. VD>>А я говорил о качестве инкапсуляции? Или то, что ее можно достичь проще — это хуже? VD>>Еще раз напомню исходную цитату, против кторой ты возражаешь: VD>>
Многие просто чисто интиуитивно переползают на более совершенные с точки зрения инкапсуляции языки вроде С++, Явы, Шарпа...
ГВ>Изуительно. Бурные аплодисменты. Зал встаёт, сцена усыпана цветами. Блестящая демонстрация того, что совершенство не связано с качеством. Ещё раз, браво! Философы посрамлены и нервно курят в дальнем углу.
Да, прикольно, дядя Гэндальф. Вот что значит репутация. А ведь в этот раз Влад прав, за что вы его так .
Это все здорово, конечно. Инкапсуляция, и все такое. А вот вы, господа философы, попробуйте в С определить функцию, получающую аргументом абстрактный (инкапсулированный) тип данных. Ведь с инкапсулированными типами надо будет работать, так? А мы, инженера, посмотрим.
Особенно интересно вот что. Попробуйте определить на С generic-функцию, которая работает с типом данных, у которого определены операции, допустим, AddRef, Release, и Copy. Это имеет самое прямое отношение к инкапсуляции, так как реализация такого типа данных скрыта за интерфейсом, а интерфейс одинаков для любой реализации. Так что нет никаких причин, почему я не могу захотеть определить функцию, работающую с таким инкапсулированным (абстрактным) типом данных — ведь тип задается только набором операций над ним, так что тип одинаков для всех реализаций. Не знаю как кому, но мне "сокрытие данных" не интересно, мне нужна возможность полноценно работать с ADT.
Понятное дело, что на С++ я могу это сделать как минимум двумя разными способами, и в обоих случаях это будет типобезопасно. Любопытно, что именно вы выберете для реализации такого поведения в С (есть куча вариантов), и самое интересное, как вы потом будете доказывать, что получилось лучше, надежнее, правильнее, удобнее, итд.
В языке С слабая статическая типизация, этого вам поправить не удастся. Я боюсь, что в вашем решении вы возьмете худшее из двух миров — статического (язык С не предоставляет никакой стандартной возможности работать с типами в ран-тайме) и динамического (практически полное отсутствие статической проверки типов). Как такое может быть лучше С++ — ума не приложу.
Gaperton:
> F>На этом нужно остановиться чтобы понять что такое инкапсуляция. Что понимается под сокрытием данных? Это то же самое что и сокрытие информации? > > Инкапсуляция = абстрактный тип данных. С другого конца надо подходить. Тип данных, который определяется набором операций над ним а не структурой.
Я достаточно много подумал над этим, и пришел к выводу, что инкапсуляция > абстрактный тип данных. В том смысле что во-1х инкапуслировать можно не только структуру данных, и во-2х поддержка реализацией некоторой абстракции еще не означает инкапсуляции этой реализации.
1. Понятие "инкапсуляция" применимо не только к типу. Например, конкретная процедура (для функциональщиков — функция) замечательно инкапсулирует свой алгоритм (для функциональщиков — правила отображения входа в выход).
2. Понятие "инкапсуляция" в некотором смысле более жесткое, чем "абстракция". Этот пункт не такой бесспорный как первый, но если не согласны, то попробуйте объяснить в чем состоит различие между абстракцией и инкапсуляцией. Мне не хочется считать их синонимами.
Здесь класс А — пример абстракции, в которой не хватает инкапсуляции:
// класс A поддерживает (реализует) абстракцию - тип с функциями-членами foo() и bar() - но при этом не закрывает _data_memberclass Ab
{
public:
void foo();
void bar();
int _data_member;
};
// класс B поддерживает (реализует) ту же абстракцию, но _data_member закрыт - вот она, инкапсуляцияclass B
{
public:
void foo();
void bar();
private:
int _data_member;
};
Конечно, по соглашению клиентский код может не обращаться к _data_member класса А, т.е. использовать А таким образом, как если бы он был инкапсулрован. Именно как если бы.
Забавно, что сначала мне не нравилось толкование из Википедии, и я хотел найти более правильное, но теперь вижу что пришел к нему же:
In computer science, information hiding is leaving out some details of implementation on purpose from the public. Encapsulation is, besides hiding, to provide common interfaces.
> Отличие инкапсуляции в языке С и С++ состоит в том, что абстрактный тип данных (класс) является типом в С++ (со всеми вытекающими — например компилятор обеспечивает контроль и приведение типов), но не является типом в С, где подобная вещь реализуется на уровне соглашений (опять же со всеми вытекающими). > > Таким образом, инкапсуляция не поддерживается в С на уровне языка. Хорошо это, или плохо? Вопрос не в том, где лучше и надежнее скрываются данные, меня, например, это волнует мало. А вот то, что ADT не является типом с точки зрения языка — это крайне неудобно.
Спецификаторы доступа в С++ появились, имо, специально для обеспечения инкапсуляции (а не абстракции). Но наряду с ними в С++ можно использовать унаследованный от С метод инкапсуляции — ограничение области видимости.
ЗЫ И конечно я согласен, что сокрытие в стиле С предпочтительнее чем ограничение доступа.
Здравствуйте, jedi, Вы писали:
J>Приехали... Начали с инкапсуляции — пришли к чужому коду.
J>Как чужой код может вызывать Ваши классы о существовании которых он ничего не знает? (О Reflection лекции просьба не читать). Или Вы боитесь такой ситуации: Вы реализуете какой-то интерфейс и передаете его куда-то в third-party компонент, а он негодяй давай быстро менять Ваши приватные поля. Ай-яй-яй... Бред.
Так не бредь. Иди почитай про метаданные и управляемые среды.
J>Ответьте на вопрос какое отношение этот имеет к ИНКАПСУЛЯЦИИ.
Прямое. Это инкапсуляция перешедшая на новый уровень. Теперь это не джентельменское соглашение, а гарантированный сервис.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ПК>И где там согласие с "большем совершенстве С+ с точки зрения инкапсуляции"?
То есть ты утверждаешь, что существенное облегчение инкапсуляции не делает языки более совершенными с точки зрения инкапсуляции? Тебе не кажется это абсурдом?
ПК> То что на C++ легче организовать сокрытие данных/информации еще не означает, что получающийся результат лучше,
Да, но это означает, что в реальных приложениях все инкапсуляция будет появляться чаще. Такова уж человеческая натура.
ПК> чем то, что делается на C. В общем, все упирается в определение, что же такое "большее совершенство с точки зрения инкапсуляции".
По-моему — это очевидно. Язык обладает специальными синтаксическими конструкциями для инкапсуляции данных. Более того, язык создан специально для поддержики принципа инкапсуляции.
ПК>Я был не согласен, подразумевая под "большим совершенством" получение "лучшей" инкапсуляции в результате. И в такой трактовке не соглашусь и сейчас.
Твои проблемы.
ПК>Если же ты вкладывал в эти слова наличие в C++/Java/C# больших средств для обеспечения инкапсуляции, то да, я с такой поправкой согласен.
По-моему, я это и говорил. Причем довольно однозначно.
ПК>Только я не уверен, что это является причиной того, почему люди "переползают" (если вообще "переползают") c C на эти языки.
А что есть какие-то иные причины? Даже шаблоны — это средство обеспечения полиморфизма. Уж С++ то точно интересен только этими принципами. С точки зрения дизайна язык то не очень. Хотя опять же лучше чем С.
ПК> Впрочем, имхо, тут сложно что-то определенно утверждать без проведения полноценного исследования.
Согласен. Остается вопрос зачем было развивать все это обсуждение на ровном месте.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Изуительно. Бурные аплодисменты. Зал встаёт, сцена усыпана цветами. Блестящая демонстрация того, что совершенство не связано с качеством. Ещё раз, браво! Философы посрамлены и нервно курят в дальнем углу.
Если выключить демагогию, то и попробовать разобраться, то станет ясно, что от языка зависит далеко не все. На любом ООЯ добиться инкапсуляции насравнимо проще чем на С++. Да и вобще писать в ОО-стиле несравнимо проще. Только этого не достаточно для получения качественного варианта. ПК совершенно прав в том, что и на С можно добиться желаемого результата если хоршенько потрахаться. Вот только трахаться нужно несравнимо больше. И качество будет зависить от упорства и принципиальности программиста.
Если сравнить среднестатистический код на С и С++ (а уж темболее на C#), то будет четкая тенденция... код написанный на С будет менее качественным. Но все это при общих равных условиях. Ну, а если сравнить код написанный на С матерым профи и ламером, но на С++, то код на С окажется лучше. Вот только выводы из этого можно сделать совершенно иные нежели делает ПК.
ГВ>PS. От наглого редактора художественной литературы (подробности тута)
Интересная ссылка. Пожалуй процитирую:
Forbidden
You don't have permission to access /index.pl on this server.
--------------------------------------------------------------------------------
Apache/2.0.46 (Red Hat) Server at www.livejornal.com Port 80
ГВ>Юноша, прежде чем писать крамолу, достойную жертвенного костра, не худо бы вспомнить правила формальной логики. О русском языке для ясности умолчу. Однако рекомендую впредь чисто интуитивно переползать на более совершенные языки изложения. Коль скоро русский Вам противопоказан. ГВ>Спойте, што ли, на С#, а? ГВ>Любителей рассуждать о том, что кому позволено или не позволено рекомендовать, отправляю по вышеуказанному адресу (это если без мата, ага).
ГВ>PPS. С любезного разрешения Геннадия Васильева.
Коментировать этот бред и хамство как-то даже не хочется. Сплошная демагогия с переходом на личности. Причем неумело прикрытая несуществующей ссылкой.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Но вот объясните мне, убогому умом, ЗАЧЕМ нужна ТАКАЯ инкапсуляция? Что аппаратная (или рантайм) защита приватных данных делает хороший дизайн еще более хорошим? Ну не можешь ты писать в чужую память и все этого достаточно для защиты, причем тут вообще инкапсуляция? От ЧЕГО Вы защищаетесь таким способом?
Поэтому я и задавал дополнительные вопросы.
