Ответ на »сообщение 4106« (hugi)
___________________________
Не стоит называть Буча недалёким
Хм... Вы так думаете? То есть, Вы думаете, что он понимает, что пишет чушь, но... продолжает писать. Тогда, конечно, все гораздо хуже... По мне, лучше он все же был недалеким... Хотя может быть Вы и правы... ради денег некоторые люди могут рядиться шутами... но это уже пройдохи.

Если Вы забыли, позволю себе напомнить Вам, что под отсутствием "хорошей" классификации подразумевается зависимость её от целей, поставленных перед исследователем
Хм... Возможно Вы пропустили, но я говорил о семантике. Исходя из Вашего утверждения у каждого должна быть собственная таблица «Менделеева», собственные буквы и ноты... Наверное, это было бы забавно... Вы возьметесь отрицать возможность существования объективного?

В самом деле, объединение объектов в классы возможно разными способами по нескольким критериям, -- выбор тех или иных диктуется предназначением классификации
Есть понятие классификации, есть понятие иерархии, наконец, есть понятие «наследования» (имеется ввиду наследование в трактовке ООП). Все это суть разные понятия. На самом деле, можно классифицировать камешки на берегу по размеру, по форме, по цвету и даже... по хим. составу. И, очевидно, подобных классификаций «на потребу» можно выдумать очень много. Можно также отметить, что классификаторы могут иметь разную структуру: линейную, матричную, объемную, иерархическую и пр.
Есть понятие иерархии. Не всякая иерархия относится к классификации. Например, иерархии «вложения», «подчинения» не являются классификацией.
Наконец, есть в ООП понятие наследования (отмечу, на всякий случай, что понятие наследования в ООП отличается от «бытового» понимания термина «наследование». В быту мы можем сказать, что ребенок унаследовал от родителей черты лица, манеры, состояние, в ООП ребенок от своих родителей не наследует). «Наследование» в ООП основано на выявлении родовых (общих свойств), которые передаются от суперкласса его подклассам. Иными словами, наследование в ООП имеет в своей основе иерархическую классификацию, описывающую передачу родовых свойств. А, следовательно, говорить о произвольном формировании иерархической классификации при наследовании в ООП – моветон (или глупость, или обман – нужное подчеркнуть).
Но выявление родовых свойств... не самая простая задача. И единственный (нетупиковый) путь – это понимание семантики рассматриваемых сущностей.

В подтверждение своих слов Буч приводит эксперимент в картинкой, на которой изображены паровозики, составленные из разной формы вагончиков. Эксперимент заключался в том, что люди, которым предлагали классифицировать паровозики с картинки, делали это по-разному, причём невозможно было выделить среди данных классификаций одну, по каким-либо критериям превосходящую остальные
Хм... Мне кажется, что Буч заслуживает аплодисментов! Такое искусное жульничание на основе подмены понятий должно достойно вознаграждаться. :)

Спасибо, значит хоть в чём-то я с Бучем сравнялся... :)
Хм... Хотя почему бы и нет?.. Если уж так хочется...

Ответ на »сообщение 4104« (hugi)
___________________________
Если посмотреть работу Шлаера и Меллора, ссылка на которую приводится у того же Буча, то можно узнать, что, по их мнению, роли являются кандидатами в классы и объекты
Ну, хорошо, посмотрели... А дальше что? Вы это приводите, как пример несуразности или глубокомыслия? Возможно, Вы не заметили, но я уже говорил, что не стоит доверять «авторитетам»... и своего мнения я не изменил.

И вообще, непосредственно Homo Sapiens не умеет исполнять обязанности ни почтальона, ни садовника, -- его прежде нужно обучить. Как обучить? -- реализовать функциональность. . Где реализовать? -- в классе. В каком? -- который наследует от класса Homo Sapiens.
Что Вы понимаете под функциональностью Homo Sapiens, и что под функциональностью Почтальона? В чем их отличие? Может ли Homo Sapiens взять предмет, отнести его к нужному месту и положить? Если может, то он уже Почтальон. Другими словами, не является ли работа Почтальона просто скоординированной последовательностью действий доступных и Homo Sapiens.
С другой стороны, давайте поверим Вашим кумирам и создадим подкласс Homo Sapiens под названием «Почтальон», конечно, наделив его свойством разносить почту. Какова реализация этого свойства? «Взять», «Отнести», «Положить»... Хм... Так это же уже было! Ну, да, лиха беда – начало... Наш Почтальон бросил работу на почте и стал Садовником. Что делать-то будем? «Отрезать» одну функциональность и наращивать новую? На всякий случай замечу, что объект почтальон-Печкин (экземпляр класса «Почтальон») у нас уже реально существует. Значит теперь мы будем вынуждены сменить класс у объекта? Хм... Ни слабо... Но и это еще не все...
Вместо почтальона-Печкина на почте стали использовать «почтовых» голубей. Срочно заставляем Печкина скрещиваться с голубкой? Или по совету «мудрого» Буча выносим «функциональность» «быть почтальоном» в отдельный класс и начинаем «прививать» его по мере необходимости разной живности и представителям Homo Sapiens?
Замечательно! А теперь на мгновение представим себе все множество профессий (включая домохозяек и пенсионеров на всякий случай)... Не слабо, правда? Только профессии – это еще цветочки. Человек (то бишь, Homo Sapiens) может еще быть внуком, сыном, мужем, отцом, дедом, внучкой, дочкой, женой, матерью, бабушкой, дядей, тетей, племянником и племянницей и т.д. и т.п., продолжаем: другом, недругом, помощником и саботажником, и т.д. и т.п. Остальное додумаете сами. Честное слово, меньше всего мне бы хотелось увидеть то, что у Вас получится в результате...
«Не сотвори себе кумира»... IMHO, разумеется.

Без этого объект "освоить новую роль" не сможет. В терминах интерфейсов это выражается: "Класс-наследник от Homo Sapiens реализует интерфейс Почтальон (или Садовник)"
Понимаю, сначала трудно... Но попробуйте смотреть на роль, как на совокупность интерфейсов. Интерфейсы уже есть, их осваивать заново не надо, надо их только упорядочить... Роль «Почтальон» в «терминах интерфейсов» выглядит примерно так: «Взять», «Отнести», «Положить». Роль можно переопределить (об этом я говорил ранее).

Судя из вашего описания не изменяет функциональности. Ведь, если в агрегате заменить один объект на другой, функциональность (список заявленных возможностей) не изменится -- изменится её реализация
Вы правы. Именно так я и написал: «Данное изменение, тоже в реальности не является изменением функциональности»

Ответ на »сообщение 4117« (hugi)
___________________________
Тип не обладает функциональностью (классы не рассматриваем).
Пардон, но у меня складывается впечатление, что вы берёте определение из книг по программированию где-то начала 80-х...

Ответ на »сообщение 4109« (hugi)
___________________________
Да, но если мне НЕ нужно, что бы объект принадлежал к какому-либо классу, имеющему функциональность "летать" и тем не менее он мог делать это?
Вы, видимо, не поняли, о чём идёт речь. "Иметь функциональность" <=> "уметь делать". Если Вы имели в виду, что Вам нужно, чтобы разнородные объекты предоставляли требуемую функциональность, то интерфейсы как раз тут Вам и помогут.
Вам даже классы с наследованием часто не понадобятся для построения ОО-систем, представьте такую ересь! :о))))
Возьму на себя смелость напомнить Вам, что именно наследование отличает Объектно-Ориентированные системы от Объектных.
Вообще-то, "ПРИ СЛОЖИВШИХСЯ ПОДХОДАХ" имена функций ни при чём, всё делается с помощью процедурного типа, либо указателей на функции. С помощью интерфейсов всё делается ещё проще. Класс, который хочет, чтобы его экземпляры сравнивались, реализует специальный интерфейс Comparable (как в Java, например).
Да нет же, я ж вам говорю, что можно ЕЩЁ проще.
например (как я уже писал, может вы просто не видели раньше), как это дело объявляется в Лимбо:

вот объявление АТД:

Env: adt[V]
    for {
    V =>
        free: fn(v: self V, used: int);
        dup:    fn(v: self V): V;
    }
{
    items: array of V;

    new: fn(args: list of V, nilval: V): Env[V];
    get:    fn(t: self Env, id: int): V;
    discard: fn(t: self Env);
};

или "простой" (вне класса) функции:

free[V](opts: list of (int, list of V), args: list of V, used: int)
    for{
    V =>
        free: fn(v: self V, used: int);
    }
{
    for(; args != nil; args = tl args)  (hd args).free(used);
    for(; opts != nil; opts = tl opts)
        for(args = (hd opts).t1; args != nil; args = tl args)
            (hd args).free(used);
}

И в том и в другом случае, V значения не имеет. Имеет значение в составе V объявлений о заявленных функциях ( для АТД требуется от элементов наличие free() и dup(), для функции – free() ).

Исчё раз повторюсь. Здесь требование на "соблюдение интерфейсов" тоже соблюдено. Но не на "классовом" уровне, а на уровне КОНКРЕТНЫХ требований, возникающих "по месту использования".

вот тот пример с сортировкой:

sort[S, T](s: S, a: array of T)
    for{  S =>  gt: fn(s: self S, x, y: T): int;  }
{  mergesort(s, a, array[len a] of T);  }

mergesort[S, T](s: S, a, b: array of T)
    for{  S =>  gt: fn(s: self S, x, y: T): int;  }
{
    r := len a;
    if (r > 1)
    {  m := (r-1)/2 + 1;
        mergesort(s, a[0:m], b[0:m]);
        mergesort(s, a[m:], b[m:]);
        b[0:] = a;
        for ((i, j, k) := (0, m, 0); i < m && j < r; k++)
        {  if(s.gt(b[i], b[j]))  a[k] = b[j++];
            else  a[k] = b[i++];
        }
        if (i < m)  a[k:] = b[i:m];
        else if (j < r)  a[k:] = b[j:r];
    }
}

как видите, это пример с сортировкой слиянием.
Сами видите: подавайте на вход функции sort(), во-первых, аргумент s, ЛЮБОГО ТИПА S (лишь бы в его составе была функция нужной сигнатуры и семантики) и массив a элементов любого типа, лишь бы он согласовался с типом аргументов функции сравнения – и получаете рабочую функцию без необходимости городить набор дополнительных синтаксических конструкций.

То же самое и в отношении свойства "летать". По задаче у меня могут появиться соврешенно извратные желания на счёт того, что должно уметь летать. Множественным наследованием можно такого же добиться, но довольно велик шанс возникновения противоречий и не стыковок (соврешенно разного характера: от правил оформления наследования, через конфликты имён и к просто логической нестыковке "интерфейсов" при реализации)...


Насколько я понимаю концепцию АТД, тип данных определяет именно данные, а не функциональность. Функциональность определяется производимыми над переменными этого типа операциями.
Выходит, вы её неправильно понимаете... Или не в курсе последних "веяний"... Ну, или, "на крайняк", её не правильно понимают Керниган с Томпсоном и Ричи (аки авторы Инферно и Лимбо... :о)

Именно концепция интерфейсов позволяет нам абстрагироваться от классов и сосредоточиться на требуемой функциональности.
Да, но, если следовать вашей логике, то абсолютное "абстрагирование от классов" сводит класс просто к роли держателя (объединителя, контейнера) реализаций интерфейсов. А при этом мы вполне логично приходим к единственному "типу" класса в системе – "типу"-держателю интерфейсов... :о) Чем тогда один от другого эти классы по реализаци механизмов поддержки этого свойства будут отличаться? :о)
Другая сторона этой же крайности: представьте, что все интерфейсы свелись (каждый в своём наборе функций) К ЕДИНСТВЕННОЙ ФУНКЦИИ. Просто, интерфейс состоит всего-лишь из одной функции. Каждый. Чем они для системы поддержки времени будут друг от друга отличаться? Ведь вы же сказали, что имена не имеют значения! :о)

Господа, задавайте себе вопросы, крутите, "мусольте" тему. Смотрите на неё так и эдак... Никто не сказал, что знания задаются на века. Всё текёть, всё зминюеться...

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

Значит ли это, что Self не является объектно-ориентированным языком?
К сожалению, не могу точно ответить на Ваш вопрос. Я не знаком с языком Self. На сайте smalltalk.ru я нашёл материал по Self, и слово "делегирование" употребляется там только при рассмотрении множественного наследования. Вообще же, насколько мне удалось понять, наследование там есть, просто его реализация отличается от традиционной. Следовательно, язык этот, как мне кажется, объектно-ориентированный.

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

Боюсь, что здесь какая-то путаница в понятиях.
Абстрактный тип данных (АТД) -- это математическое понятие, связанное именно с производимыми над типом операциями.

Возможно, Вы правы. Некоторая путаница и впрямь есть. Но я бы сказал иначе: АТД нельзя использовать без определённых над ним операций, т.к. реализация АТД должна быть скрыта от посторонних. Но, на мой взгляд, это не даёт оснований говорить, что "в АТД есть функциональность". Есть просто набор операций, связанных с АТД и обеспечивающих его поддержку.

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

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

Мне кажется, объектно-ориентированное программирование основано на пересылке сообщений, а не на наследовании.

Вы внимательно читали моё сообщение? Я разве где-нибудь употребил слово "основано"? Я сказал, что Объектно-Ориентированные языки в общепринятой терминологии отличаются от Объектных языков именно поддержкой наследования.

Значит ли это, что Self не является объектно-ориентированным языком?

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

Ответ на »сообщение 4027« (Руслан Богатырев)
___________________________

А теперь представим, что мы добавим третий параметр -- контекст сообщения.

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

А в Обероне нельзя достичь этого эффекта при помощи композиции объектов? Наличие универсальноко обработчика как раз и позволяет объекту-обертке, знающему контекст, модифицировать сообщение, а значит и обработку сообщения, необходимым образом. Что характерно динамически.

Мне (тоже) кажется, что в (оригинальном) Обероне родовые интерфейсы были введены как раз для поддержки broadcast-ов, чтобы сообщения могли достигать своих (неявных) адресатов, проходя через контейнеры, в которые они вложены.
Интересно, насколько применим такой подход за пределами визуализаторов?

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

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

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

Мне кажется, объектно-ориентированное программирование основано на пересылке сообщений, а не на наследовании.

Вы внимательно читали моё сообщение? Я разве где-нибудь употребил слово "основано"? Я сказал, что Объектно-Ориентированные языки в общепринятой терминологии отличаются от Объектных языков именно поддержкой наследования.

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

Ответ на »сообщение 4084« (Владимир Лось)
___________________________

То есть в описании конкретной функции не важно К КАКОМУ АТД принадлежит  обрабатываемый объект. Главное, что бы в этом типе была затребованная функциональность.

Насколько я понимаю концепцию АТД, тип данных определяет именно данные, а не функциональность. Функциональность определяется производимыми над переменными этого типа операциями.

Боюсь, что здесь какая-то путаница в понятиях.
Абстрактный тип данных (АТД) -- это математическое понятие, связанное именно с производимыми над типом операциями.