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

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

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

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

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

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

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

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

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

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

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

Почему при использовании функции вместо сущности повышается гибкость? Да, и правомочность такой замены, требует пояснения...

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

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

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

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

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

Хм... «общепринятый смысл»... нонсенс... хотя, наверное, не общепринятый.

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

Ранее приводились примеры складов под открытым небом... они ошибочны?

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

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

Но можно ещё определений складов придумать в качестве доказательства
вредности одной, пусть даже очевидной и основанной на добросовестной
классификации, иерархии.
1. Склад организованный для отвода глаз. Потоки идут вообще мимо.
Но бухучёт на подложные транспортные потоки ведётся.
2. Склад на продукцию пользующуюся бешеным спросом. Разгрузки-выгрузки нет.
3. Склад на продукцию не пользующуюся спросом. Выгрузки нет.
4. Склад совмещенный с производством (например лесной склад). Поступления нет.
5,6. Акцизный склад. Товары лежат на реальном складе до наклейки этих чёртовых
акцизных марок, которые так мешают открывать пробки. То же таможенный склад.
7. Франко склад, регулирующий ответственность на затраты.
8. Товарным складом признается организация, осуществляющая ... (ст. 907 ГК РФ)

Надо ещё салат к старому новому году делать ... :) Шляпу можно из чего-нибудь
съестного изготовить. Слой варёной картошки, слой отварных сушёных грибов,
слой отварной курицы, майонез, протертый сыр. Рекомендую.

Разговор о складе появился от того, что у природных объектов есть свойства,
которые позволяют разным исследователям выделять одни и те же особенности
(в данном случае функция демпферирования), которые можно организовать
в частную иерархию, которая будет удобна многим.
Но если рассмотреть историю (не логику!) развития иерархии,
то окажется, что на первых порах иерархия (и наследование) помогает.
Однако достижение достаточно сложного дерева наследования приводит к
путанице в структуре, плодит ненужное дублирование свойств и функций у объектов
разошедшихся по дереву иерархии, но требующих сходных свойств или методов.
Есть примеры этого в Delphi в вопросах на Круглом столе.
Именно с этой точки зрения наследование теряет свои плюсы.

Ответ на »сообщение 4237« (Сергей Губанов)
___________________________

1) Object-Oriented Programming = Polymorphism + (Some) Late Binding + (Some) Information Hiding + Inheritance

2) Component-Oriented Programming = Polymorphism + (Really) Late Binding + (Real) Information Hiding + Safety

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

Спасибо за разъяснения. Конечно, теперь совсем другое дело.

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

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

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

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

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

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

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

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

Ответ на »сообщение 4222« (AVC)
Дело не в наследовании как таковом, а в его "глубине" и назначении.
Идеальный вариант -- 2 уровня:
(1) абстрактный (интерфейсный) класс;
(2) класс реализация.

Уровней абстрактных типов может быть более одного. Возьмём фрэймворк Блэкбокса:
ANYPTR --> Stores.Store --> Models.Model --> TextModels.Model --> TextModels.StdModel
ANYPTR --> Stores.Store --> Views.View --> TextViews.View --> TextViews.StdView
Конкретным типом является только один (последний), однако абстрактных типов может быть столько сколько нужно.

----------------------------------------------------------------------------

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

Жаль, что инструментарий компонентного программирования видится всего лишь как серия заплат на инструментарии ООП.

Если бы Вы увидели оригинальную формулу, то не сделали бы такого заключения. Оригинал находится там:

"http://web.archive.org/web/20040616162935/http://www.oberon.ch/resources/component_software/cop.html"
(адресом является вся строка)

1) Object-Oriented Programming = Polymorphism + (Some) Late Binding + (Some) Information Hiding + Inheritance

2) Component-Oriented Programming = Polymorphism + (Really) Late Binding + (Real) Information Hiding + Safety

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

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

Понимаю, что параллель с иерархией классов тут не совсем корректна, но все же…

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

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

В сообщении 4227 я уже говорил, о том, что есть принципиальное различие между комбинированием (композицией, агрегацией) и иерархией наследования. Наверное, нам все же придется рассмотреть один или более примеров, для иллюстрации этих положений. В материале http://www.alexus.ru/russian/articles/design/letter06/index.htm разобраны этапы создания системы и отчасти разобраны вопросы построения композиций (комбинаций).

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

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

Согласны ли Вы с тем, что Ваш основной результат в терминах этой статьи — вычленение инварианта склада (демпфера)?

Согласны ли Вы с тем, что идею предложенного Вами инварианта можно с успехом реализовать не только в качестве вершины иерархии в составе конкретной созданной Вами системы, но и, например, в качестве равноправного компонента или даже в качестве низшего звена другой иерархии?

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

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


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

Это очень интересно.
Правда, у меня создается впечатление, что здесь вопрос уже (почти?) философский.
Чтобы обеспечить гибкость/расширяемость программной системы надо тем или иным способом инкапсулировать изменяющиеся аспекты задачи (в классах; или в данных, как у Меллора), но без введения каких-то инвариантов все равно не обойтись.
Зачастую инварианты (=неизменные аспекты) определяются внешними обстоятельствами -- средой разработки (каркасом) и т.д.
Можно попытаться извлечь их из требований пользователя (заказчика).
Если мы постоянно разрабатываем приложения для данной прикладной области, то можно накопить опыт и обобщить его в виде библиотеки классов или даже специального прикладного каркаса. Но такую библиотеку (или каркас), думается, не удастся создать на основании опыта одного приложения.
Но мне кажется, что у Вас здесь какой-то иной подход. "Платоновский", что ли. Правильно ли я понял?

Ответ на »сообщение 4230« (Горбунов-Посадов)
___________________________

Жаль, что инструментарий компонентного программирования видится всего лишь как серия заплат на инструментарии ООП.

для компонентного программирования обязательно нужна модульность, не требуется безопасность, не обязательно поддерживать наследование (в любой форме), не обязательно и ооп.

помимо модульности требуются интерфейсы. нужна также отчуждаемая persistent-форма хранения. больше ничего.

Ответ на »сообщение 4228« (Горбунов-Посадов)
___________________________
С точки зрения реализации, многократного использования, кажется, продуктивнее иметь базис: равноправные компоненты "Склад-демпфер", "Учет" и др., и их уже произвольно комбирнировать между собой, а не находиться в плену их иерархического выстраивания, к чему нас нередко подталкивает ООП
В сообщении 4227 я уже говорил, о том, что есть принципиальное различие между комбинированием (композицией, агрегацией) и иерархией наследования. Наверное, нам все же придется рассмотреть один или более примеров, для иллюстрации этих положений. В материале http://www.alexus.ru/russian/articles/design/letter06/index.htm разобраны этапы создания системы и отчасти разобраны вопросы построения композиций (комбинаций).