Здравствуйте, folk, Вы писали:

F>Я достаточно много подумал над этим, и пришел к выводу, что инкапсуляция > абстрактный тип данных. В том смысле что во-1х инкапуслировать можно не только структуру данных, и во-2х поддержка реализацией некоторой абстракции еще не означает инкапсуляции этой реализации.

F>1. Понятие "инкапсуляция" применимо не только к типу. Например, конкретная процедура (для функциональщиков — функция) замечательно инкапсулирует свой алгоритм (для функциональщиков — правила отображения входа в выход).

Ваше наблюдение совершенно верное. При этом, это все равно совершенно одно и тоже. Выделяют два типа абстракции:
Абстракция данных (то, что в ООП называют инкапсуляция)
Процедурная абстракция — то что вы называете инкапсуляцией алгоритма.

Литература:
Лисков, Б.; Гатэг, Дж.
"Использование абстракций и спецификаций при разработке программ"

Эта книга (оригинально издательства MITPress) построена на базе соответвующего учебного курса MIT, который вели означенные люди. Думаю, Лисков представлять не нужно. Это одна единственная книга, где про разнообразные абстракции сказано все.

F>2. Понятие "инкапсуляция" в некотором смысле более жесткое, чем "абстракция". Этот пункт не такой бесспорный как первый, но если не согласны, то попробуйте объяснить в чем состоит различие между абстракцией и инкапсуляцией. Мне не хочется считать их синонимами.
F>Здесь класс А — пример абстракции, в которой не хватает инкапсуляции:
F>

F>// класс A поддерживает (реализует) абстракцию - тип с функциями-членами foo() и bar() - но при этом не закрывает _data_member
F>class Ab
F>{
F> public:
F>  void foo();
F>  void bar();
F>  int _data_member;
F>};

Я не вижу здесь никакой абстракции. Это структура, + определено несколько функций, которые принимают ее аргументом. И все. Абстрактный тип данных определяется только операциями над ним. Понимаете — только. В этом смысл абстракции.
Что такое табуретка? Если вы скажете, что это четыре ножки + сиденье, это не будет ADT. ADT для табуретки — нечто, на что можно сесть. Стул — это не табуретка, у которой есть спинка. Это то, на что (1) можно сесть и (2) при этом можно откинуться назад и не упасть.

F>// класс B поддерживает (реализует) ту же абстракцию, но _data_member закрыт — вот она, инкапсуляция
F>class B
F>{
F> public:
F> void foo();
F> void bar();
F> private:
F> int _data_member;
F>};
F>[/c]
F>Конечно, по соглашению клиентский код может не обращаться к _data_member класса А, т.е. использовать А таким образом, как если бы он был инкапсулрован. Именно как если бы.
Зачем это делать? Если нечто помечено как public, позразумевается, что вы хотите предоставить к этому свободный доступ. Если это данные, то об абстракции можно забыть — ее нет. Какой смысл применять соглашения для достижения того, что и так предоставляется средствами языка?

F>Забавно, что сначала мне не нравилось толкование из Википедии, и я хотел найти более правильное, но теперь вижу что пришел к нему же:

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.

Возможно. Меня как инженера не интересует information hiding. Это не привносит ничего интересного в процесс разработки и дизайна, если думаешь в терминах ADT. Тем более, не вижу смысла в маниакальном сокрытии данных в рамках одного проекта — люди и так узнают внутренности, если захотят — им достаточно просто спросить об этом автора . А если им не понятно, что такое public interface, то вопрос решается не техническими средствами, а простым обучением (хотя таких лучше на работу не брать).

В случае если уж надо именно что-то скрыть (а на самом деле — обеспечить независимую разработку и удобство повторного использования, что несколько другое), я воспользуюсь компонентными технологиями — и опять же, information hiding я получу автоматически, не думая о нем специально при дизайне. Зачем вводить этот термин? Он не интересен, по крайней мере мне. Я не рассуждаю в таких терминах. Я не чувствую, что такой взгляд на вещи приносит мне какую-либо пользу как инженеру.

>> Отличие инкапсуляции в языке С и С++ состоит в том, что абстрактный тип данных (класс) является типом в С++ (со всеми вытекающими — например компилятор обеспечивает контроль и приведение типов), но не является типом в С, где подобная вещь реализуется на уровне соглашений (опять же со всеми вытекающими).
>>
>> Таким образом, инкапсуляция не поддерживается в С на уровне языка. Хорошо это, или плохо? Вопрос не в том, где лучше и надежнее скрываются данные, меня, например, это волнует мало. А вот то, что ADT не является типом с точки зрения языка — это крайне неудобно.
F>Спецификаторы доступа в С++ появились, имо, специально для обеспечения инкапсуляции (а не абстракции). Но наряду с ними в С++ можно использовать унаследованный от С метод инкапсуляции — ограничение области видимости.
C++ предоставляет адекватные средства для реализации ADT, причем все модификаторы необходимы. Почему именно они появились — вопрос с моей точки зрения праздный, главное, зачем они мне нужны. Ну, а за использование в С++ методов инкапсуляции, и прочих методов, унаследованных из С, я лично бью по рукам. Особенно, если автор не в состоянии внятно объяснить свою мотивацию — почему он не применяет "родные" методы С++.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вот точная ссылка: сюда.

И типа эта ссылка делает твою демагию более логичной, а оскорбления превращает в мудрость?

Здравствуйте, VladD2, Вы писали:

ГВ>>Вот точная ссылка: сюда.
VD>И типа эта ссылка делает твою демагию более логичной, а оскорбления превращает в мудрость?

Она ведёт к наглому редактору.

Здравствуйте, Gaperton, Вы писали:

F>>1. Понятие "инкапсуляция" применимо не только к типу. Например, конкретная процедура (для функциональщиков — функция) замечательно инкапсулирует свой алгоритм (для функциональщиков — правила отображения входа в выход).

G>Ваше наблюдение совершенно верное. При этом, это все равно совершенно одно и тоже.

Здесь я оспаривал уместность слова "тип" во фразе "инкапсуляция = абстрактный тип".

G>Выделяют два типа абстракции:
G>Абстракция данных (то, что в ООП называют инкапсуляция)
G>Процедурная абстракция — то что вы называете инкапсуляцией алгоритма.

G>Литература:
G>Лисков, Б.; Гатэг, Дж.
G>"Использование абстракций и спецификаций при разработке программ"

G>Эта книга (оригинально издательства MITPress) построена на базе соответвующего учебного курса MIT, который вели означенные люди. Думаю, Лисков представлять не нужно. Это одна единственная книга, где про разнообразные абстракции сказано все.

На досуге попробую найти-почитать. Но сомневаюсь что там все упрощено до "инкапсуляция = абстракция".

F>>2. Понятие "инкапсуляция" в некотором смысле более жесткое, чем "абстракция". Этот пункт не такой бесспорный как первый, но если не согласны, то попробуйте объяснить в чем состоит различие между абстракцией и инкапсуляцией. Мне не хочется считать их синонимами.
F>>Здесь класс А — пример абстракции, в которой не хватает инкапсуляции:
F>>

F>>// класс A поддерживает (реализует) абстракцию - тип с функциями-членами foo() и bar()
F>>// - но при этом не закрывает _data_member
F>>class Ab
F>>{
F>> public:
F>>  void foo();
F>>  void bar();
F>>  int _data_member;
F>>};

G>Я не вижу здесь никакой абстракции. Это структура, + определено несколько функций, которые принимают ее аргументом. И все. Абстрактный тип данных определяется только операциями над ним. Понимаете — только. В этом смысл абстракции.

Абстракция

struct { void foo(); void bar(); };

определяется только операциями foo и bar. Классы A и B являются не абстрактными, а вполне конкретными типами. И оба реализуют вышеуказанную абстракацию, так что клиент работающий с этой абстракцией может использовать и класс А, и класс B.

G>Что такое табуретка? Если вы скажете, что это четыре ножки + сиденье, это не будет ADT. ADT для табуретки — нечто, на что можно сесть. Стул — это не табуретка, у которой есть спинка. Это то, на что (1) можно сесть и (2) при этом можно откинуться назад и не упасть.

Стул не является табуреткой. Стул и табуретка являются сиденьями. А сиденье — нечто, на что можно сесть.

[]

F>>Конечно, по соглашению клиентский код может не обращаться к _data_member класса А, т.е. использовать А таким образом, как если бы он был инкапсулрован. Именно как если бы.
G>Зачем это делать? Если нечто помечено как public, позразумевается, что вы хотите предоставить к этому свободный доступ. Если это данные, то об абстракции можно забыть — ее нет. Какой смысл применять соглашения для достижения того, что и так предоставляется средствами языка?

Как правило незачем. Здесь я спорил с товарищами, утверждающими, что предоставление функций доступа без information hiding является инкапсуляцией. Я так не считаю.

F>>Забавно, что сначала мне не нравилось толкование из Википедии, и я хотел найти более правильное, но теперь вижу что пришел к нему же:

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.

G>Возможно. Меня как инженера не интересует information hiding. Это не привносит ничего интересного в процесс разработки и дизайна, если думаешь в терминах ADT. Тем более, не вижу смысла в маниакальном сокрытии данных в рамках одного проекта — люди и так узнают внутренности, если захотят — им достаточно просто спросить об этом автора . А если им не понятно, что такое public interface, то вопрос решается не техническими средствами, а простым обучением (хотя таких лучше на работу не брать).

G>В случае если уж надо именно что-то скрыть (а на самом деле — обеспечить независимую разработку и удобство повторного использования, что несколько другое), я воспользуюсь компонентными технологиями — и опять же, information hiding я получу автоматически, не думая о нем специально при дизайне. Зачем вводить этот термин? Он не интересен, по крайней мере мне. Я не рассуждаю в таких терминах. Я не чувствую, что такой взгляд на вещи приносит мне какую-либо пользу как инженеру.

Если говорить о полезности/безполезности терминов, то зачем использовать два термина с одинаковой, по Вашему мнению, смысловой нагрузкой — абстракция и инкапсуляция?

Компонентные технологии здесь совершенно ни при чем. Чтобы узнать внутренности компонента, опять же достаточно спросить у автора , есть и другие способы.

[]

F>>Спецификаторы доступа в С++ появились, имо, специально для обеспечения инкапсуляции (а не абстракции). Но наряду с ними в С++ можно использовать унаследованный от С метод инкапсуляции — ограничение области видимости.
G>C++ предоставляет адекватные средства для реализации ADT, причем все модификаторы необходимы. Почему именно они появились — вопрос с моей точки зрения праздный, главное, зачем они мне нужны. Ну, а за использование в С++ методов инкапсуляции, и прочих методов, унаследованных из С, я лично бью по рукам.

Бессмысленная жестокость

G>Особенно, если автор не в состоянии внятно объяснить свою мотивацию — почему он не применяет "родные" методы С++.

Особенно, если автор вообще невменямый

Здравствуйте, folk, Вы писали:

F>Здесь я оспаривал уместность слова "тип" во фразе "инкапсуляция = абстрактный тип".
Ок, нивапрос.

G>>Лисков, Б.; Гатэг, Дж.
G>>"Использование абстракций и спецификаций при разработке программ"
F>На досуге попробую найти-почитать. Но сомневаюсь что там все упрощено до "инкапсуляция = абстракция".
Да, упрощено, на более чем 300 страницах. Вы когда-нибудь читали столько про одну "инкапсуляцию"? Книгу рекомендую, получите удовольствие.

F>Абстракция

struct { void foo(); void bar(); };

определяется только операциями foo и bar. Классы A и B являются не абстрактными, а вполне конкретными типами. И оба реализуют вышеуказанную абстракацию, так что клиент работающий с этой абстракцией может использовать и класс А, и класс B.

Путаете абстрактный класс и абстрактный тип данных. Несмотря на общее слово в названии, вещи совершенно разные. Абстрактный класс — у которого не бывает прямых экземпляров, т. е. который нельзя инстанцировать. Термин из ООП, позразумевает наличие иерархии наследования.
"Абстрактный тип данных" — термин не из ООП (но что парадоксально, знакомство с ADT позволит глубже понять принципы ООП). Что это такое, я уже объяснял, ссылки на литературу привел. В терминологии ООП ему соответствует просто "класс".

G>>Что такое табуретка? Если вы скажете, что это четыре ножки + сиденье, это не будет ADT. ADT для табуретки — нечто, на что можно сесть. Стул — это не табуретка, у которой есть спинка. Это то, на что (1) можно сесть и (2) при этом можно откинуться назад и не упасть.

F>Стул не является табуреткой. Стул и табуретка являются сиденьями. А сиденье — нечто, на что можно сесть.
Это уж как вы их определите. В моем примере стул и табуретка вообще не связаны отношением "являются". И это ровным счетом ничего не меняет.

F>Как правило незачем. Здесь я спорил с товарищами, утверждающими, что предоставление функций доступа без information hiding является инкапсуляцией. Я так не считаю.
Ну, со мной об этом спорить не надо. Как я говорил, я в таких терминах не рассуждаю.

F>>>Забавно, что сначала мне не нравилось толкование из Википедии, и я хотел найти более правильное, но теперь вижу что пришел к нему же:

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.

G>>Возможно. Меня как инженера не интересует information hiding. Это не привносит ничего интересного в процесс разработки и дизайна, если думаешь в терминах ADT. Тем более, не вижу смысла в маниакальном сокрытии данных в рамках одного проекта — люди и так узнают внутренности, если захотят — им достаточно просто спросить об этом автора . А если им не понятно, что такое public interface, то вопрос решается не техническими средствами, а простым обучением (хотя таких лучше на работу не брать).

G>>В случае если уж надо именно что-то скрыть (а на самом деле — обеспечить независимую разработку и удобство повторного использования, что несколько другое), я воспользуюсь компонентными технологиями — и опять же, information hiding я получу автоматически, не думая о нем специально при дизайне. Зачем вводить этот термин? Он не интересен, по крайней мере мне. Я не рассуждаю в таких терминах. Я не чувствую, что такой взгляд на вещи приносит мне какую-либо пользу как инженеру.

F>Если говорить о полезности/безполезности терминов, то зачем использовать два термина с одинаковой, по Вашему мнению, смысловой нагрузкой — абстракция и инкапсуляция?
Термин "инкапсуляция" применяется в контексте ООП, и понимается большинством именно как "сокрытие данных". Термин "абстракция" (в смысле абстракция данных/процедурная абстракция) не является распространенным и ходовым, я его применил (со ссылкой на литературу) только чтобы показать фактическое отсутствие разницы между концепцией ADT и ролью инкапсуляции в ООП. А вот термин Abstract Data Type применяется достаточно широко, и не обязательно в контексте ООП. Он в общем случае не требует соответствия языка принципам ООП. За ADT стоит своя теория, термин исторический, и его не перепутаешь с "сокрытием данных". Его нельзя понимать узко, как "инкапсуляцию". Я предпочитаю его, так как он позволяет избежать двусмысленных толкований, и не вызывает прямых ассоциаций с ООП.

F>Компонентные технологии здесь совершенно ни при чем. Чтобы узнать внутренности компонента, опять же достаточно спросить у автора , есть и другие способы.
Он может вам не сказать , а вы не сможете посмотреть. По крайней мере простым способом. Что и имеет место быть в случае, когда вы покупаете готовый ActiveX компонент, например (вот случай, когда надо необходимо скрыть реализацию). И они здесь очень даже причем — такой "способ инкапсуляции" не зависит от языка, и обеспечивает "надежное сокрытие данных". Здесь выше по ветке обсуждалось, какой язык обеспечивает "более надежную" инкапсуляцию, и это собственно мой ответ — никакой. Эту задачу решают компонентные технологии, только в их контексте такой разговор имеет смысл.

G>>C++ предоставляет адекватные средства для реализации ADT, причем все модификаторы необходимы. Почему именно они появились — вопрос с моей точки зрения праздный, главное, зачем они мне нужны. Ну, а за использование в С++ методов инкапсуляции, и прочих методов, унаследованных из С, я лично бью по рукам.
F>Бессмысленная жестокость
G>>Особенно, если автор не в состоянии внятно объяснить свою мотивацию — почему он не применяет "родные" методы С++.
F>Особенно, если автор вообще невменямый
"Уши мальчика на спине его. Он слушает, когда его бьют" (из древнеегипетских наставлений по обучению писцов)

Здравствуйте, Gaperton, Вы писали:

F>>Абстракция

struct { void foo(); void bar(); };

определяется только операциями foo и bar. Классы A и B являются не абстрактными, а вполне конкретными типами. И оба реализуют вышеуказанную абстракацию, так что клиент работающий с этой абстракцией может использовать и класс А, и класс B.

G>Путаете абстрактный класс и абстрактный тип данных. Несмотря на общее слово в названии, вещи совершенно разные. Абстрактный класс — у которого не бывает прямых экземпляров, т. е. который нельзя инстанцировать. Термин из ООП, позразумевает наличие иерархии наследования.
G>"Абстрактный тип данных" — термин не из ООП (но что парадоксально, знакомство с ADT позволит глубже понять принципы ООП). Что это такое, я уже объяснял, ссылки на литературу привел. В терминологии ООП ему соответствует просто "класс".

Вы несколько не правы, класс и абстрактный тип данных — не совсем одно и тоже. В общем случаее любой класс — есть абстрактный тип данных. Но, один класс может представлять несколько абстрактных типов данных, или ещё более правильно, то объект определённого класса, может иметь несколько абстрактных типов данных пример:

class SomeClassA : public InterfaceA, public InterfaceB
{
};

SomeClassA obj;

obj обладает несколькими абстрактными типами данных — SomeClassA, InterfaceA и InterfaceB
На этом основании этого свойства вы можете передавать ссылку на obj в выражения, где требуются ссылки на InterfaceA, InterfaceB и SomeClassA.

void foo1(const SomeClassA&);
void foo2(const InterfaceA&);
void foo3(const InterfaceB&);

foo1(obj); // ОК
foo2(obj); // ОК
foo3(obj); // ОК

Это всё справедливо для языков проповедующих классический подход реализации ООП, то есть то подход, где есть понятие класс и оно тесно связано с понятием объект (C++, C#, Java, Object Pascal и т.д.).

Здравствуйте, Mr. None, Вы писали:

G>>"Абстрактный тип данных" — термин не из ООП (но что парадоксально, знакомство с ADT позволит глубже понять принципы ООП). Что это такое, я уже объяснял, ссылки на литературу привел. В терминологии ООП ему соответствует просто "класс".

MN>Вы несколько не правы, класс и абстрактный тип данных — не совсем одно и тоже. В общем случаее любой класс — есть абстрактный тип данных. Но, один класс может представлять несколько абстрактных типов данных, или ещё более правильно, то объект определённого класса, может иметь несколько абстрактных типов данных пример:

Я прав , а то, что вы описываете, в теории типа называется "отношением подтипа" (чему в ООП соответствует термин "наследование"). Класс не "имеет" абстрактные типы данных, нет. Ситуация очевидна — один ADT (класс) "является подтипом" ("унаследован" от) другого ADT (класса). Вот и все, ничего сложного, как видите.

MN>

MN>class SomeClassA : public InterfaceA, public InterfaceB
MN>{
MN>};

MN>SomeClassA obj;
MN>

MN>obj обладает несколькими абстрактными типами данных — SomeClassA, InterfaceA и InterfaceB
MN>На этом основании этого свойства вы можете передавать ссылку на obj в выражения, где требуются ссылки на InterfaceA, InterfaceB и SomeClassA.

Obj — это не класс, а объект. И тип этого объекта obj вполне конкретен — это ADT SomeClassA, который является подтипом ADT InterfaceA и InterfaceB. Все три являются абстрактными типами данных, и они связаны отношением подтипа. Что и позволяет вам передавать его параметром в функцию, которая берет аргументом, например, InterfaceA (любое значение типа SomeClassA является также значением типа InterfaceA). Все просто.

Gaperton:

> F>Абстракция

struct { void foo(); void bar(); };

определяется только операциями foo и bar. Классы A и B являются не абстрактными, а вполне конкретными типами. И оба реализуют вышеуказанную абстракацию, так что клиент работающий с этой абстракцией может использовать и класс А, и класс B.
>
> Путаете абстрактный класс и абстрактный тип данных. Несмотря на общее слово в названии, вещи совершенно разные. Абстрактный класс — у которого не бывает прямых экземпляров, т. е. который нельзя инстанцировать. Термин из ООП, позразумевает наличие иерархии наследования.
> "Абстрактный тип данных" — термин не из ООП (но что парадоксально, знакомство с ADT позволит глубже понять принципы ООП). Что это такое, я уже объяснял, ссылки на литературу привел. В терминологии ООП ему соответствует просто "класс".

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

int main()
{
  A a;
  a.foo(5);
  return a.bar();
}

Используя А, клиент рассматривает его как абстракцию

struct A { void foo(int); int bar(); };

, все остальные функции/данные класса А клиента не интересуют. Теперь посмотрим на конкретную реализация этой абстракции:

struct A
{
  A(): _data(1) {}  

  void foo(int x) { _set_data( x ? x : 1 ); }
  int bar() const { return 1000 / x; }
  
  void _set_data(int x) { _data = x; }
  int _data;
};

Программа, состоящая из определения А и main() замечательно работает и без инкапсуляции. Пока клиент использует абстракцию, все в порядке. Если при клиент выйдет за пределы абстракции, например обратится непосредственно к _set_data или _data, то можем получить проблемы в виде деления на ноль или в виде чрезмерной связанности, что помешает нам в модификации кода А (читай — подстановке некой реализации B вместо текущей реализации А).
Чтобы пресечь такую возможность, мы с помощью сокрытия информации убираем детали реализации из открытого доступа, и получаем инкапсуляцию. Вот грубо, что я имел ввиду.
Если говорить об абстракции без инкапсуляции, то ничто, кроме соображений целесообразности, не мешает нам выйти за пределы абстракции. Даже используя абстрактный класс ООП мы можем выйти за пределы этой абстракции, например с помощью dynamic_cast.

> G>>Что такое табуретка? Если вы скажете, что это четыре ножки + сиденье, это не будет ADT. ADT для табуретки — нечто, на что можно сесть. Стул — это не табуретка, у которой есть спинка. Это то, на что (1) можно сесть и (2) при этом можно откинуться назад и не упасть.
>
> F>Стул не является табуреткой. Стул и табуретка являются сиденьями. А сиденье — нечто, на что можно сесть.
> Это уж как вы их определите. В моем примере стул и табуретка вообще не связаны отношением "являются". И это ровным счетом ничего не меняет.

Оперируя абстракцией "сиденье", мы будем выполнять над ней только операции "сесть"/"встать", но не "откинуться", даже если текущая реализация сиденья позволяет откинуться.

[]

> F>Компонентные технологии здесь совершенно ни при чем. Чтобы узнать внутренности компонента, опять же достаточно спросить у автора , есть и другие способы.
> Он может вам не сказать , а вы не сможете посмотреть.

Процитирую начало разговора:

G>Тем более, не вижу смысла в маниакальном сокрытии данных в рамках одного проекта — люди и так узнают внутренности, если захотят — им достаточно просто спросить об этом автора .
G>В случае если уж надо именно что-то скрыть (а на самом деле — обеспечить независимую разработку и удобство повторного использования, что несколько другое), я воспользуюсь компонентными технологиями

Говорилось про разработку в рамках одного проекта. Почему при компонентной разработке автор откажется показывать код, а при некомпонентной — согласится?

[]

Здравствуйте, folk, Вы писали:

F>Gaperton:

>> F>Абстракция

struct { void foo(); void bar(); };

определяется только операциями foo и bar. Классы A и B являются не абстрактными, а вполне конкретными типами. И оба реализуют вышеуказанную абстракацию, так что клиент работающий с этой абстракцией может использовать и класс А, и класс B.
>>
>> Путаете абстрактный класс и абстрактный тип данных. Несмотря на общее слово в названии, вещи совершенно разные. Абстрактный класс — у которого не бывает прямых экземпляров, т. е. который нельзя инстанцировать. Термин из ООП, позразумевает наличие иерархии наследования.
>> "Абстрактный тип данных" — термин не из ООП (но что парадоксально, знакомство с ADT позволит глубже понять принципы ООП). Что это такое, я уже объяснял, ссылки на литературу привел. В терминологии ООП ему соответствует просто "класс".

F>Такое трактование абстрактного типа данных вижу впервые, но этих двоих я точно не путаю.
Какое "такое"? ADT — тип данных который определяется операциями над ним (и ничем другим). О чем я уже вам писал. Я другого определения в литературе не встречал, а что на заборах написано меня мало интересует.

F> Надо вернуться назад и объяснить что я подразумевал под абстрактным типом или просто абстракцией. Абстрактный класс из ООП совершенно не при чем. Чтобы не усложнять, забудем также про наследование и возможность реализации конкретным типом нескольких абстракций.
F>Вот клиентский код, использующий класс А:
F>

F>int main()
F>{
F>  A a;
F>  a.foo(5);
F>  return a.bar();
F>}
F>

F>Используя А, клиент рассматривает его как абстракцию

struct A { void foo(int); int bar(); };

, все остальные функции/данные класса А клиента не интересуют. Теперь посмотрим на конкретную реализация этой абстракции:
F>

F>struct A
F>{
F>  A(): _data(1) {}  

F>  void foo(int x) { _set_data( x ? x : 1 ); }
F>  int bar() const { return 1000 / x; }
  
F>  void _set_data(int x) { _data = x; }
F>  int _data;
F>};
F>

Вы не используете средства языка для определения абстракции. О чем я вам уже писал. Если так писать на С++ — это либо (1) неграмотность, либо (2) не абстракция.

F>Программа, состоящая из определения А и main() замечательно работает и без инкапсуляции. Пока клиент использует абстракцию, все в порядке. Если при клиент выйдет за пределы абстракции, например обратится непосредственно к _set_data или _data, то можем получить проблемы в виде деления на ноль или в виде чрезмерной связанности, что помешает нам в модификации кода А (читай — подстановке некой реализации B вместо текущей реализации А).

Клиент имеет возможность так поступить потому, что работает не с ADT, а со структурой. Ему открыта реализация, и он, зная С++, и не зная того, что происходит в вашей голове, решит что это никакой не ADT. И будет совершенно прав — на языке С++ ADT пишется по другому. Вам, конечно, никто не сможет запретить считать это ADT "без сокрытия данных" (хоть такая штука и противоречит определению ADT). Не буду и я.

F>Чтобы пресечь такую возможность, мы с помощью сокрытия информации убираем детали реализации из открытого доступа, и получаем инкапсуляцию. Вот грубо, что я имел ввиду.
То, что вы имеете в виду, противоречит определению ADT и теории типа. О чем я вам уже писал. Не бывает ADT "без сокрытия данных", кроме ситуации, если мы вынуждены использовать соглашения (инкапсуляция не поддерживается языком). В языках типа С++ поступать так — неграмотность.

F>Если говорить об абстракции без инкапсуляции, то ничто, кроме соображений целесообразности, не мешает нам выйти за пределы абстракции. Даже используя абстрактный класс ООП мы можем выйти за пределы этой абстракции, например с помощью dynamic_cast.
Я не понимаю, о чем вы. Как-то очень мудрено. "Выход за пределы абстракции посредством dynamic_cast" это жесткий хардкор .

F>Оперируя абстракцией "сиденье", мы будем выполнять над ней только операции "сесть"/"встать", но не "откинуться", даже если текущая реализация сиденья позволяет откинуться.
Все понятно. Давайте оставим табуретки. Я не собираюсь доказывать, что разбираюсь в них лучше вас .

F>Процитирую начало разговора:
F>

G>>Тем более, не вижу смысла в маниакальном сокрытии данных в рамках одного проекта — люди и так узнают внутренности, если захотят — им достаточно просто спросить об этом автора .
G>>В случае если уж надо именно что-то скрыть (а на самом деле — обеспечить независимую разработку и удобство повторного использования, что несколько другое), я воспользуюсь компонентными технологиями

F>Говорилось про разработку в рамках одного проекта. Почему при компонентной разработке автор откажется показывать код, а при некомпонентной — согласится?

Независимая разработка — имелось в виду, когда в рамках одного проекта разработка ведется разными компаниями (такое бывает) и (возможно) по условиям контракта исходники и алгоритмы не должны быть раскрыты. Например. Вообще, у вас удивительная способность не понимать мои посты. Процитирую конец разговора:

Что и имеет место быть в случае, когда вы покупаете готовый ActiveX компонент, например (вот случай, когда надо необходимо скрыть реализацию).

Вот что здесь может быть непонятно? Это из моего поста, на который вы отвечаете. Как после этого примера можно думать, что я говорю о разработке в рамках одного проекта? Если у нас такие проблемы с взаимопониманием, то продолжать разговор нецелесообразно, ИМХО.

Gaperton:

Сначала проясню основные моменты, а потом отвечу на ваши реплики.

Камень преткновения — толкование термина абстракция. Вы понимаете абстракцию скорее как сокрытие деталей, я же понимаю как игнорирование или сокрытие деталей (для использования абстракции это неважно). Похоже ваше толкование навеяно определением ADT, не здесь имхо не стоит проводить таких прямых ассоциаций.

Если принять "ваш" термин ADT (я принимаю — поиск подтверждает ваше определение) то "мое" понятие инкапсуляции действительно очень близко к ADT. За ADT — спасибо.

Для полноты картины следует отметить, что мне встречались также определения инкапсуляции как объединения (в капсулу) без сокрытия. Например объединение нескольких переменных в структуру или превращение свободной функции в функцию-член класса. Но такое раздвоение термина лично мне не нравится.

> F>Такое трактование абстрактного типа данных вижу впервые, но этих двоих я точно не путаю.
> Какое "такое"? ADT — тип данных который определяется операциями над ним (и ничем другим). О чем я уже вам писал. Я другого определения в литературе не встречал, а что на заборах написано меня мало интересует.

Вот именно "такое". Я не возражал против такого определения ADT, но не путаю его с абстрактным классом из ООП. У вас тоже неслабая способность не понимать оппонента

> F>Программа, состоящая из определения А и main() замечательно работает и без инкапсуляции. Пока клиент использует абстракцию, все в порядке. Если при клиент выйдет за пределы абстракции, например обратится непосредственно к _set_data или _data, то можем получить проблемы в виде деления на ноль или в виде чрезмерной связанности, что помешает нам в модификации кода А (читай — подстановке некой реализации B вместо текущей реализации А).
>
> Клиент имеет возможность так поступить потому, что работает не с ADT, а со структурой.

Именно так.

> Ему открыта реализация, и он, зная С++, и не зная того, что происходит в вашей голове, решит что это никакой не ADT.

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

[скиппед, не буду отвечать на шпильки мой адрес, хорошо?]

> Я не понимаю, о чем вы. Как-то очень мудрено. "Выход за пределы абстракции посредством dynamic_cast" это жесткий хардкор .

здесь я похоже перегнул. На самом деле и при наследовании от абстрактного класса в C++ возможен дополнителный уровень сокрытия — приватное наследование от абстрактного класса — dynamic_cast to implementation не должен работать.

> F>Процитирую начало разговора:
> F>

> G>>Тем более, не вижу смысла в маниакальном сокрытии данных в рамках одного проекта — люди и так узнают внутренности, если захотят — им достаточно просто спросить об этом автора .
> G>>В случае если уж надо именно что-то скрыть (а на самом деле — обеспечить независимую разработку и удобство повторного использования, что несколько другое), я воспользуюсь компонентными технологиями
> F>

> F>Говорилось про разработку в рамках одного проекта. Почему при компонентной разработке автор откажется показывать код, а при некомпонентной — согласится?
>
> Независимая разработка — имелось в виду, когда в рамках одного проекта разработка ведется разными компаниями (такое бывает) и (возможно) по условиям контракта исходники и алгоритмы не должны быть раскрыты. Например.

Прямой зависимости между компонентностью и сокрытием исходников нет. Не забываем о статически компонуемых библитеках lib.

> Вообще, у вас удивительная способность не понимать мои посты. Процитирую конец разговора:
>

> Что и имеет место быть в случае, когда вы покупаете готовый ActiveX компонент, например (вот случай, когда надо необходимо скрыть реализацию).

> Вот что здесь может быть непонятно? Это из моего поста, на который вы отвечаете. Как после этого примера можно думать, что я говорю о разработке в рамках одного проекта? Если у нас такие проблемы с взаимопониманием, то продолжать разговор нецелесообразно, ИМХО.

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

Здравствуйте, folk, Вы писали:

F>Gaperton:

F>Сначала проясню основные моменты, а потом отвечу на ваши реплики.

F>Камень преткновения — толкование термина абстракция. Вы понимаете абстракцию скорее как сокрытие деталей, я же понимаю как игнорирование или сокрытие деталей (для использования абстракции это неважно). Похоже ваше толкование навеяно определением ADT, не здесь имхо не стоит проводить таких прямых ассоциаций.
Уточню свою позицию — я думаю она у нас отличается не сильно на самом деле. Хочу только отметить, что
1) В языках, которые позволяют скрыть реализацию, тип с публичными данными — это не ADT. Так как соглашения применять смысла нет. В таком случае говорим, что в языке есть поддержка инкапсуляции.
2) В языках, где все всегда "public", единственный способ определить ADT — применять соглашения, что к данным (некоторым функциям) обращаться нельзя. Такой язык не имеет поддержки инкапсуляции, и мы вынуждены применять соглашения. Что не есть гут, и в нашей теории этот прискорбный факт отражать негоже, бо просто незачем — и так понятно, что не от хорошей жизни это все. "ADT без инкапсуляции" — и есть попытка отразить сие безобразие в теории, на что я вам и указал . Вот и все.

К тому же, у вас примеры были на одном языке, на что я вам и отметил, что один из примеров ADT не является. Вот если бы вы привели один из примеров, например, на питоне, тогда вопросов бы не было. Там соглашения — единственный способ "скрыть" реализацию (определить ADT. Хотя, может я и отстал от жизни, и там появились закрытые члены класса). Но это скорее уже придирки с моей стороны.

F>Если принять "ваш" термин ADT (я принимаю — поиск подтверждает ваше определение) то "мое" понятие инкапсуляции действительно очень близко к ADT. За ADT — спасибо.
Не за что . Приятно, что из беседы получилась польза.

>> F>Такое трактование абстрактного типа данных вижу впервые, но этих двоих я точно не путаю.
>> Какое "такое"? ADT — тип данных который определяется операциями над ним (и ничем другим). О чем я уже вам писал. Я другого определения в литературе не встречал, а что на заборах написано меня мало интересует.

F>Вот именно "такое". Я не возражал против такого определения ADT, но не путаю его с абстрактным классом из ООП. У вас тоже неслабая способность не понимать оппонента
Не без этого. Просто пытаюсь для экономии времени предсказать ход мысли собеседника, заполняя непонятные моменты своими предположениями. Это — издержки подхода, то есть если уж не понял, то как надо не понял, ничего общего . Но чаще получается.

>> Я не понимаю, о чем вы. Как-то очень мудрено. "Выход за пределы абстракции посредством dynamic_cast" это жесткий хардкор .

F> здесь я похоже перегнул. На самом деле и при наследовании от абстрактного класса в C++ возможен дополнителный уровень сокрытия — приватное наследование от абстрактного класса — dynamic_cast to implementation не должен работать.
Ну, кстати, вот такое наследование не является отношением подтипа (т. е. это не есть "правильное" наследование в терминах классического ООП). Это, считай, специальный случай агрегации (с философской точки зрения, конечно). Потому, что тип не приведется еще и к базовому классу — такое отношение не удовлетворяет принципу подстановки Лисков (который и есть определение подтипа для ADT). Так что мы этот случай тоже не должны рассматривать специальным образом.

F>Прямой зависимости между компонентностью и сокрытием исходников нет. Не забываем о статически компонуемых библитеках lib.
Тоже метод.

F>Проблема во взаимопонимании была связана с произведенной вами подменой понятий. Разработка в рамках одного проекта неожданно превратилась в купленный ActiveX и будто бы аргументы, справедливые в случае ActiveX подтверждают вашу правоту и для единого проекта. Обвиняйте в этом себя, а не меня.
А я вас и не обвиняю. Непонимание — вещь обоюдная. Там на самом деле в двух абзацах рассматривалось два случая — разработка в одной команде (первый), разработка в распределенной команде, возможно силами нескольких фирм. Тезис такой:

Для одной команды надежное "сокрытие реализации" не имеет смысла, так как сами понимаете, какие секреты, все свои. Если человек при этом нарушает инкапсуляцию, его можно научить постредством "толстый железный проволока" (как это по русски? Лом!) по спине. Когда оно реально имеет смысл (примеры с купленным софтом/тонкостями копирайтов на разные куски софта), оно достигается не средствами языка (статические/динамические либы, компонентные технологии — you name it), так что тем более бессмысленно сравнивать языки по надежности сокрытия реализации (что происходило выше по ветке).

Мне все еще надо себя обвинять, или мы таки поняли друг друга?

Здравствуйте, Gaperton, Вы писали:

MN>>Вы несколько не правы, класс и абстрактный тип данных — не совсем одно и тоже. В общем случаее любой класс — есть абстрактный тип данных. Но, один класс может представлять несколько абстрактных типов данных, или ещё более правильно, то объект определённого класса, может иметь несколько абстрактных типов данных пример:

G>Я прав , а то, что вы описываете, в теории типа называется "отношением подтипа"
Не вижу противоречий — любой объект подтипа обладает как минимум 2-умя типами: прямым типом и типом предка.

G>(чему в ООП соответствует термин "наследование").
И тут вы не правы. В ООП нет ни слова об отношении тип-подтип — это объектное и структурное программирование, а ООП определяет отношение потомок-предок, что не всегда есть тип-подтип. В некоторых языках программирования реализация отношения потомок-предок выполняется через тип-подтип (классический подход реализации ООП) — это, например, C++. Но заметьте — это не обязательно, снвоа приведу в пример язык Self — это объектно-ориентированный язык, в котором есть понятие наследования, которое реализует отношение потомок-предок, но начисто отсутствует понятие типа (класса кстати тоже); наследование там реализуется в терминах объектов — один объект является предком другого.

G>Класс не "имеет" абстрактные типы данных, нет. Ситуация очевидна — один ADT (класс) "является подтипом" ("унаследован" от) другого ADT (класса). Вот и все, ничего сложного, как видите.

Вы всё сильно упрощаете. Тип — это абстракция времени компиляции, используемая для решения проблемы классификации выражений в языках со статической типизацией (правила подстановки типов проверяются компилятором при компиляции). Класс — это некоторая сущность, описывающая свойства объекта, она может существовать даже в период выполнения программы (объекты вы можете создавать и динамически).
Вот вам пример объектной системы, в которой понятия типа и класс разделены (я его уже приводил). Подсистема графического интерфейса Windows:
1) класс окна определяет свойства окна;
2) само окно — это объект определённого класса;
3) в программе ты имеешь доступ к нему через описатель, который определяет тип объекта для записи выражений языка программирования.

MN>>

MN>>class SomeClassA : public InterfaceA, public InterfaceB
MN>>{
MN>>};

MN>>SomeClassA obj;
MN>>

MN>>obj обладает несколькими абстрактными типами данных — SomeClassA, InterfaceA и InterfaceB
MN>>На этом основании этого свойства вы можете передавать ссылку на obj в выражения, где требуются ссылки на InterfaceA, InterfaceB и SomeClassA.

G>Obj — это не класс, а объект.
см. выше "объект определённого класса, может иметь несколько абстрактных типов данных". Я знаю, что obj — это объект и пока что в моих словах нет противоречия.

G>И тип этого объекта obj вполне конкретен — это ADT SomeClassA, который является подтипом ADT InterfaceA и InterfaceB. Все три являются абстрактными типами данных, и они связаны отношением подтипа. Что и позволяет вам передавать его параметром в функцию, которая берет аргументом, например, InterfaceA (любое значение типа SomeClassA является также значением типа InterfaceA). Все просто.

Уже ответил выше: "любой объект подтипа обладает как минимум 2-умя типами: прямым типом и типом предка"

Здравствуйте, Mr. None, Вы писали:

G>>Я прав , а то, что вы описываете, в теории типа называется "отношением подтипа"
MN>Не вижу противоречий — любой объект подтипа обладает как минимум 2-умя типами: прямым типом и типом предка.
У любого объекта один тип. Всегда. Если вы не начнете изобретать свою теорию (чем вы и занимаетесь), то она пойдет по мясницкий нож Оккама. Уже пошла.

G>>(чему в ООП соответствует термин "наследование").
MN>И тут вы не правы. В ООП нет ни слова об отношении тип-подтип — это объектное и структурное программирование, а ООП определяет отношение потомок-предок, что не всегда есть тип-подтип.
И тут я прав. Я вам говорю не свое мнение на тему что такое тип-подтип и прочие философские вопросы (как делаете вы), а о соотвествии терминологии из теории типа и ООП. А о чем говорите вы — не знаю.

MN>Вы всё сильно упрощаете.
Теория и должна все упрощать, в ней не бывает ничего лишнего. Я вам рассказываю о теории типа, а не о "мыслях, к которым я пришел, и которые мне очень дороги". В науке вовсю действует принцип "бритвы оккама". И вообще я сложные вещи не запоминаю, я не "мальчик с феноменальной памятью".

MN>Тип — это абстракция времени компиляции, используемая для решения проблемы классификации выражений в языках со статической типизацией (правила подстановки типов проверяются компилятором при компиляции). Класс — это некоторая сущность, описывающая свойства объекта, она может существовать даже в период выполнения программы (объекты вы можете создавать и динамически).
Вы забыли добавить одну из двух вещей, что делать необходимо, если вы с кем-то спорите. Либо ссылочку на печатную работу по теме, либо мааленькое слово ИМХО. Зачем мне вникать в ваше персональное понимание понятий "тип" и "класс", относительно которых весь остальной мир определился 20 лет назад? Есть на то какие-нибудь причины?

MN>Уже ответил выше: "любой объект подтипа обладает как минимум 2-умя типами: прямым типом и типом предка"
Вы бы ознакомились для начала с теорией типа — тем, что уже сделано в этой области. Поиск: type theory. А то ваши мысли слишком оригинальны, в них разобраться тяжело. Правда.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Mr. None, Вы писали:

G>>>Я прав , а то, что вы описываете, в теории типа называется "отношением подтипа"
MN>>Не вижу противоречий — любой объект подтипа обладает как минимум 2-умя типами: прямым типом и типом предка.
G>У любого объекта один тип. Всегда. Если вы не начнете изобретать свою теорию (чем вы и занимаетесь), то она пойдет по мясницкий нож Оккама. Уже пошла.
G>>>(чему в ООП соответствует термин "наследование").
MN>>И тут вы не правы. В ООП нет ни слова об отношении тип-подтип — это объектное и структурное программирование, а ООП определяет отношение потомок-предок, что не всегда есть тип-подтип.
G>И тут я прав. Я вам говорю не свое мнение на тему что такое тип-подтип и прочие философские вопросы (как делаете вы), а о соотвествии терминологии из теории типа и ООП. А о чем говорите вы — не знаю.

И я вам излагаю не своё мнение, более того, могу даже ссылки на авторитеты и книги привести.
Чтобы у вас не сложилось впечатление, что я философствую о сферических конях в вакууме вот вам конкретные примеры.
Язык Self — объектно-ориентированый, понятие типа отсутсвует напрочь, понятие класса отсутствует напрочь, наследование реализуется в терминах объектов: один объект создаёт другого и становится его предком, новый объект является для него потомком — отношение потомок-предок. Язык Volcano (основаный на параллельном прологе) — объектно-ориентированный, понятия типа отсутствует, понятие класса отстуствует, поэтому и наследование не может пониматься как отношение тип-подтип, объект представляется в виде бесконечного процесса вычисления продукционного правила (не спрашивайте что это такое — не отвечу).
Далее пример из области проектирования — классика ошибочное использование наследования:
класс реализующий очередь сообщения наследуют от класса списка, потому что они сходны по функциональности и у них есть функции со схожими сигнатурами — с точки зрения компилятора получилось отношение тип-подтип, с точки зрения здравого смысла очередь сообщений и список настолько далеки друг от друга, что не могут выступать как родственные сущности связанные отношением наследования (потомок-предок).
Достаточно?

MN>>Вы всё сильно упрощаете.
G>Теория и должна все упрощать, в ней не бывает ничего лишнего. Я вам рассказываю о теории типа, а не о "мыслях, к которым я пришел, и которые мне очень дороги". В науке вовсю действует принцип "бритвы оккама". И вообще я сложные вещи не запоминаю, я не "мальчик с феноменальной памятью".

Это конкретная реализация всё упрощает в частности вы говорите о реализации ООП, принятой в таких языках как C++, C#, Java, Object Prolog и т. д. Несмотря на то, что это очень распространённые языки — это далеко не самая лучшая реализация ООП (говорю это несмотря на то, что плюсы — это мой второй язык после русского) и сужать всю теорию ООП до наследования, инкапсуляции и полиморфизма как они представимы в C++ очень недальновидно.
Есть как минимум 2 подхода в реализации ООП:
1) принятая в плюсах, для неё в частности характерно статическое наследование (реализаемое через банальное копирование кода предка в код потомка при компиляции) и виртуальные вызовы;
2) принятая в Self`е — наследование через агрегацию и делегирование вызовов.

MN>>Тип — это абстракция времени компиляции, используемая для решения проблемы классификации выражений в языках со статической типизацией (правила подстановки типов проверяются компилятором при компиляции). Класс — это некоторая сущность, описывающая свойства объекта, она может существовать даже в период выполнения программы (объекты вы можете создавать и динамически).
G>Вы забыли добавить одну из двух вещей, что делать необходимо, если вы с кем-то спорите. Либо ссылочку на печатную работу по теме, либо мааленькое слово ИМХО.

Да, пожалуйста:
А. Элиенс. Принципы объектно-ориентированной разработки программ

G>Зачем мне вникать в ваше персональное понимание понятий "тип" и "класс", относительно которых весь остальной мир определился 20 лет назад?

Выходит, что ещё не определился.
Да и как насчёт примера относительно подсистемы графического пользовательского интерфейса Windows? Стало быть к нему у вас претензий нет?

G>А то ваши мысли слишком оригинальны, в них разобраться тяжело. Правда.
А я и не заставляю.

MN>Есть как минимум 2 подхода в реализации ООП:
MN>1) принятая в плюсах, для неё в частности характерно статическое наследование (реализаемое через банальное копирование кода предка в код потомка при компиляции) и виртуальные вызовы;
MN>2) принятая в Self`е — наследование через агрегацию и делегирование вызовов.

Забыл 3-ий подход — принятый в Volcano, но он слишком экзотический и скорее всего жить не будет, но меж тем всё равно он есть и отличается от других подходов.

Mr. None -> "Re[36]: Суть полимор"

MN> Чтобы у вас не сложилось впечатление, что я философствую о
MN> сферических конях в вакууме вот вам конкретные примеры.
MN> Язык Self — объектно-ориентированый, понятие типа отсутсвует
MN> напрочь, понятие класса отсутствует напрочь, наследование
MN> реализуется в терминах объектов: один объект создаёт другого и
MN> становится его предком, новый объект является для него потомком -
MN> отношение потомок-предок. Язык Volcano (основаный на параллельном
MN> прологе) — объектно-ориентированный, понятия типа отсутствует,
MN> понятие класса отстуствует, поэтому и наследование не может
MN> пониматься как отношение тип-подтип, объект представляется в виде
MN> бесконечного процесса вычисления продукционного правила (не
MN> спрашивайте что это такое — не отвечу).

Я таки сильно извиняюсь, но какая от этого конкретная польза?

Yury Kopyl aka hrg | Хоббиты — маздай! Мордовия — фарева

Здравствуйте, Mr. None, Вы писали:

MN>И я вам излагаю не своё мнение, более того, могу даже ссылки на авторитеты и книги привести.
Даже ссылки на авторитеты и книги? Не думал, что о том, что я не прав, пересказывая теорию типа, опубликованную в одних книгах, уже пишут в других.

MN>Чтобы у вас не сложилось впечатление, что я философствую о сферических конях в вакууме вот вам конкретные примеры.
MN>Достаточно?
Более чем, чтобы в очередной раз посоветовать вам ознакомится с теорией типа, прежде чем философствовать.

MN>Это конкретная реализация всё упрощает в частности вы говорите о реализации ООП, принятой в таких языках как C++, C#, Java, Object Prolog и т. д. Несмотря на то, что это очень распространённые языки — это далеко не самая лучшая реализация ООП (говорю это несмотря на то, что плюсы — это мой второй язык после русского) и сужать всю теорию ООП до наследования, инкапсуляции и полиморфизма как они представимы в C++ очень недальновидно.
Я-то как раз (в отличии от) говорю не о конкретной реализации, а о теории типа, близко к в варианту Лисков. Она не зависит от языка, и в общем случае перпендикулярна ООП. Что касается ООП, у него есть минимум два достаточно строгих определения. В данный момент я пользуюсь классическим (наследования, инкапсуляции и полиморфизма), которое на самом деле более общо, чем модель типов языков Smalltalk, С++, Java, etc.

MN>Да и как насчёт примера относительно подсистемы графического пользовательского интерфейса Windows? Стало быть к нему у вас претензий нет?
Она не имеет никакого отношения к теории типа, и языкам программирования. Мне на нее плевать. Спорить надоело, всего доброго.

Gaperton:

> Мне все еще надо себя обвинять, или мы таки поняли друг друга?

Похоже поняли. Обвинения сняты

Здравствуйте, hrg, Вы писали:

hrg>Mr. None -> "Re[36]: Суть полимор"

MN>> Чтобы у вас не сложилось впечатление, что я философствую о
MN>> сферических конях в вакууме вот вам конкретные примеры.
MN>> Язык Self — объектно-ориентированый, понятие типа отсутсвует
MN>> напрочь, понятие класса отсутствует напрочь, наследование
MN>> реализуется в терминах объектов: один объект создаёт другого и
MN>> становится его предком, новый объект является для него потомком -
MN>> отношение потомок-предок. Язык Volcano (основаный на параллельном
MN>> прологе) — объектно-ориентированный, понятия типа отсутствует,
MN>> понятие класса отстуствует, поэтому и наследование не может
MN>> пониматься как отношение тип-подтип, объект представляется в виде
MN>> бесконечного процесса вычисления продукционного правила (не
MN>> спрашивайте что это такое — не отвечу).

hrg>Я таки сильно извиняюсь, но какая от этого конкретная польза?

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

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Mr. None, Вы писали:

MN>>И я вам излагаю не своё мнение, более того, могу даже ссылки на авторитеты и книги привести.
G>Даже ссылки на авторитеты и книги? Не думал, что о том, что я не прав, пересказывая теорию типа, опубликованную в одних книгах, уже пишут в других.

Вот только не нало поясничать.. Я привёл вам ссылку на книгу, почитайте на досуге, узнаете очень много нового.

MN>>Чтобы у вас не сложилось впечатление, что я философствую о сферических конях в вакууме вот вам конкретные примеры.
MN>>Достаточно?
G>Более чем, чтобы в очередной раз посоветовать вам ознакомится с теорией типа, прежде чем философствовать.

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

MN>>Это конкретная реализация всё упрощает в частности вы говорите о реализации ООП, принятой в таких языках как C++, C#, Java, Object Prolog и т. д. Несмотря на то, что это очень распространённые языки — это далеко не самая лучшая реализация ООП (говорю это несмотря на то, что плюсы — это мой второй язык после русского) и сужать всю теорию ООП до наследования, инкапсуляции и полиморфизма как они представимы в C++ очень недальновидно.
G>Я-то как раз (в отличии от) говорю не о конкретной реализации, а о теории типа, близко к в варианту Лисков.
А причём здесь теория типов, если речь зашла об ООП?

G>Она не зависит от языка, и в общем случае перпендикулярна ООП.
Вот тут вы абсолютно правы, но при этом противоречите остальным своим высказываниям.

G>Что касается ООП, у него есть минимум два достаточно строгих определения. В данный момент я пользуюсь классическим (наследования, инкапсуляции и полиморфизма), которое на самом деле более общо, чем модель типов языков Smalltalk, С++, Java, etc.

Будьте добры приведите хоть одно. То что вы подразумеваете под определением основаным на наследование, инкапсуляцие и полиморфизме — это не определение, а одна из реализаций модели или выражаясь иным языком — знаковой системы — именуемой ООП. Есть и другие реализации, вот только давать определение модели по её реализации нельзя. Для начала будьте добры сформулируйте основные положения модели и докажите её полноту и непротиворечивость, а уж после этого бросайтесь определениями самой модели! Что не можете? И это понятно, потому что пока что ещё никому не удалось подвести под ООП строгую математическую базу — только философские заключения. В отличие от теории типов, которая прочно сидит на теории множеств. Поэтому, например, ваше заявление о "соотвествии терминологии из теории типа и ООП" просто несостоятельно — они не могут соответствовать потому что терминология теории типов жёстко определена, а терминология ООП весьма расплывчата. Это как с фракталами, все понимают, что такое фрактал, все могут привести несколько десятков реализаций, но никто не может дать чёткого определения.
И если уж на то пошло, то "наследование, инкапсуляция, полиморфизм" — это очень узкая реализация. Есть более широкие определения, включающие в том числе и данную (НИП), я привёл ссылку на книгу, где расказывается об одной из них.