С наступившми Новым Годом!
А то все -- с наступающим, да с наступающим... :)

Ответ на »сообщение 4204« (ASU)
___________________________
Попробую еще раз... Наследование (в ООП) – всегда классификация, но не всякая классификация – наследование... «Любая селедка – рыба, но не всякая рыба – селедка». Буч приводит надуманный пример (рисунок) с разными вагончиками и говорит, что поскольку способов классификации может быть много, то и иерархий наследования тоже может быть много. Непонятно?...
Может быть имелось в виду, что иерархия наследования меняется в зависимости от выбранного "базиса" рассматриваемых критериев и свойств. Тогда противоречий в методе НЕТ. Противоречия возникают, когда мы ЭТО пытаемся впихнуть в средства языков, в которых нет столь гибких средств "учёта базисов"... :о)

С Новым Годом!

Ответ на »сообщение 4201« (hugi)
___________________________
Выбросил/уничтожил и нет проблемы!..
Прям по Сталину... У Вас там случайно не авторитарная секта Верующих в Большие Системы?

Уважаемый hugi!

Если вы имете в виду слова "нет человека - нет проблемы", то никогда подобной чуши (на счёт того, что эти слова говорил Сталин), не повторяйте. А также не делайте аллюзий по сему поводу.
Сталин никогда и нигде этих слов не говорил. Эти слова вложил в уста Сталина писатель Рыбаков в "Детях Арбата"... ( см.например здесь: http://magazines.russ.ru/druzhba/2000/1/volkov.html)

Эта "шняга" из того же разряда, что и перевираемое ленинское о "кухарке и государстве"... :о)
Упоминая подобные вещи в приличном обществе, вы только добавляете себе минусов в глазах тех, кто знает чуть больше и шире скармливаемых нам "новорежимных" считалок и речовок... :о)

С Новым Годом!
Успехов и удачи в наступающем году!

Ответ на »сообщение 4197« (hugi)
___________________________
Да? А каким образом вы будете "удовлетворять компилятор" на предмет принадлежности конкретного класса к классу (интерфейсу) "Умеющих Летать"? :о)
Примерно таким, каким Вы в Лимбо.
Это не ответ. Я потому и задал этот вопрос, что ответ на него покажет различия в подходах уже на стадии проектирования...

А вот теперь скажите, эта "отдельная сущность" как-то выражается конкретно в языках программирования? Ведь мы вроде бы все согласны, что языки – это ещё и средство закрепления проектных решений. - А скажите, как вы будете реализовывать требование поддержки классом того или иного интерфейса (реализовывать эти самые напроектированные "решения")?
Выражается. Interface называется. Легко: Класс реализует Интерфейс.
Не вырывайте фразы из контекста. Вопрос был не в том, что я не знаю, как это делается в отдельных языках...

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

Помилуйте, смысл – кардинально изменился. Это всё равно, как "вам шашечки нужны или в аэропорт?" Оформление "интерфейсов" в обязательном виде в программе в виде отдельных синтаксических элементов – это обязательное наличие "шашечек". А вот описание конкретных требований в конкретном месте – как раз минимальное требование на возможность "ехать". И будь это телега, частник на копейке или, собственно, такси – вы можете по"ехать" и успеть на самолёт. :о)
Выражайтесь, пожалуйста, яснее.
Извольте. "Шашечки" – это обязательность выражения средствами языка придуманными вами интерфейсов и классов. Но, как я уже писал выше вы не всегда МОЖЕТЕ это сделать. "Ехать" – обеспечение сущностями (объектами) функциональности. В случае с процедурой сортировки, Вы ОБЯЗАНЫ вводить в описания интерфейсов методов с сигнатурой, затребованной процедурой сортировки. В случае с Лимбо важно просто наличие такого метода в АТД.

Наложение будет "1-в-1"? И де тут гибкость?
А вот и ошибаетесь! Здесь отношение "многие ко многим".
А как на счёт динамики изменения набора в классах, к исходникам которых вы не имеете доступа? Мы ведь и о гибкости проектирования речь вели, так? :о)

УмеющийЛетать описывает некоторую функциональность позволяющую причислить АНАЛИЗИРУЕМЫЙ объект именно к этому классу. Так?
Опять не так. Как раз наоборот, можно причислить класс к набору классов, реализующих конкретный Интерфейс, причём это в классе явно прописывается.
И вы все интерфейсы можете предвидеть заранее?
И вы даёте гарантию, что при изменении требований и условий, вам не придётся перепроектировать этот набор интерфейсов кардинально?
И вы будете так же успешно использовать чужие компоненты, как и раньше (при прежнем варианте проекта), не имея доступа к их исходному коду?
Кроме того- и скомканный лист бумаги "летает"... :о)

Так и в Лимбо – мы МОЖЕМ думать, что данный объект МОЖЕТ БЫТЬ ПРИЧИСЛЕН к определённому классу, потому, что он имеет какую-либо функциональность (или их совокупность), но классов, как таковых в языке НЕТ.
Возможно, такой подход несколько более гибкий... с сопутствующими обстоятельствами.
Есть и сопутствующие обстоятельства... Я о них уже упоминал. Я имею в виду желательность (а, скорее, даже – необходимость) введения синтаксиса "в месте вызова" такой полиморфной функции. Может быть ситуация, когда нужная функция в объекте есть (семантика), и сигнатура по аргументам та, что нужно, да вот беда, имя отличается. В этом случае желательно с помощью некоей синтаксической конструкции указать компилятору, что за функцию действительно надо иметь в виду.

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

не имея не только наследования, но даже "классов" (в ставшем  привычным понимании) вообще...
Ну, если там нет зарезервированного слова class, это не значит, что там нет классов.
Там есть только АТД. Они так и ввели слово adt (abstract data type). Это нечто, как структура с функциями. Класс без наследования.

Важна конкретика функциональности, а не принадлежность объекта к какому-то там типу (классу)...
А вот конкретика функциональности по большому счёту определяется именно принадлежностью к классу. Или интерфейсу, что более гибко. Или, как в Лимбо, что, может быть, ещё более гибко.
КЛАСС – вторичен. Он – результат нашего анализа, абстрагирования. Предмет не принадлежит какому-то там классу "сам по себе". Классы – только у нас в голове. Природа изначально "деклассирована"... :о)

...ООП сделало слишком быстрый переход "в обобщение"...
Это как?
Это я на счёт леса наследования и его прямой связи с лесом абстракций, полученных при анализе...
Очень часто первое строится только исходя из достижения максимального повторного использования кода, а не функциональности...

И ещё... При использовании Интерфейсов, которые, как я уже упоминал, выступают в качестве контракта между Вами и используемым Вами классом, у Вас есть практически 100% уверенность, что используемый класс делает то, что Вам нужно, что хорошо в плане безопасности (устойчивости). А как с этим в Лимбо? Если сигнатуре метода сравнения удовлетворяет метод сложения, или сигнатуре метода сложения удовлетворяет метод умножения?
Дык у нас и в "обычных" ООП-языках никакой гарантии по семантике нет. Взять хотя бы знаменитый пример с перегрузкой операций. Обычно главным аргументом против такой широкой практики как раз и служит отсутствие чёткого понимания (из текста программы) что конкретно за операции (смысл) стоят за конкретным значком... Интерфейсы пока не описывают семантики... К сожалению... :о)

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

С наступающим Новым Годом Вас!

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

Наследование, иерархия.  Широко применяющийся, массовый, но унылый и малопродуктивный механизм.

Наследование – это великолепный механизм, который позволяет с минимальными усилиями создавать большие системы. Но я бы еще раз повторил, что полезность (если не использовать высокопарное слово «великолепие»!) наследования раскрывается только при раскрытии семантики предметной области (и ее сущностей, разумеется).
Попробую пояснить маленьким примером. Предположим надо написать складскую программу. У нас, как у разработчиков, есть два пути. Первый – собираем информацию от будущих пользователей (какие функции выполняет склад? Какая периодичность выполнения? Какими документами оперируют на складе? Кто заводит ту или иную информацию? И т.д. и т.п.). Второй путь, состоит в том, чтобы не беспокоить пользователей, не рыться в книгах, а... сесть и подумать о том, в чем смысл склада... Странно, правда? Но все же попытаемся. Чем занимаются на складе? Принимают и отпускают товары/материалы. Правильно? То есть, через склад протекает некий «материальный поток». Но «поток» может «течь» и без склада, что же делает склад в «потоке»? Заметим, что «поток» имеет разную интенсивность и даже точки разрыва... Например, материалы поступили сегодня, а отгружать их будут через неделю (неравномерность по времени); материал поступил в большой партией, а отпускать его будем маленькими порциями (неравномерность по объему). Если мы предположим, что поступление на склад и отгрузка со склада равны и по времени и по объему (что привезли, то и увезли в тот же момент), то склад... просто не нужен. Итак, «соль» склада – это демпфирование входных и выходных потоков. Согласны? Теперь попробуем приложить «склад-демпфер» к известным нам складам, от киоска под окном, до крупного логистического центра (тот же аэропорт, например). Есть ли хотя бы одна ситуация, когда наше «определение» неверно? Нет... Тогда можно пойти дальше и начать формировать иерархию складов. Но для этого надо разобраться со структурой склада и посмотреть на логику развития тех сущностей, которыми он «населен». В результате получим... достаточно простую иерархию, описывающую все множество складов. И мы не только решим поставленную перед нами задачу, но и будем избавлены (раз и навсегда!) от... пожеланий пользователей внести то или иное изменение.
Попробуйте найти близкое по своим возможностям решение, не используя «наследования»...

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

Ответ на »сообщение 4201« (hugi)
___________________________
...мне иногда приходится вести разговор на грани...
Оно и видно.
Рад, что Вы это заметили :)

Дабы ни у кого не появилось соблазна поверить, но зато появилось желание опровергнуть или доказать (а значит, как минимум, задуматься).
Интересная методика.
Стара... как мир, поверьте... :) Порой для того, чтобы привести человека в чувство приходится... бить по щекам.

Нет, мне тоже верить не следует. Когда Вам откроется нечто, Вы сами поверите, и сомнение никогда не появится. Но к этому надо быть готовым...

УАУ!!! Да у Вас, наверное, и ритуал целый существует посвящения в свою веру?!
В мою веру посвятить нельзя, но ее можно принять. И заключается она в призыве Платона: «Познай себя».

... а в зеркале... не встречали? :)
А без шуток?! Это ль не Вы говорили:
>> Есть праздники и есть будни. Есть работа и есть развлечение. То что уместно (забавно и весело) в одном случае, неуместно в другом... Красить мир одной краской - надо ли...
Я говорил, но совсем по другому поводу...

Основу любого («бесконечного») разнообразия составляет... очень небольшое количество элементов. Разберите «калейдоскоп»... и убедитесь.
Ух ты! А с каких это пор калейдоскоп по сложности приравнен к Homo Sapiens?
Если Вы можете опровергнуть данную аналогию, опровергайте, а если не можете...

«ВСЮ функциональность»... Забавно... А если изменятся условия задачи или появятся другие задачи?
А на что мне наследование и полиморфизм?
Понятно... Значит снова будете создавать множество произвольных (несуразных) иерархий наследования на потребу каждой новой задачи... Успехов на этом не легком поприще!..

Вы, наверное, говорите о простых программах, а я о больших системах.
Ах, да... Я и забыл, что Вы у нас Гуру Больших Систем. А мы то непосвящённые только и можем лепить программки в Delph'ях типа "сложить два числа"
Н-да... по крайней мере самокритично :)))

Вы можете «уничтожить Печкина», а я нет (у меня он просто меняет роль).
Нет, у Вас он меняет не роль, а генетический код: был Печкин -- стал Голубь. Круто.
Увы... Обида застила Вам глаза...

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

Если «переменная» «Пол» класса «Homo Sapiens» может принимать только одно значение из нескольких допустимых, то как же можно... Видимо, я чего-то не понимаю...
Видимо, так... Ведь из Ваших слов пол -- не просто одно из нескольких допустимых значений, это Роль (хотя бы потому, что с полом сопряжены некоторые функции человека как-то: Быть Матерью, Быть Отцом и пр., причём взаимоисключающие друг друга)
Фи... Есть переменная «Пол», есть роль «Отец». Это суть разные вещи. Можете использовать бесполую роль - «Родителя», что изменится? Зачем сваливать в одну кучу совершенно разные понятия?

И всё это у Вас прописано в одном классе, безосновательность чего я и продемонстрировал на примере.
Роли в классе не прописываются! Я уже несколько раз говорил о том, что роль агрегирует интерфейсы, а интерфейс (по определению!) то, что обеспечивает (межуровневое) взаимодействие элементов. Поэтому, то, что Вы продемонстрировали в примере... пусть остается с Вами.

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

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

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

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

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

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

У химических элементов это заряд, масса, радиус, строение электронной оболочки и, может, ещё что-нибудь. У букв -- соответствие звукам языка. У нот... не знаю -- не специалист
Подскажу (если Вы не против), у нот, как впрочем и у любых иных звуков – частоты, продолжительность и амплитуды колебаний.

Мы же говорим о проблеме классификации сущностей, имеющих очень большое число характеристик
Хм... сколько степеней свободы имеет палец? А рука? А все тело человека? Продолжать или уже понятно?.. Сколько музыкальных произведений существует? Много?! А нот всего семь... а параметра только три... Сколько действий может совершить человек? Много?! А если разложить на простые движения (которых всего-то два: поступательное и вращательное)... «Зачем делать сложным то, что проще простого?». Характеристики (свойства) – это проявления (вовне) композиций из очень малого количества исходных (внутренних) элементов. Можно перечислять композиции, а можно попробовать понять их основу и правила построения (создания).

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

Хм... Мне кажется, что Буч заслуживает аплодисментов! Такое искусное жульничание на основе подмены понятий должно достойно вознаграждаться. :)
Может, объясните для тех, кто в танке, где у него подмена понятий?
Попробую еще раз... Наследование (в ООП) – всегда классификация, но не всякая классификация – наследование... «Любая селедка – рыба, но не всякая рыба – селедка». Буч приводит надуманный пример (рисунок) с разными вагончиками и говорит, что поскольку способов классификации может быть много, то и иерархий наследования тоже может быть много. Непонятно?..

Хм... Хотя почему бы и нет?.. Если уж так хочется...
А вот это уже граничит с оскорблением. Если в ответ на сообщение Сергея Губанова я пытался отшутиться, то здесь мне уже не до шуток.
Вы хотели походить на Г. Буча, я этому не противился... и это для Вас оскорбительно? Может быть тогда не надо на него походить, может быть лучше оставаться самим собой?..
Но я прошу у Вас прощения, раз мое замечание Вас столь сильно задело. Обидеть Вас я не хотел.

Кстати о проектировании сложных систем:
http://www.gazeta.ru/techzone/2005/12/28_e_508171.shtml
Класс!

Кстати о проектировании сложных систем:

http://www.gazeta.ru/techzone/2005/12/28_e_508171.shtml