Ответ на »сообщение 964« (12)
___________________________

Имеем описание последовательности вызова методов, осуществляемых модулем. Короче алгоритм имеем. Почему нельзя сказать реализует ли другой модуль этот алгоритм, или нет? В интерфейсе.

Сказать можно, а гарантировать - вряд ли.

Последовательность вызовов - это алгоритм? Уж если говорить о безболезненности замены и контроле такой безболезненности, то по-хорошему требуется формальный протокол оперирования сущностями, представленными в интерфейсе, а также средства его обеспечения. Если Вам известны примеры такого в языках програмирования - приведите, можно будет разобрать.

Может ли в интерфейсе быть описан алгоритм (в полном смысле этого слова, а не просто вырожденная последовательность вызовов)? Если может, то чем он отличается от реализации и где проходит грань между алгоритмом в интерфейсе и алгоритмом в реализации (что подвергается абстрагированию?).

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

Разница между Java-классами и Оберон-модулями в том и состоит, что класс подразумевает принудительный (автоматический) интерфейс, а модуль - добровольный (ручной). Здесь вполне по делу упоминался принцип "No paranoia rule" Клеменса Шиперского.

Вводя новыми интерфейсами новые слои абстракции мы за видимую свободу безболезненного манипулирования платим потерей контроля над реализацией.

Ответ на »сообщение 960« (Сергей Перовский)
___________________________

Ответ на »сообщение 959« (AVC)
___________________________
По моему, наиболее полное соответствие теории множеств у ОО подхода с наследованием только по реализации: если некоторый объект входит в множество A, которое является подмножеством B, то он обладает всеми свойствами элементв B. Без всяких "ведет себя аналогично" или "с точки зрения...".
Он просто является элементом множества B.
Очевидно, это просто частный случай. А математики обобщать любят.

Ответ на »сообщение 956« (Варяжский Гость)
___________________________

Интерфейс сам по себе имеет побочные эффекты. Выделение описательной части из реализации не такое безболезненное, как может показаться: интерфейс может неявно тянуть за собой нюансы реализации. К тому же если интерфейс понимать как чисто декларативную часть, где собраны представления структур данных и функционала, то декларативность обычно выражается в бессистемном наборе сущностей безотносительно их семантики применения. Т.е. последовательность (синхронность/асинхронность для параллельного выполнения) вызова функций/методов обычно не регламентируется. Наконец, в интерфейсе редко отражаются ограничения на конкретную сущность: валидация входных и выходных параметров, инвариантность состояний.
Имеем описание последовательности вызова методов, осуществляемых модулем. Короче алгоритм имеем. Почему нельзя сказать реализует ли другой модуль этот алгоритм, или нет? В интерфейсе.

Ответ на »сообщение 962« (Илья Ермаков)
___________________________


Тут налицо непонимание автором того, что тип данных несет в первую очередь содержательную нагрузку. То, какие поля для круга окажутся избыточными - второстепенно, это нюансы реализации, а важно то, что понятие "круг" действительно является частным случаем эллипса, и любой алгоритм, работающий на эллипсах, будет работать и с кругами. Возможное решение - вообще не вводить отдельного класса для круга, обходясь эллипсом. Но можно и ввести, явным образом гарантируя для кругов инвариант "r1=r2". А вот введение двух несвязанных типов "эллипс" и "круг" является бессмыссленным решением, как и наследование эллипса от круга.

Насколько я понимаю, так же думает и Мейер.
В его недавно переизданной книге об ОО-конструировании программных систем, в главе 14 (Введение в наследование; с.457) он не рассматривает пример прямоугольник-квадрат (равно как и эллипс-круг) в качестве парадокса.
Просто спокойно замечает, что квадрат характеризуется инвариантом side1 = side2.
Конечно, ссылка на авторитет ничего не доказывает; но я все же привожу ее (в качестве информации для размышления).

Ответ на »сообщение 961« (Денис Зайцев)
___________________________
Человек, не имеющий достаточного представления об OOD сходу говорит: "сделаю круг наследником элипса!". Ээээ нет, если бы все было так просто - то зачем задавать задачу? Если немного подумать, то начинаешь понимать, что тогда у круга появляются лишние свойства (если они объявлены не private) и методы. Так, у элипса необходимо хранить два радиуса (и 4 метода для работы с ними, если они объявлены как private). Кругу же необходим лишь один радиус и всего два метода для работы с ним. Налицо избыточность данных.
Тут налицо непонимание автором того, что тип данных несет в первую очередь содержательную нагрузку. То, какие поля для круга окажутся избыточными - второстепенно, это нюансы реализации, а важно то, что понятие "круг" действительно является частным случаем эллипса, и любой алгоритм, работающий на эллипсах, будет работать и с кругами. Возможное решение - вообще не вводить отдельного класса для круга, обходясь эллипсом. Но можно и ввести, явным образом гарантируя для кругов инвариант "r1=r2". А вот введение двух несвязанных типов "эллипс" и "круг" является бессмыссленным решением, как и наследование эллипса от круга.

Ответ на »сообщение 960« (Сергей Перовский)
По моему, наиболее полное соответствие теории множеств у ОО подхода с наследованием только по реализации: если некоторый объект входит в множество A, которое является подмножеством B, то он обладает всеми свойствами элементв B. Без всяких "ведет себя аналогично" или "с точки зрения...".
Он просто является элементом множества B.

Очевидно, Вы имеете в виду, что если

type
  A = class(B)

то A - подмножество B.
(хотя в принципе можно думать, что в данном случае наоборот, B - помножество A, т.к. A может вводить новые поля, которые можно логически считать присутствующиими и у B, но имеющими NULL-значения).

В любом случае (какой бы вариант Вы ни выбрали) этот подход имеет некоторые проблемы. В частности, имеется довольно известный парадокс ОО-проектирования "Круг - это не эллипс".
Не могу найти ссылку на первоисточник. Вот ссылка на обсуждение этого парадокса на русском языке:
http://finnam.blogspot.com/2005/11/ood.html

Вот несколько ссылок на английском языке:

http://ootips.org/ellipse-circle.html
http://www.parashift.com/c++-faq-lite/proper-inheritance.html
http://twasink.net/blog/archives/2004/06/circleellipse_p.html

Ответ на »сообщение 959« (AVC)
___________________________
По моему, наиболее полное соответствие теории множеств у ОО подхода с наследованием только по реализации: если некоторый объект входит в множество A, которое является подмножеством B, то он обладает всеми свойствами элементв B. Без всяких "ведет себя аналогично" или "с точки зрения...".
Он просто является элементом множества B.
Вся история с интерфейсами, множественным наследованием и т.д. начинается, когда математическая проработка отсутствует. Все эти механизмы служат для латания прорех в исходной модели. Вспомните рассуждения о "хрупкости": ошибки в реализации базового класса можно исправить только имея доступ к исходным текстам базового класса.
Для математика это звучит как "что будем делать, если обнаружим ошибку в теореме Пифагора?". Ответ очевиден - будем перестраивать всю математику.

Ответ на »сообщение 955« (12)
___________________________

Ответ на »сообщение 953« (Варяжский Гость)
___________________________
Далеко не всегда нужно (можно) разделять интерфейс и реализацию. При программировании бывает полезно работать даже не с АТД, а со слоями абстракций, реализованными, например, на базе конечных автоматов (реализация абстракции в виде другой абстракции, математической с возможностями формального анализа и синтеза).

Не понял я этой мысли. Интерфейс, то - что нужно, чтобы можно было
менять реализацию безболезненно. А почему его нельзя (не нужно) выделить?

Я сам пока думаю на тем, что сказал Варяжский Гость.
С одной стороны, "объекты - наше все", и по правилам ОО-дизайна ими следует оперировать только через интерфейс.
С другой стороны, можно вспомнить критику немодульных языков (у которых единицей инкапсуляции является класс) и "No Paranoia Rule" (кажется, у Шиперского).

Ответ на »сообщение 957« (info21)
___________________________

С помощью Оберона нельзя shoot yourself in the foot:

http://www.reed.edu/~tuckers/jokes/foot.html

Однако, среди перечисленных языков есть и Pascal, и Modula-2.
Возможно, автор просто не слышал об Обероне. :)

С помощью Оберона нельзя shoot yourself in the foot:

http://www.reed.edu/~tuckers/jokes/foot.html