interface IFlyingCreature
{
  void Fly();
  void Land();
}
interface IJumpingCreature
{
  void Jump();
}
class CommonBeetle
{
  int Eat(Food f);
}
//-=skipped=-
class SomeBeetle : CommonBeetle, IFlyingCreature, IJumpingCreature
{
  void SomeSpecificFeature();
} 

при использовании интерфейсов в дальнейшем будет возможность написать

class Raven: CommonBird, IFlyingCreature
{
  .....
} 

Цитата:

А если пугает обширная иерархия, то тогда - вариант 2.

---

Вот написал, а потом подумал.....
Интерфейс ведь не содержит реализации и придется описывать как прыгает каждый конкретный жук.
Ну тогда все-таки множественное наследование.

Давайте я еще вывешу свои размышления (даже практически предлагаемый механизм) из соседней ветки.

Цитата
Да, новые идеи всегда с трудом находят понимание у современников

Что такое множественное наследование, ты понимаешь.
Теперь переверни картинку вверх ногами. Что получилось?
Это множественные наследники.

В предлагаемой реализации:
Цитата:


Теперь замещаем методы test1 и test2 методами классов mix1 и mix2:
Цитата:


Поскольку оба методы переопределены, причем разными подклассами, результат будет:
Цитата:


Т.е. я раздумываю, не строить ли шаблон класса динамически, добавляя суперклассы и наследников, которые выполняют некий downmix, заменяя функционал суперкласса.
Но заменяют они реализацию не у себя, а в том классе, который я им указываю.
И создаю я объекты не наследников, а сразу объекты суперкласса, но с уже переопределенными аспектами поведения.
Моя задача решается идеально, но это не ООП, так ведь?

Вот такая тема.
Но, поскольку я не могу найти реализации и обоснования подобных механизмов у классиков - пребываю в глубокой задумчивости.

Pelmen писал(а) 02. Июня 2006 :: 10:09:

Никаким. Нет производного класса.
Более того, нет концепции производных классов - есть концепция замещения или реализации аспектов поведения.
Т.е. до точки X есть производные классы и ООП - а далее downmix.

Цитата:

Я знаю
И спасибо вам за ваши со Степаном предложения.
Я конечно, это все уже реализовал или одним или другим способами.

Здесь у меня академический интерес, который может перерасти в практический.
Ну и возможно, кого-то тоже наведет на конструктивные мысли.

В конце концов, не все же время ходить протоптанными путями

kms
Более мененее ясно. Разъясни только вот чего.
Правильно ли я понимаю, что подобные конструкции полезны в ситуации, когда в работе программы одновременно используется относительно небольшое количество объектов? Тогда как возможных вариантов этих самых разных объектов - очень много. И таким образом ты просто хочешь облегчить описание всех этих бесконечных возможных вариантов. Ага?

Palytch
Третьим будешь?

Я тебе щас умную вещь скажу, ты только не обижайся. Может быть не надо путать понятия "класс" и "объект"?

Класс - это "Жук". У жука есть разные данные: как он перемещается, что он есть, когда спит, и т. д. по всему "набору аспектов поведения".

Поймали конкретного жука - это объект. Создаем объект класса "Жук", в конструктор передаем параметры: Летает на 4-х крыльях, может прыгать, ест пыльцу, свистит в ля-миноре.

Не катит?

Скорость

И агрегация проигрывает вот в чем:
Если есть большое число аспектов, и каждый реализуется отдельным агрегированным объектом, создание и копирование такого класса - это каждый раз создание необходимого числа агрегируемых объектов.

По крайней мере, в языках типа 1С, где нет логики указателей.

Т.е. по нагрузочной способности, это абсолютно разные концепции.
Если скорость создания агрегата будет линейно (а там, глядишь, и память закончится, экспонента пойдет)проседать с ростом числа аспектов поведения, то downmix потребует 1 раз создания шаблона и минимальное постоянное время на создание экземляров класса.


_{P.S. ну ладно, ладно, ну можно, конечно что-то придумать с хранением по ссылке в 1С. А то щас наброситесь}

kms писал(а) 02. Июня 2006 :: 11:25:

Именно агрегация. Только часть жука - это не "поет", а "пелка". Орган, которым он поет. "Поет" - это метод "пелки".

Описываем интерфейс "ПелкаЖука", наследуем от него много конкретных органов, которыми жуки могут петь, описываем в них, как именно эти органы поют. При создании конкретного жука в переменную "_Пелка" класса "Жук" записываем экземпляр конкретной пелки данного конкретного жука. Класс "Жук" делегирует выполенние метода "Петь()" переменной "_Пелка".

Если переменная "_Пелка" пуста, то жук не поет вообще.

Всо.