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

при этом в зале игровых автоматов функция хранения как таковая уже будет отсутствовать.

функция хранения, конечно, в понимании ASU, поскольку книги и лодки ничем не хуже и не лучше игровых автоматов.

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

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

КОП = ООП + модульность + безопасность - наследование (через границы модулей)

Жаль, что инструментарий компонентного программирования видится всего лишь как серия заплат на инструментарии ООП. Может быть, перспективнее взгляд "с чистого листа", без оглядки на сложившиеся каноны, создававшиеся (как видно, в частности, из приведенной сложноватой формулы) в пренебрежении к потребностям компонентного программирования?
___________________________

Вот взгляд с совершенно другой, "не обероновской", стороны -- интересная статья С.Меллора (одного из авторов известного метода объектно-ориентированного анализа) об управлении меняющимися требованиями к ПО: "Managing changing requirements".

http://www.embedded.com/story/OEG20010725S0103

Здесь он говорит о выделении инварианта и помещении всех потенциально меняющихся компонентов задачи в данные.
(Отмечу, что здесь другой подход: создается модель, которая затем транслируется в код.)

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

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


cклад есть помещение для хранения чего-либо, а также большое количество предметов (сущностей), собранных в одном месте.

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

если это брать в качестве определения и считать демпфирование неотъемлемым свойством любого склада, то чему тогда удивляться, что склад в вашей трактовке вдруг перестанет удовлетворять вашему же определению?

даю аналогично свое определение: огурец есть соленый на вкус овощ класса cucumis sativus. если не соленый, то уже не огурец. попробуйте привести мне пример овоща класса cucumis sativus, который не соленый на вкус и который при этом удовлетворяет моему определению. не получится. по определению.

Временной склад боеприпасов – типичный склад, аналогичный камере хранения.

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

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

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

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

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

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

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

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

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

Ответ на »сообщение 4225« (AVC)
___________________________
Сопоставимы = сравнимы. (В отличие от круглого и соленого.)
Возможно, я как-то не так выразился?
Я имею в виду, что у нас может быть выбор: реализовать требуемую функциональность с помощью наследования или композиции.
Значит нам придется сравнивать эти решения, чтобы выбрать лучшее
Ну, если исходить из функциональности... то, возможно, Вы правы... Тогда становится понятна и Ваша мысль о том, что идеальный вариант (наследования) – это два уровня.

Я просто пытаюсь понять (наверное, в наивной и даже глупой форме): так уж ли нужны "развесистые" иерархии? Или вполне достаточно всего двух "уровней": интерфейс (АТД) -- реализация? (В некоторых языках это даже не будет наследованием.)
Это вообще не наследование, если появится наследование, то будет уже не два, а более уровней.

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

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

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

Ответ на »сообщение 4187« (ASU)
___________________________
Если найдется склад, который ни «демпфирует» входные и выходные потоки, то я пойду готовить салат к новогоднему столу... из своей шляпы.
1. временный склад боеприпасов.
1000 ящиков со снарядами. с этого склада только забирают ящики.
входного потока нет. учет есть. склад есть. демпфирования нет.
2. сельская изба-читальня.
книги на руки не дают. книги идут из района.
входной поток есть. учет есть. склад есть. демпфирования нет.
3. спасательная станция.
2 лодки. не портятся. не тонут. вечные.
входного потока нет. выходного потока нет. склад есть. демпфирования нет
1. Временной склад боеприпасов – типичный склад, аналогичный камере хранения. Происходит согласование входного потока во времени (когда-то положили, а потом забираем, все сразу или по частям).
2 и 3. Это примеры лизинга (проката), когда что-то дается во временное пользование (арендуется). Есть функция хранения, но потоков нет. Например, здание в котором сдаются помещения в аренду, складом не является. Можно привести аналогичный пример хранения отходов, отвалы, характерные для некоторых производств, помойки и т.п. Но это именно хранилища, а не склады.

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

Ответ на »сообщение 4222« (AVC)
___________________________
В некоторых отношениях композиция и наследование вполне сопоставимы
Сопоставимы?..


Сопоставимы = сравнимы. (В отличие от круглого и соленого.)
Возможно, я как-то не так выразился?
Я имею в виду, что у нас может быть выбор: реализовать требуемую функциональность с помощью наследования или композиции.
Значит нам придется сравнивать эти решения, чтобы выбрать лучшее.


Мне кажется, что можно уточнить постановку вопроса. Дело не в наследовании как таковом, а в его "глубине" и назначении.
Идеальный вариант -- 2 уровня:
(1) абстрактный (интерфейсный) класс;
(2) класс реализация.
Все что сверх этого, таит в себе дополнительные проблемы.
В языках же с явной поддержкой интерфейсов, о которых говорил hugi, даже этого не надо.
Если довести эту мысль до предела (и может быть -- до абсурда :)), то наследование вообще может стать излишним.
Не комментирую...

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

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

привет честной компании! поработал с репетитором. ошибок в русском постараюсь не делать.

Если найдется склад, который ни «демпфирует» входные и выходные потоки, то я пойду готовить салат к новогоднему столу... из своей шляпы.

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

2. сельская изба-читальня.
книги на руки не дают. книги идут из района.
входной поток есть. учет есть. склад есть. демпфирования нет.

3. спасательная станция.
2 лодки. не портятся. не тонут. вечные.
входного потока нет. выходного потока нет. склад есть. демпфирования нет.

Ответ на »сообщение 4222« (AVC)
___________________________
В некоторых отношениях композиция и наследование вполне сопоставимы
Сопоставимы?..

Например, композиция позволяет реализовать требуемую функциональность динамически, объединив (сконфигурировав) несколько объектов (даже во время выполнения программы).
Наследование же (в языках вроде Си++ и Оберона) статично, требует компиляции
Хм... Композиция возможна, если только это заложено разработчиком. То есть, при проектировании сущности (модуля, класса, программы...) разработчик должен позаботиться о том, чтобы было возможным создавать композиции во время работы (в run-time). Правильно? Таким образом, и композиция, и наследование – решения времени проектирования (design-time).
Другими словами, чтобы была возможность получать композиции в run-time, необходимо сделать специальную «надстройку». Но, если создать «объектную фабрику» («надстройка» для наследования), то можно добавлять объекты новых классов прямо при работе своей программы.
Создание композиций (внутри агрегата) – это «конструирование», а разработка классов – это кодирование... Но это положение справедливо только в случае, если речь идет о простых (элементарных) классах. Агрегаты – это тоже классы, которые (как правило) имеют свою логику развития (которую можно отобразить через наследование). Разработка классов-агрегатов для конкретной предметной области может осуществляться, как программистами, так и пользователями. Это более высокоуровневое программирование-конструирование, собственно, о чем я и говорил... ранее.

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

Мне кажется, что можно уточнить постановку вопроса. Дело не в наследовании как таковом, а в его "глубине" и назначении.
Идеальный вариант -- 2 уровня:
(1) абстрактный (интерфейсный) класс;
(2) класс реализация.
Все что сверх этого, таит в себе дополнительные проблемы.
В языках же с явной поддержкой интерфейсов, о которых говорил hugi, даже этого не надо.
Если довести эту мысль до предела (и может быть -- до абсурда :)), то наследование вообще может стать излишним.
Не комментирую...

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


Хм... композиция лежит в основе агрегации, классификация лежит в основе наследования... Как можно предпочесть соленое круглому?


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

Мне кажется, что можно уточнить постановку вопроса. Дело не в наследовании как таковом, а в его "глубине" и назначении.
Идеальный вариант -- 2 уровня:
(1) абстрактный (интерфейсный) класс;
(2) класс реализация.
Все что сверх этого, таит в себе дополнительные проблемы.
В языках же с явной поддержкой интерфейсов, о которых говорил hugi, даже этого не надо.
Если довести эту мысль до предела (и может быть  -- до абсурда :)), то наследование вообще может стать излишним.