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

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

_>>Всех тонкостей не помню, но в дружественной функции вроде можно кастовать к приватному базовому типу.
S>Можем, да. Вот такой вот ограниченный получается полиморфизм.

А как же утверждение "полиморфизма нет"?

_>>Что такое "наследование"?
S>Наследование — это отношение is-a. В конкретных языках оно может быть реализовано несколько по-разному, но в целом обычно мы наблюдаем следующие черты:
S>1. Subtyping между родителем и наследником, следствием которого является совместимость по присваиванию ссылок и указателей.
S>2. Наследование состояния: каждый экземпляр потомка содержит в себе полное состояние предка (используется для обеспечения п.1)
S>3. Наследование поведения: все экземплярные методы предка работают и на потомке. Поведение статических методов и конструкторов зависит от вкусов дизайнеров языка; как правило, они не наследуются.
S>4. Полиморфизм экземплярных методов: потомок может переопределять некоторые методы предка, меняя их поведение.

_>>Достаточно написать "class B: private A" и мы получаем агрегацию/композицию, а не наследование.
S>Вы бы всё же разобрались в основах. Всего четыре термина в ветке, а вы уже сорок постингов отказываетесь принять их общепринятые определения.
S>В частности, приватное наследование — это всё же наследование, а вовсе не агрегация.

А как же "is-a"? А композиция/агрегирование, которое реализовано через приватное наследование, ближе к инкапсуляции, чем к наследованию.

_>>Для полноты картины: что такое инкапсуляция и полиморфизм?
S>Инкапсуляция — возможность предоставлять различные контракты различному коду. В самом примитивном виде мы отличаем "внутренний" код от "внешнего" (секции interface и implementation в классическом Паскале или ); в более интересном виде мы можем отличать "код потомков данного класса в любой сборке", "код посторонних классов в данной сборке", и т.п.

Какие контракты? Что за различный код? Мне кажется ты продвигаешь другую теорию под видом определений ООП.
Инкапсуляция — это ограничение доступа к внутренностям объекта из-вне, а еще объединение данных и алгоритмов обрабатывающих с этими данные.

S>Про полиморфизм всё уже сказано здесь: http://rsdn.ru/forum/philosophy/2853873

Автор: Gaperton
Дата: 26.02.08

Хочу заметить что там сказано что наследование — это механизм параметрического полиморфизма, а предыдущий оратор пишет что это механизм ad-hoc полиморфизма. Кто-то врет.

Ad-hoc полиморфизм — это виртуальные функции, и наследование тут поскольку-постольку, можно другие механизмы использовать для виртуальных функций.

Признаю свое поражение. Перехожу в режим read only.

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

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

_>>Для полноты картины: что такое инкапсуляция и полиморфизм?
S>Инкапсуляция — возможность предоставлять различные контракты различному коду. В самом примитивном виде мы отличаем "внутренний" код от "внешнего" (секции interface и implementation в классическом Паскале или ); в более интересном виде мы можем отличать "код потомков данного класса в любой сборке", "код посторонних классов в данной сборке", и т.п.

Я бы сказал что инкапсуляция это сокрытие деталей в общем случае. Деталями может быть все что угодно от данных до способов, алгоритмов. Понятие инкапсуляции двойственно абстракции. Т.е. как только мы от чего-то абстрагировались, значит мы скрыли какую-то деталь.
* Слой аппаратных абстракций (HAL) скрывает (инкапсулирует) различия в аппаратном обеспечении;
* fopen/FILE инкапсулирует детали взаимодействия с файловой системой;
* std::vector<T> инкапсулирует особенности реализации абстрактного типа данных "динамический массив";
* template <...> void sort (RandomAccessIterator first, RandomAccessIterator last, Compare comp) инкапсулирует как метод сортировки, так и детали его реализации. Точно так же инкапсулируются сортируемые данные, способ их хранения и способ сравнения значений, но в обратном направлении. Т.е. эти особенности скрываются от реализации sort.
Таким образом, у нас в общем случае может не быть отличий "внутренний/внешний", как и модификаторов видимости. Инкапсуляция работает на уровне "знаем/не знаем" особенность.

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

_>Какие контракты? Что за различный код? Мне кажется ты продвигаешь другую теорию под видом определений ООП.
ООП не определяет эти термины, оно их только использует, причем строго ограниченную часть.

_>Инкапсуляция — это ограничение доступа к внутренностям объекта из-вне, а еще объединение данных и алгоритмов обрабатывающих с этими данные.
Ограничение доступа — частный случай. А к объединению данных и алгоритмов вообще никакого отношения. Алгоритмы могут быть разбросаны, это только увеличивает инкапсуляцию (http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197).

S>>Про полиморфизм всё уже сказано здесь: http://rsdn.ru/forum/philosophy/2853873

Автор: Gaperton
Дата: 26.02.08

_>
_>Хочу заметить что там сказано что наследование — это механизм параметрического полиморфизма, а предыдущий оратор пишет что это механизм ad-hoc полиморфизма. Кто-то врет.
Наследование — это проявление ограниченного параметрического полиморфизма. Чистый параметрический полиморфизм работает для всех типов одинаково. А наследование позволяет использовать только типы, являющиеся наследниками (и то не всегда). Т.е. некоторые аспекты параметрического полиморфизма проявляются, но не вполне, значит относить наследование к параметрическому полиморфизму нельзя.

_>Ad-hoc полиморфизм — это виртуальные функции, и наследование тут поскольку-постольку, можно другие механизмы использовать для виртуальных функций.
Виртуальные функции — лишь частный случай ad-hoc полиморизма. Так же к нему относятся перегрузка операторов и функций, duck typing, late binding, multimethods (multiple dispatch), а так же подмножество pattern matching-а для некоторых языков.
И не для, а вместо. Под виртуальными функциями подразумевается вполне конкретный механизм.

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

_>А как же "is-a"? А композиция/агрегирование, которое реализовано через приватное наследование, ближе к инкапсуляции, чем к наследованию.

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

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

_>Достаточно написать "class B: private A" и мы получаем агрегацию/композицию, а не наследование.

Ну да, как же. Посмотри в сторону вирутальных деструкторов, например. За Приватную базу объектом владеть таки можно, а через поле, хоят бы и публичное -- нет. Так что получаем, что в С++ наследование и инкапсуляция никак не связаны. Можно быть чьим-то наследником, но скрывать это, например. Или скрывать это от всех, кроме своих наследников и друзей, как вариант

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

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

S>>Про полиморфизм всё уже сказано здесь: http://rsdn.ru/forum/philosophy/2853873

Автор: Gaperton
Дата: 26.02.08

_>
_>Хочу заметить что там сказано что наследование — это механизм параметрического полиморфизма, а предыдущий оратор пишет что это механизм ad-hoc полиморфизма. Кто-то врет.
Давай на примере объясню.
Дано:

abstract class Base
{
 public abstract void F();
}

class A : Base
{
  public override void F() { Console.WriteLine("A"); }
}

class B : Base
{
  public override void F() { Console.WriteLine("B"); }
}

Использование:

Base o = ...
o.F(); // тут ad-hoc полиморфизм - выбор реализации метода делается на основе фактического типа переменной 'o'

Еще:

void DoSomething(int n, Base o)
{
  for(int i=0; i<n; ++i)
    o.F();
}

Метод DoSomething параметрически полиморфен по параметру 'o', в том смысле, что одна и та же реализация для любого наследника Base.

Чтобы это стало очевидней, определение DoSomething по смыслу ближе всего к следующему:

void DoSomething<T>(int n, T o)
  where T: Base
{
  for(int i=0; i<n; ++i)
    o.F();
}

В этом смысле наследование это "механизм параметрического полиморфизма" — оно нужно чтобы иметь возможность писать такие вот параметрически полиморфные методы; без такой возможности оно нафиг не нужно.

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

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

S>>>Про полиморфизм всё уже сказано здесь: http://rsdn.ru/forum/philosophy/2853873

Автор: Gaperton
Дата: 26.02.08

_>>
_>>Хочу заметить что там сказано что наследование — это механизм параметрического полиморфизма, а предыдущий оратор пишет что это механизм ad-hoc полиморфизма. Кто-то врет.
A>Давай на примере объясню.
A>Дано:

пример не наследования а перегрузки (override). А что такое перегрузка функций? Подсказка, это не параметрический полиморфизм.

Вот пример наследования и параметрического полиморфизма:
class A { add(A) }
class B : A
class C : A

a.add(a)
b.add(b)
c.add(c)

A>В этом смысле наследование это "механизм параметрического полиморфизма" — оно нужно чтобы иметь возможность писать такие вот параметрически полиморфные методы; без такой возможности оно нафиг не нужно.
Ничегонепонял, но ты прав.

Вроде, тебе я еще не сдавался. Сдаюсь.

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

_>>Что такое "наследование"?
S>Наследование — это отношение is-a.
К сожалению на определение — это не тянет.
если я напишу class Man: Fish {} — это наследование или нет??

S>В конкретных языках оно может быть реализовано несколько по-разному, но в целом обычно мы наблюдаем следующие черты:
выделение убивает ценность этих пунктов напрочь.
S>1. Subtyping между родителем и наследником, следствием которого является совместимость по присваиванию ссылок и указателей.
S>2. Наследование состояния: каждый экземпляр потомка содержит в себе полное состояние предка (используется для обеспечения п.1)
S>3. Наследование поведения: все экземплярные методы предка работают и на потомке. Поведение статических методов и конструкторов зависит от вкусов дизайнеров языка; как правило, они не наследуются.
S>4. Полиморфизм экземплярных методов: потомок может переопределять некоторые методы предка, меняя их поведение.

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

_>пример не наследования а перегрузки (override).
overload — перегрузка, override — переопределение
_>А что такое перегрузка функций? Подсказка, это не параметрический полиморфизм.
Перегрузка (которая overload) по типу параметров — статический ad-hoc полиморфизм

_>Вот пример наследования и параметрического полиморфизма:
_>class A { add(A) }
_>class B : A
_>class C : A

_>a.add(a)
_>b.add(b)
_>c.add(c)
Тут да, метод add параметрически полиморфен по обоим параметрам.

Здравствуйте, fin_81, Вы писали:
_>А как же утверждение "полиморфизма нет"?
Снаружи — нет.

_>А как же "is-a"? А композиция/агрегирование, которое реализовано через приватное наследование, ближе к инкапсуляции, чем к наследованию.
Я же написал, как именно.

_>Какие контракты? Что за различный код? Мне кажется ты продвигаешь другую теорию под видом определений ООП.
_>Инкапсуляция — это ограничение доступа к внутренностям объекта из-вне, а еще объединение данных и алгоритмов обрабатывающих с этими данные.
Я просто смотрю правде в глаза. Чтобы приблизить ваше понимание инкапсуляции к настоящему, нужно дать себе труд задуматься о том, что такое "внутренности" и что такое "извне". Внезапно окажется, что реальное программирование оперирует не чёрно-белым миром private/public, а значительно более интересными градациями.

_>Хочу заметить что там сказано что наследование — это механизм параметрического полиморфизма, а предыдущий оратор пишет что это механизм ad-hoc полиморфизма. Кто-то врет.
Нет, кто-то не понимает. Чтобы осмысленно обсуждать тему, нужно разбираться, какое значение имеет каждое слово.
Если вы пишете (обычный!) метод, который принимает в качестве аргумента ссылку на A, то получаем параметрический полиморфизм. Понятно, почему, или надо разжёвывать?
Когда вы перегружаете виртуальный метод, то получаете ad-hoc полиморфизм. Понятно, почему, или надо разжёвывать?

_>Ad-hoc полиморфизм — это виртуальные функции, и наследование тут поскольку-постольку, можно другие механизмы использовать для виртуальных функций.
Виртуальные функции — это как раз механизм. А наследование — это концепция. То, что вы называете "другие механизмы", скорее всего, виртуальными функциями не является.

_>Признаю свое поражение. Перехожу в режим read only.
Давно пора.

Здравствуйте, samius, Вы писали:
S>Я бы сказал что инкапсуляция это сокрытие деталей в общем случае. Деталями может быть все что угодно от данных до способов, алгоритмов. Понятие инкапсуляции двойственно абстракции. Т.е. как только мы от чего-то абстрагировались, значит мы скрыли какую-то деталь.
S>* Слой аппаратных абстракций (HAL) скрывает (инкапсулирует) различия в аппаратном обеспечении;
S>* fopen/FILE инкапсулирует детали взаимодействия с файловой системой;
S>* std::vector<T> инкапсулирует особенности реализации абстрактного типа данных "динамический массив";
S>* template <...> void sort (RandomAccessIterator first, RandomAccessIterator last, Compare comp) инкапсулирует как метод сортировки, так и детали его реализации. Точно так же инкапсулируются сортируемые данные, способ их хранения и способ сравнения значений, но в обратном направлении. Т.е. эти особенности скрываются от реализации sort.
S>Таким образом, у нас в общем случае может не быть отличий "внутренний/внешний", как и модификаторов видимости. Инкапсуляция работает на уровне "знаем/не знаем" особенность.
Детали — это некий контракт. Инкапсуляция как сокрытие означает, что кусок кода номер 1 "видит" не то, что кусок кода номер 2.
Всё, что "видит" код — это некий контракт.
С точки зрения метода Method1 объект типа А оборудован единственным методом ToString(). А с точки зрения метода Method2() у объекта типа А есть ещё и куча полей, методов, и прочих штук. При этом компилятор всё ещё проверяет соответствие использования объектов класса A в коде Method2 некоторому контракту. Какому именно — зависит от того, где объявлен этот Method2 — в самом классе A, в классе, унаследованном от класса A, в той же сборке, что и класс A, и так далее.
Если мы не можем отличить, является ли код внутренним или внешним, то компилятор не сможет проверить корректность использования контрактов — а, стало быть, никакой инкапсуляции не получится.

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

J>К сожалению на определение — это не тянет.

J>если я напишу class Man: Fish {} — это наследование или нет??
Наследование. А что вас не устраивает?

S>>В конкретных языках оно может быть реализовано несколько по-разному, но в целом обычно мы наблюдаем следующие черты:
J>выделение убивает ценность этих пунктов напрочь.
У вас есть какое-то более другое определение?

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

0>>Теоретическая чистота когда — это как?

J>Или там "из функции должен быть только один выход", потому что типа Дейкстра доказал, что такие функции лучше — и поэтому начинаются пляски с тем же goto, лишь бы return в середине функции не написать.

Прошу прощения, что вмешиваюсь. И наверняка обсуждение на эту тему встречается, и поэтому писать стоило бы туда.
Цитата на всякий случай..
из "Чистый код" Р. Мартина (гл. 3, "Функции"):

Структурное программирование

Некоторые программисты следуют правилам структурного программирования, изложенным Эдгаром Дейкстрой [SP72]. Дейкстра считает, что каждая функция и каждый блок внутри функции должны иметь одну точку входа и одну точку выхода. Выполнение этого правила означает, что функция должна содержать только одну команду return, в циклах не должны использоваться команды break или continue, а команды goto не должны использоваться никогда и ни при каких условиях.

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

Итак, если ваши функции остаются очень компактными, редкие вкрапления множественных return, команд break и continue не принесут вреда, а иногда даже повышают выразительность по сравнению с классической реализацией с одной точкой входа и одной точкой выхода. С другой стороны, команда goto имеет смысл только в больших функциях, поэтому ее следует избегать.

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

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

J>>К сожалению на определение — это не тянет.
S>
J>>если я напишу class Man: Fish {} — это наследование или нет??
S>Наследование. А что вас не устраивает?
тем, что Man is NOT a fish.

S>>>В конкретных языках оно может быть реализовано несколько по-разному, но в целом обычно мы наблюдаем следующие черты:
J>>выделение убивает ценность этих пунктов напрочь.
S>У вас есть какое-то более другое определение?

если бы было, я б в эту ветку встревал. Максимум что я могу придумать, что наследование — это элемент синтаксиса. ну вот сказал Хейлсберг: "В C# если MyChild определен как 'class MyChild: MyParent', то будем говорить, что MyChild наследуется от MyParent" — вот и появилось в C# наследование. А если б Хейсберг сказал "..., то будем говорить, что MyChild куксится от MyParent" — было в C# куксение, а наследования не было. А отношение is a — не в тему, оно в мозгу программиста сидит, а не в ЯП. И реализовать его можно вагоном разных способов реализовать, ну там, перекрыть оператор неявного приведения типов, например.

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

J>если бы было, я б в эту ветку НЕ встревал.

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

S>Здравствуйте, samius, Вы писали:
S>>Таким образом, у нас в общем случае может не быть отличий "внутренний/внешний", как и модификаторов видимости. Инкапсуляция работает на уровне "знаем/не знаем" особенность.
S>Детали — это некий контракт. Инкапсуляция как сокрытие означает, что кусок кода номер 1 "видит" не то, что кусок кода номер 2.
"Видит" — это немного не то. Вот допустим что мой код видит (и может безболезненно для компиляции использовать) безобразное количество идентификаторов, начинающихся с _, __. Так вот, инкапсуляция начинается там где приходит понимание того факта, что если я не хочу обнаружить непредсказуемое поведение вызываемого мной кода, или не хочу переписывать код при обновлении библиотеки, я не должен юзать эти идентификаторы.
Вместе с тем, модификаторы доступа ограничивают не видимость, а именно доступ.

S>Всё, что "видит" код — это некий контракт.
Изначально контракт — это все что документировано. А разметка модификаторами доступа, как и другие способы управления видимостью — это только делегирование компилятору проверки соответствия контракту, защита от Буратин, не читающих документацию.
Позже при отсутствии документации мы стали пытаться восстанавливать контракт по видимым/публичным артефактам. Но это вовсе не значит что обнаружив публичный метод с названием __не_вызывай_меня_никогда_все_сломается___совсем(), следует его первым делом вызвать.

S>С точки зрения метода Method1 объект типа А оборудован единственным методом ToString(). А с точки зрения метода Method2() у объекта типа А есть ещё и куча полей, методов, и прочих штук. При этом компилятор всё ещё проверяет соответствие использования объектов класса A в коде Method2 некоторому контракту. Какому именно — зависит от того, где объявлен этот Method2 — в самом классе A, в классе, унаследованном от класса A, в той же сборке, что и класс A, и так далее.
S>Если мы не можем отличить, является ли код внутренним или внешним, то компилятор не сможет проверить корректность использования контрактов — а, стало быть, никакой инкапсуляции не получится.
Проверка компилятором корректности использования контрактов вторична. Вот возьмем тот же WinAPI. Контракты есть, а модификаторов нет. И компилятор не ограничивает нас от того что бы послать любое сообщение любому Handle-у. Кто скажет что в WinAPI нет инкапсуляции?

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

S>>В общем случае для второго класса нехарактерно владение таким уровнем классификации. В быту многие до пенсии (и после) называют все металлические предметы железяками.
S>Это понятно. Непонятно такое же невладение на профессиональном форуме.
S>Ну, то есть оно, наверное, объяснимо — какие-то негодяи тридцать лет внедряли мисконцепцию "ООП = инкапсуляция, наследование, полиморфизм", что привело к смешенью умов. Но всё равно вызывает разочарование как само невладение, так и отказ воспринимать корректную картину мира.

Ну, дык, был спор про парадигмы когда-то... Установили, что ООП — это "всего лишь" парадигма. А парадигма — это некая совокупность устоявшихся практических подходов к решению задач + инструментарий, всё вместе образующие "культуру дизайна в рамках ХХХ", "взгляд на проблему" и прочие плохо формулируемые вещи. Характерно, что в том споре никто не набирался смелости утверждать (как здесь), что составляющие этой "совокупности" могут входить только в одну парадигму.

З.Ы. Да и вообще... давно пора составить каталог ссылок на обсуждения прошлых лет здесь и стрелять ими сразу же в ответ... Бо на качественное обсуждение, смотрю, ни у кого давно не "стоит". ((

Здравствуйте, Jack128, Вы писали:
S>>Наследование. А что вас не устраивает?
J>тем, что Man is NOT a fish.
Непонятно, откуда вы это взяли. В том языке, где вы можете так написать, Man вполне себе a Fish.

J>если бы было, я б в эту ветку встревал. Максимум что я могу придумать, что наследование — это элемент синтаксиса. ну вот сказал Хейлсберг: "В C# если MyChild определен как 'class MyChild: MyParent', то будем говорить, что MyChild наследуется от MyParent" — вот и появилось в C# наследование.
Лично мне ближе семантика, а не синтаксис.

А если б Хейсберг сказал "..., то будем говорить, что MyChild куксится от MyParent" — было в C# куксение, а наследования не было. А отношение is a — не в тему, оно в мозгу программиста сидит, а не в ЯП. И реализовать его можно вагоном разных способов реализовать, ну там, перекрыть оператор неявного приведения типов, например.
Имхо, у вас в голове какая-то каша.
is-a, в общефилософском смысле, выражается исключительно в виде LSP.
Когда мы рассматриваем LSP в конкретном языке программирования, абстрактный принцип превращается в конкретные утверждения. Типа "объект класса B можно передать в любой метод, принимающий аргументы класса A".

И вот если оказывается, что "куксение" реализует LSP, то мы говорим, что "в C# куксение является разновидностью ООП-шного наследования".

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

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

S>>Здравствуйте, samius, Вы писали:
S>>>Таким образом, у нас в общем случае может не быть отличий "внутренний/внешний", как и модификаторов видимости. Инкапсуляция работает на уровне "знаем/не знаем" особенность.
S>>Детали — это некий контракт. Инкапсуляция как сокрытие означает, что кусок кода номер 1 "видит" не то, что кусок кода номер 2.
S>"Видит" — это немного не то. Вот допустим что мой код видит (и может безболезненно для компиляции использовать) безобразное количество идентификаторов, начинающихся с _, __. Так вот, инкапсуляция начинается там где приходит понимание того факта, что если я не хочу обнаружить непредсказуемое поведение вызываемого мной кода, или не хочу переписывать код при обновлении библиотеки, я не должен юзать эти идентификаторы.
S>Вместе с тем, модификаторы доступа ограничивают не видимость, а именно доступ.
Это понятно. Инкапсуляция — это, конечно же, явление, а не механизм. Однако когда мы говорим о поддержке инкапсуляции в языке, мы ожидаем от компилятора проверки всех этих "я не должен".

S>Изначально контракт — это все что документировано. А разметка модификаторами доступа, как и другие способы управления видимостью — это только делегирование компилятору проверки соответствия контракту, защита от Буратин, не читающих документацию.
Лично моя точка зрения — в том, что в контексте языков программирования рассматривать документацию бессмысленно. С точки зрения документации, все языки обладают одинаковой выразительной силой. Интересны те контракты, которые можно выразить в языке — всё точно так же, как с инкапсуляцией. Контракт как явление существует независимо от языка, но поддержка контрактов всё же требуется.

S>Позже при отсутствии документации мы стали пытаться восстанавливать контракт по видимым/публичным артефактам. Но это вовсе не значит что обнаружив публичный метод с названием __не_вызывай_меня_никогда_все_сломается___совсем(), следует его первым делом вызвать.

Названия методов — ни о чём. Также как и аргумент с именем pleaseDontPassNullHere.

S>Проверка компилятором корректности использования контрактов вторична. Вот возьмем тот же WinAPI. Контракты есть, а модификаторов нет. И компилятор не ограничивает нас от того что бы послать любое сообщение любому Handle-у. Кто скажет что в WinAPI нет инкапсуляции?
Инкапсуляция там — в том, что вы не можете напрямую работать с внутренним состоянием контрола. Контракт, выраженный в терминах WinAPI, у всех контролов ровно один — SendMessage().
То, что контролы ведут себя существенно по разному в ответ на разные значения аргументов этого единственного метода "сделайВсё" — это недостаток выразительности в выбранном языке/платформе.
Неспроста первое, что делают все ООП-шные UI фреймворки под винапи — это определяют иерархию классов с методами, чтобы отойти от нетимизированного и непроверяемого SendMessage().

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

S>is-a, в общефилософском смысле, выражается исключительно в виде LSP.
S>Когда мы рассматриваем LSP в конкретном языке программирования, абстрактный принцип превращается в конкретные утверждения. Типа "объект класса B можно передать в любой метод, принимающий аргументы класса A".
ну вот мне эти конкретные утверждения и нужны.
Если я перекрою неявное преобразование типов из B в A, то экземпляр B можно будет передать в любой метод, принимающий A. Значит ли это, что B — наследник A ??? Если нет, то почему?