VladD2:
> Да шишники вот уже 35 лет слона не замечают. Хотя не все. Многие просто чисто интиуитивно переползают на более совершенные с точки зрения инкапсуляции языки вроде С++, Явы, Шарпа...
Интересно... А в чем, по-твоему, большее совершенство, скажем, C++ по сравнению c С с точки зрения инкапсуляции? Можно примерчик?
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Интересно... А в чем, по-твоему, большее совершенство, скажем, C++ по сравнению c С с точки зрения инкапсуляции?
Она в нем есть.
ПК>Можно примерчик?
С++:
struct A
{
private:
int _val;
public:
int getVal() { return _val; }
void setVal(int val)
{
if (val < 0)
throw"требования инкапсуляции не допускают установку "
"отрицальтного значения свойству Val.";
_val = val;
}
};
void main()
{
A a;
a.setVal(123); // OK
a.setVal(-123); // Облом в рантайме.
a._val = -123; // Облом во время компиляции.
}
С:
struct A
{
int _val;
};
void mian()
{
A a;
a._val = -123; // Нарушение принципов инкапсуляции. Подразумевается что A::_val не может содержать отрицальное значение.
}
Не думаю, что этот пример был действительно нужен. Но чтобы ты в очередной раз не сказал, что я отказывюсь давать "подтвреждения своим утвреждениям" я его дал, затратив при этом немалое время на набивку соврешенно никчемного кода. В предь, уж извини я сразу буду посылать куда подальше, когда ты ты будешь мнея принуждать давать подтверждение совершенно очевидным вещам. Даговорились?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Не думаю, что этот пример был действительно нужен. Но чтобы ты в очередной раз не сказал, что я отказывюсь давать "подтвреждения своим утвреждениям" я его дал, затратив при этом немалое время на набивку соврешенно никчемного кода. В предь, уж извини я сразу буду посылать куда подальше, когда ты ты будешь мнея принуждать давать подтверждение совершенно очевидным вещам. Даговорились?
Влад, инкапсуляция — это когда вызывающая сторона ничего не знает о внутренней структуре обьекта с которым работает.
На С++ это делается при помощи абстрактных классов, которыми эмулируются интерфейсы (не приплетать сюда наследование, так как это независимые вещи). Надеюсь, ты можешь себе представить пример.
Спецификаторы доступа private/public/... в С++ не могут использоваться для инкапсуляции, потому что они не освобождают компилятор от необходимости знать о внутренней структуре объекта.
В твоем примере, как ни крути, компилятору надо знать структуру объекта. Что бы работать со классом надо иметь его полное описание вместе с внутренностями. У меня язык не поворачиваеться назвать это инкапсуляцией.
Здравствуйте, Nick_, Вы писали:
N_>Здравствуйте, VladD2, Вы писали:
VD>>Не думаю, что этот пример был действительно нужен. Но чтобы ты в очередной раз не сказал, что я отказывюсь давать "подтвреждения своим утвреждениям" я его дал, затратив при этом немалое время на набивку соврешенно никчемного кода. В предь, уж извини я сразу буду посылать куда подальше, когда ты ты будешь мнея принуждать давать подтверждение совершенно очевидным вещам. Даговорились?
N_>Влад, инкапсуляция — это когда вызывающая сторона ничего не знает о внутренней структуре обьекта с которым работает.
Спасибо, я занаю.
N_>На С++ это делается при помощи абстрактных классов, которыми эмулируются интерфейсы (не приплетать сюда наследование, так как это независимые вещи). Надеюсь, ты можешь себе представить пример.
Абстрактные классы тут совершенно не причем.
N_>Спецификаторы доступа private/public/... в С++ не могут использоваться для инкапсуляции, потому что они не освобождают компилятор от необходимости знать о внутренней структуре объекта.
Компилятор может знать все что угодно. Инкапсуляция — это понятие для человека. Компилятор только обеспечивает ее.
N_> Что бы работать со классом надо иметь его полное описание вместе с внутренностями. У меня язык не поворачиваеться назвать это инкапсуляцией.
Чтобы рабоать с классом достаточно знать его публичный интерфейс. Видмо тебя вводит в заблуждение термин "интерфейс". Ты видимо путаешь его с понятием из КОМ. А это не совсем одно и тоже. Виртуальность нужна для обеспечения динамического полиморфизма. А для инкапсуляции достаточно и средств вроде управления доступом.
ЗЫ
Я не совсем прав в том плане, что С совсем не поддерживает инкапсуляции. С поддерживает инкапсуляцию клобальных данных. Клобальные переменные могут быть не видны для других модулей. При этом можно организовать функции досупа к этим глобальным данным. Но этого явно недостаточно для полноценной реализации инкапсуляции. Классы и модификаторы доступа намного более гибкий инструмент.
А вообще, грусно. Мы тут осбуждаем такие высокоуровневые темы как паттерн-матчинг вс. полиморфизм, а на самом деле путаемся в базовых понятиях вроде инкапсуляции.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
> Я не совсем прав в том плане, что С совсем не поддерживает инкапсуляции. С поддерживает инкапсуляцию клобальных данных. Клобальные переменные могут быть не видны для других модулей. При этом можно организовать функции досупа к этим глобальным данным. Но этого явно недостаточно для полноценной реализации инкапсуляции. Классы и модификаторы доступа намного более гибкий инструмент.
Наверное когда ПК говорил об инкапсуляции в С, он имел ввиду что-то вроде этого:
struct A; // A объявлено, но не определеноint getVal(struct A const*);
void setVal(struct A*, int);
Так что скрывать можно не только глобальные данные. Правда скорее всего еще понадобятся средства для создания и удаления struct A, также следует опасаться неявного приведения void* -> A*, и поскольку неймспейсов нет, то к функциям придется добавлять префиксы A_ чтобы отличать их от соответствующих функций для struct B. Короче, в С все удобства на улице. Но вопрос в том, что же такое инкапсуляция.
> А вообще, грусно. Мы тут осбуждаем такие высокоуровневые темы как паттерн-матчинг вс. полиморфизм, а на самом деле путаемся в базовых понятиях вроде инкапсуляции.
Стыдно сказать, действительно путаемся. Предлагаю вынести ветку про инкапсуляцию в Философию, потому что эта тема интересна сама по себе.
Ясно, что инкапсуляция (а также сокрытие информации и абстракция) так или иначе связаны с запрещением доступа к реализации. Чтобы говорить предметно попытался провести классификацию целей и средств.
Цели, которые могут преследоваться, при запрещении доступа к реализации (добавьте если чего забыл) :
1. исключение нарушения инвариантов реализации
2. уменьшение цены внесения изменений в реализацию
3. обеспечение полиморфного использования реализации
Средства, которые могут использоваться, для запрещения доступа к реализации (если это вообще имеет отношение к обсуждаемому вопросу) (и добавьте если чего забыл) :
1. права доступа в ЯП (public, private и т.д.)
2. область видимости в ЯП (определение локально для функции, определение локально для модуля и т.д.)
3. отдельный бинарный файл, содержащий реализацию (dll, exe в отдельном процессе и т.д.)
Можно нарисовать таблицу 3х3 и указать, какие из ячеек относятся к инкапсуляции, сокрытию информации и абстракции. Далее мое имхо, я считаю (считал, в смысле торг уместен) что:
1. термин "инкапсуляция" относится к первым двум целям (исключение нарушения инвариантов и уменьшение цены изменений) и не зависит от средств достижения целей.
2. термин "абстракция" относится к третьей цели (обеспечение полиморфного использования) и тоже не зависит от средств достижения.
3. термин "сокрытие информации" обозначает собственно запрещение доступа к реализации, т.е. относится ко всем ячейкам таблицы и является просто средством обеспечения инкапсуляции и побочным эффектом достижения абстракции.
Давайте разберем мои ошибки и попытаемся прийти к консенсусу насчет этих терминов.
Здравствуйте, folk, Вы писали:
F>Наверное когда ПК говорил об инкапсуляции в С, он имел ввиду что-то вроде этого: F>
F>struct A; // A объявлено, но не определено
F>int getVal(struct A const*);
F>void setVal(struct A*, int);
F>
F>Так что скрывать можно не только глобальные данные. Правда скорее всего еще понадобятся средства для создания и удаления struct A, также следует опасаться неявного приведения void* -> A*, и поскольку неймспейсов нет, то к функциям придется добавлять префиксы A_ чтобы отличать их от соответствующих функций для struct B. Короче, в С все удобства на улице. Но вопрос в том, что же такое инкапсуляция.
Дык о том, и речь. Это закат солнца вручную.
По этому я и сказал:
более совершенные с точки зрения инкапсуляции языки вроде С++, Явы, Шарпа...
F>Стыдно сказать, действительно путаемся. Предлагаю вынести ветку про инкапсуляцию в Философию, потому что эта тема интересна сама по себе.
Что не сделаешь по просьбам трудящихся.
F>Ясно, что инкапсуляция (а также сокрытие информации и абстракция) так или иначе связаны с запрещением доступа к реализации. Чтобы говорить предметно попытался провести классификацию целей и средств.
F>Цели, которые могут преследоваться, при запрещении доступа к реализации (добавьте если чего забыл) : F>1. исключение нарушения инвариантов реализации
+1 F>2. уменьшение цены внесения изменений в реализацию
+1 F>3. обеспечение полиморфного использования реализации
И все же полиморфизм не связан непосредственно с инкапсуляцией. Те же ФЯ — это хорошо доказывают. Просто в ООП — это два принципа неразрывно связаны и в купе помогают решать проблемы абстрагирования.
F>Средства, которые могут использоваться, для запрещения доступа к реализации (если это вообще имеет отношение к обсуждаемому вопросу) (и добавьте если чего забыл) : F>1. права доступа в ЯП (public, private и т.д.)
+1 F>2. область видимости в ЯП (определение локально для функции, определение локально для модуля и т.д.)
+1 F>3. отдельный бинарный файл, содержащий реализацию (dll, exe в отдельном процессе и т.д.)
+1
F>Можно нарисовать таблицу 3х3 и указать, какие из ячеек относятся к инкапсуляции,...
Нарисуй. Все только спасибо скажут.
F>Давайте разберем мои ошибки и попытаемся прийти к консенсусу насчет этих терминов.
По-моему, у тебя только одна ошибка и я указал на нее выше. В остальном согласен.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2:
> ПК> Интересно... А в чем, по-твоему, большее совершенство, скажем, C++ по сравнению c С с точки зрения инкапсуляции?
> Она в нем есть.
Средства для обеспечения инкапсуляции есть и в C. При этом получающаяся инкапсуляция ничуть не "меньше", чем в C++.
> ПК> Можно примерчик?
> С++: >
> struct A
> {
> private:
> int _val;
>
> public:
> int getVal() { return _val; }
>
> void setVal(int val)
> {
> if (val < 0)
> throw"требования инкапсуляции не допускают установку "
> "отрицальтного значения свойству Val.";
> _val = val;
> }
> };
>
> void main()
> {
> A a;
> a.setVal(123); // OK
> a.setVal(-123); // Облом в рантайме.
> a._val = -123; // Облом во время компиляции.
> }
Ты привел неэквивалентный с точки зрения инкапсуляции пример на C. Но это не означает, что нельзя написать эквивалентный в этом отношении пример на C. Вот он:
Заголовочный файл:
typedef int ErrorCode;
#define A_OK ((ErrorCode)0)
// Требования инкапсуляции не допускают установку
// отрицальтного значения свойству Val.
//#define A_ERROR_INVALID_VAL ((ErrorCode)-1)
typedef struct Atag A;
A* create_A(void);
void delete_A(A*);
int A_getVal(A*);
ErrorCode A_setVal(A*, int);
Файл с реализацией:
. . .
struct Atag
{
int _val;
};
A* create_A(void)
{
A* a = (A*)malloc(sizeof(A));
return a;
}
void delete_A(A* a)
{
free(a);
}
int A_getVal(A* a)
{
return a->_val;
}
ErrorCode setVal(A* a, int val)
{
if (val < 0)
return A_ERROR_INVALID_VAL;
a->_val = val;
return A_OK;
}
Использование:
int main()
{
A* a;
ErrorCode err_code;
a = create_A();
if (!a)
return -1;
err_code = 0;
. . .
if (err_code != A_OK)
err_code = A_setVal(a, 123); // OKif (err_code != A_OK)
err_code = A_setVal(a, -123); // Облом в рантайме.if (err_code != A_OK)
a->_val = -123; // Облом во время компиляции.
delete_A(a);
return err_code == A_OK ? 0 : -1;
}
> Не думаю, что этот пример был действительно нужен.
Отчего же, он вполне хорошо проиллюстрировал твою позицию, здорово сэкономив нам время на ненужной риторике. Как видишь, C вполне позволяет писать код, эквивалентный в отношении инкапсуляции коду на C++. Скажем, та же Win API в этом отношении вполне в порядке.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
И всё-таки код не эквивалентен. Действуя по правилам языка — я могу использовать указатель на структуру, что бы получить или изменить значение переменной. Т.е. получаем не более чем инкапсуляцию по соглашению, а вовсе не синтаксическую инкапсуляцию. С тем же успехом можно говорить об инкапсуляции на ассемблере.
И хотя на C всё же возможен вариант инкапсуляции — когда в начале любого объекта указатель на таблицу виртуальных функций и кроме него (а так же порядка расположения и сигнатуры функций) другим модулям не известно больше ничего — всё равно это пример скорее искусственного использования языка, нежели реальной инкапсуляции. Хотя бы потому, что и тут инкапсуляция по соглашению, да в добавок усилия по написанию такого кода на порядок выше, чем при написании кода обычного — в то время как на языках с естественной поддержкой инкапсуляции — C++, C#, Jaba — затраты на инкапсуляцию почти (или вообще) не заметны.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Средства для обеспечения инкапсуляции есть и в C.
Кто-то заявлял обратное? Есть, кое-какие, но более скудные нежели в ООП-языках.
ПК> При этом получающаяся инкапсуляция ничуть не "меньше", чем в C++.
А кто говорил о меньшей или большей?
ПК>Ты привел неэквивалентный с точки зрения инкапсуляции пример на C.
Естествнно. Я же мазохист наворачивать на С черти какие навороты чтобы доказать примитивнную фразу. Я показал отсуствие средств инкапсуляции на уровне типа. Что в точности соотвествует моим словам о меньших возможностях С в этой области.
ПК> Но это не означает, что нельзя написать эквивалентный в этом отношении пример на C. Вот он:...
Код поискипан.
Скажи, ты считашь этот код таким же простым как и приведенный мной? И к тому же этот код демонстрирует только эмуляцию энкапсуляции, так как фактически ничто не мешает мне получить описание этого типа и изменить значение полей. Что не так в случае с ООП-языками.
ПК>Отчего же, он вполне хорошо проиллюстрировал твою позицию, здорово сэкономив нам время на ненужной риторике. Как видишь, C вполне позволяет писать код, эквивалентный в отношении инкапсуляции коду на C++. Скажем, та же Win API в этом отношении вполне в порядке.
Паш, я устал от демагогии льющейся, с твоей стороны в мой адрес, в последнее время все больше и больше.
Вот только что ты сделал вид, что я где-то заявил о том, что на С невозможно достичь инкапсуляции и гневно разгромил мою невреную позицию. Но тут есть одна закавыка. Я этого не заявлял! Ты боролся не с моими утверждениями, а с их переиначенным вариантом. Напомню, я сказал следующее:
Да сишники вот уже 35 лет слона не замечают. Хотя не все. Многие просто чисто интиуитивно переползают на более совершенные с точки зрения инкапсуляции языки вроде С++, Явы, Шарпа...
Итак, где же здесь утверждение о невозможности реализации инкапсуляции в С? Если сделать обратный вывод, то из этого высказывания можно получить только лишь заявление тиа:
С++, Явы, Шарпа обладают более совершенными средствами инкапсуляции.
с folk-ом, и твоей несомненный опыт в этом вопросе, я осмелюсь предположить, что это совершенно намерянная провокация. Так какова же ее цель? Мне уже надоело доказывать, что я не верблюд. Единственный выход борьбы с подобными нападками я виже только использование твоей тактики. Но мне банально не хочется этим заниматься, по этому предлагаю просто не докапываться до слов других и не требовать подтверждения любых сказанных другим слов. Тем более в ультимативной форме и с обидными эпитетами типа "огульный". ОК?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, Павел Кузнецов, Вы писали:
AF> И всё-таки код не эквивалентен. Действуя по правилам языка — я могу использовать указатель на структуру, что бы получить или изменить значение переменной.
Не можешь -- ты не видишь определение структуры, оно скрыто в файле реализации.
AndreyFedotov:
> И всё-таки код не эквивалентен. Действуя по правилам языка — я могу использовать указатель на структуру, что бы получить или изменить значение переменной.
Это в теории. На практике можно наблюдать, что многие библиотеки и API, написанные на C, лучше скрывают детали своей реализации, чем аналогичные библиотеки и API на C++.
Попробуй, например, доступиться к внутренним структурам Windows — вряд ли это получится сделать легко: Win API достаточно хорошо изолирует тебя от внутренних деталей. А теперь давай посмотрим, скажем, на MFC... Много переменных-членов public, protected, не говоря уже о различных "внутренних" функциях с доступом public, включенных в интерфейс класса просто потому что они нужны самой MFC.
На C++ легче организовать сокрытие данных (вообще-то это вовсе не эквивалентно инкапсуляции, но на этом можно сейчас не останавливаться). Но это вовсе не означает, что сокрытие данных будет практически более эффективно, чем в C.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2:
> ПК>Средства для обеспечения инкапсуляции есть и в C.
> Кто-то заявлял обратное?
Да:
ПК> Интересно... А в чем, по-твоему, большее совершенство, скажем, C++ по сравнению c С с точки зрения инкапсуляции?
Она в нем есть.
> Скажи, ты считашь этот код таким же простым как и приведенный мной?
Нет. Но в реальных приложениях это имеет весьма небольшое значение. Я с тобой согласен в отношении того, что в C++ легче сокрыть данные, чем в C. Но, к своему сожалению, я часто замечаю, что практически интерфейсы на C более инкапсулированы, чем интерфейсы на C++.
> И к тому же этот код демонстрирует только эмуляцию энкапсуляции, так как фактически ничто не мешает мне получить описание этого типа и изменить значение полей. Что не так в случае с ООП-языками.
Если говорить о C++, то, несмотря на то, что "легальными" средствами получить доступ к private части класса нельзя, реально это делается совсем не сложно. Даже легче, чем в коде на C, приведенном выше, т.к. описание класса уже находится в заголовочном файле, и большинство модификаций оригинального кода не будет требовать исправлений в коде пользователя.
> Паш, я устал от демагогии льющейся, с твоей стороны в мой адрес, в последнее время все больше и больше.
Я его сообщение увидел уже после того, как отправил ответ. Если бы заметил раньше, скорее всего, ничего писать бы не стал, т.к. он вполне подробно все расписал.
> , я осмелюсь предположить, что это совершенно намерянная провокация. Так какова же ее цель?
тебя уточнить, что же ты имел в виду, т.к. никакого особого совершенства C++ в отношении обеспечения инкапсуляции по сравнению с C я реально не наблюдаю. По моему опыту скорее даже наоборот: т.к. "простых" средств для сокрытия данных в C нет, то если кому-то хочется это оганизовать, он вынужден использовать более радикальные подходы, чем в C++, соответственно, получая более эффективные в отношении сокрытия реализации результаты.
P.S. Тебе больше нравиться переходить к разборкам вместо того, чтобы ограничиться простым ответом на заданный вопрос?
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>AndreyFedotov:
>> И всё-таки код не эквивалентен. Действуя по правилам языка — я могу использовать указатель на структуру, что бы получить или изменить значение переменной.
ПК>Это в теории. На практике можно наблюдать, что многие библиотеки и API, написанные на C, лучше скрывают детали своей реализации, чем аналогичные библиотеки и API на C++.
Это вполне естественно. Чем больше возможностей в языке — тем больше шансов сделать кучу ляпов. Ведь C++, C# или Java не гарантируют принудительной инкапсуляции — а лишь поддерживают возможность инкапсуляции.
ПК>Попробуй, например, доступиться к внутренним структурам Windows — вряд ли это получится сделать легко: Win API достаточно хорошо изолирует тебя от внутренних деталей. А теперь давай посмотрим, скажем, на MFC... Много переменных-членов public, protected, не говоря уже о различных "внутренних" функциях с доступом public, включенных в интерфейс класса просто потому что они нужны самой MFC.
Сравнение не корректно. Команда, которая делала API Windows — была на несколько порядков опытнее, было потрачено гораздо болше времени и сил как на проектирование так и на реализацию. Про MFC прекрасно известно, что это было несчастное детя порочного союза — на которое всем было наплевать, и оно бы давно умерло, если бы не конкуренция с Borland, во имя которой MFC была раскручена, при сохранении обратной псевдосовместимости со старыми версиями — из-за которой и торчат кишки в виде открытых переменных и т.п.
Кроме того — сравнение это вообще не корректно — так как сравнивается ОС — обеспечивающая инкапсуляцию аппаратными средствами и весьма кривая библиотека — справедливо раскритикованная уже огромное кол-во раз. Тогда уж надо сравнивать Windows и объектно-ориентированные ОС.
ПК>На C++ легче организовать сокрытие данных (вообще-то это вовсе не эквивалентно инкапсуляции, но на этом можно сейчас не останавливаться). Но это вовсе не означает, что сокрытие данных будет практически более эффективно, чем в C.
Вот именно практически — будет. Хотя и в том и в другом случае — используя довольно простые трюки инкапсуляцию легко нарушить. Но проблема не в языке. Проблема в железе — которое просто не даёт возможности эффективно поддержать инкапсуляцию на уровне языка. Или резко теряете в производительности — или забудьте о настоящей инкапусляции.
Что бы инкапсулировать данные по-настоящему, требудется, что бы область данных процесса была доступна не всему процессу, а только коду методов класса. Современные процессоры такую возможность не предоставляют (хотя до некоторой степени на x386 это сделать и возможно).
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Здравствуйте, Павел Кузнецов, Вы писали:
AF>> И всё-таки код не эквивалентен. Действуя по правилам языка — я могу использовать указатель на структуру, что бы получить или изменить значение переменной.
Ш>Не можешь -- ты не видишь определение структуры, оно скрыто в файле реализации.
Да, так можно поступить — но тогда мигом получаем другие грабли — нет проверки указателей, и элементарно подсунуть вместо одного типа — другой. Что в случае C++ элементарно было бы выловлено на этапе компиляции.
Кроме того — сути дела это не меняет — инкапсуляция всё-равно только по соглашению. В том же модуле — где расположена структура — все равно элементарно можно получить доступ к содержимому объекта напрямую, а плодить по паре файлов на каждый тип — накладно.
Да и потом — никто и не отрицает возможности инкапсуляции на C — речь идёт только о накладных расходах на неё. Так же, как и в случае с ассемблером.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Вот именно практически — будет. Хотя и в том и в другом случае — используя довольно простые трюки инкапсуляцию легко нарушить. Но проблема не в языке. Проблема в железе — которое просто не даёт возможности эффективно поддержать инкапсуляцию на уровне языка. Или резко теряете в производительности — или забудьте о настоящей инкапусляции.
ИМХО, Вы перепутали Божий дар с яичницей .
Инкапсуляция — это один из методов грамотного проектирования, позволяющий снизить связанность между компонентами из которых строится система.
А то о чем Вы говорите — это безопасность исполнения. И компилятор к ней никакого отношения не имеет.
Скорее это задача загрузчика ОС обеспечить защиту модулей от посягательств друг друга .
AF> Что бы инкапсулировать данные по-настоящему, требудется, что бы область данных процесса была доступна не всему процессу, а только коду методов класса. Современные процессоры такую возможность не предоставляют (хотя до некоторой степени на x386 это сделать и возможно).
И не скоро предоставят в том виде, в котором Вы это описали.
Во-первых это слишком сложно реализовать аппаратно (сами подумайте нужно грузить код всех методов данного класса в отдельный сегмент со спец. правами доступа к сегменту данных и т.д. и т.п).
Во-вторых это просто-напросто никому не нужно.
В-третьих это легко достигается уже существующими методами. Помещением классов в разные адресные простронства и использование любого доступного метода IPC.
VladD2:
> F>Стыдно сказать, действительно путаемся. Предлагаю вынести ветку про инкапсуляцию в Философию, потому что эта тема интересна сама по себе. > > Что не сделаешь по просьбам трудящихся.
Вот бы модераторы philosophy и decl почаще разносили ветки по собственной инициативе, а то в длинных обсуждениях черт ногу сломит. Да еще мой OE иногда загадочно перетасовывает дерево сообщений.
> > F>Ясно, что инкапсуляция (а также сокрытие информации и абстракция) так или иначе связаны с запрещением доступа к реализации. Чтобы говорить предметно попытался провести классификацию целей и средств. > > F>Цели, которые могут преследоваться, при запрещении доступа к реализации (добавьте если чего забыл) : > F>1. исключение нарушения инвариантов реализации > +1 > F>2. уменьшение цены внесения изменений в реализацию > +1 > F>3. обеспечение полиморфного использования реализации > > И все же полиморфизм не связан непосредственно с инкапсуляцией. Те же ФЯ — это хорошо доказывают. Просто в ООП — это два принципа неразрывно связаны и в купе помогают решать проблемы абстрагирования.
Хотелось показать, что для кода, использующего полиморфный тип, реализация тоже скрыта. И скрыта по объективным причинам, а не потому что хочется безопасности или легкости изменений в реализации. Разве это не справедливо для ФЯ?
> F>Средства, которые могут использоваться, для запрещения доступа к реализации (если это вообще имеет отношение к обсуждаемому вопросу) (и добавьте если чего забыл) : > F>1. права доступа в ЯП (public, private и т.д.) > +1 > F>2. область видимости в ЯП (определение локально для функции, определение локально для модуля и т.д.) > +1 > F>3. отдельный бинарный файл, содержащий реализацию (dll, exe в отдельном процессе и т.д.) > +1 > > F>Можно нарисовать таблицу 3х3 и указать, какие из ячеек относятся к инкапсуляции,... > Нарисуй. Все только спасибо скажут.
Пусть сначала ПК прояснит кое-что.
> F>Давайте разберем мои ошибки и попытаемся прийти к консенсусу насчет этих терминов. > > По-моему, у тебя только одна ошибка и я указал на нее выше. В остальном согласен.
Павел Кузнецов:
> На C++ легче организовать сокрытие данных (вообще-то это вовсе не эквивалентно инкапсуляции, но на этом можно сейчас не останавливаться). Но это вовсе не означает, что сокрытие данных будет практически более эффективно, чем в C.
На этом нужно остановиться чтобы понять что такое инкапсуляция. Что понимается под сокрытием данных? Это то же самое что и сокрытие информации?
Здравствуйте, jedi, Вы писали:
J>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Вот именно практически — будет. Хотя и в том и в другом случае — используя довольно простые трюки инкапсуляцию легко нарушить. Но проблема не в языке. Проблема в железе — которое просто не даёт возможности эффективно поддержать инкапсуляцию на уровне языка. Или резко теряете в производительности — или забудьте о настоящей инкапусляции.
J>ИМХО, Вы перепутали Божий дар с яичницей .
В этом у меня талант, однако...
J>Инкапсуляция — это один из методов грамотного проектирования, позволяющий снизить связанность между компонентами из которых строится система.
Догадываюсь.
J>А то о чем Вы говорите — это безопасность исполнения. И компилятор к ней никакого отношения не имеет.
Догадываюсь.
Об этом начал говорить не я а предидущие ораторы, когда они заявили, что:
— Windows лучше инкапсулирует свои внутренние структуры данных (написанные на C) чем библиотеки на C++ (в качестве примера приводилась MFC)
На что я ответил, что сравнение относительно хорошо продуманной ОС и кривой (изначально и по признанию создателей) библиотеки в смысле качества проектирования (одним из критериев которого безусловно и является инкапсуляция) — не корректно. Кроме того — прекрасны известны примеры, когда как раз используются внутренние структуры данных Windows — начиная от банальных LOGFONT — которые столь же элементарно заполнить как правильно так и не правильно (объектный GDI+ в этом смысле на порядок надёжнее) и кончая структурами, описание которых публике не известно (тому есть примеры в MSDN и даже здесь на RSDN — например посмотрите прекрасную статью про обработку структурированных исключений). Тут есть так же и другая грань — что доступ к ряду структур (например к структурам дескрипторов) защищён средствами ОС — но так это как раз и есть безопасность использования, а не инкапсуляция.
J>Скорее это задача загрузчика ОС обеспечить защиту модулей от посягательств друг друга .
На уровне модулей она давно решена.
AF>> Что бы инкапсулировать данные по-настоящему, требудется, что бы область данных процесса была доступна не всему процессу, а только коду методов класса. Современные процессоры такую возможность не предоставляют (хотя до некоторой степени на x386 это сделать и возможно). J>И не скоро предоставят в том виде, в котором Вы это описали.
Вопрос — я тоже сомневаюсь, однако известно, что работы в этом направлении ведутся.
J>Во-первых это слишком сложно реализовать аппаратно (сами подумайте нужно грузить код всех методов данного класса в отдельный сегмент со спец. правами доступа к сегменту данных и т.д. и т.п).
Не многим сложнее, чем защита на уровне сегментов, однако затраты памяти и ресурсов действительно выше.
J>Во-вторых это просто-напросто никому не нужно.
Никому, если не считать пентагон, МО, NASA и с десяток отраслеобразующих монстров вроде Intel и IBM.
J>В-третьих это легко достигается уже существующими методами. Помещением классов в разные адресные простронства и использование любого доступного метода IPC.
Легко — это вы мягко сказали — с учётном затрат на переключение контекста и прочие прелести...
Кроме того количество процессов весьма ограничено, что бы вытаскивать код каждого класса (тем паче метода) в одельный процесс.
J>Best regards, jedi. J>P.S. Ой, кажется я ввязался в флейм ...
А вот это у Тебя Талант...
PS. По поводу .NET — законы природы не обманешь. Если проверка не делается аппаратными средствами, значит она делается программно и нужно аккуратно выяснять плюсы и минусы обоих подходов, а не просто уповать на всемогущество .NET.
...
