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

Правильно, только я бы говорил не об определениях (я их не давал), а о семантике (смысле) данного понятия.

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

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

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

я сказал на черное белое? а кто знает, какой я смысл вкладывал в слово "белое"? то-то.

Ответ на »сообщение 4241« (sdf)
___________________________
но если вам так нравится думать... давайте приравняем склад хранилищу и будем говорить, что есть склад (хранилище) и есть склад-демпфер (хранилище-демпфер). так будет понятно?
Подобная «легкость» лежит в основе многих проблем... Простите, но семантики хранилища и склада различны. Это уже обсуждалось.

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

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

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

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

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

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

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

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

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

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

Фиктивный «склад», то есть склада нет, есть только фикция.

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

3. Склад на продукцию не пользующуюся спросом. Выгрузки нет.
==Хранилище.

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

Ответ на »сообщение 4240« (Как слышно? Прием!)
___________________________
Дело в том, что по определению ASU склад - это то, что демпферирует
Правильно, только я бы говорил не об определениях (я их не давал), а о семантике (смысле) данного понятия. Использование склада вне «демпфирования» возможно в той же мере, как и забивание гвоздей микроскопом...

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

Но можно ещё определений складов придумать в качестве доказательства
вредности одной, пусть даже очевидной и основанной на добросовестной
классификации, иерархии.
1. Склад организованный для отвода глаз. Потоки идут вообще мимо.
Но бухучёт на подложные транспортные потоки ведётся.
Фиктивный «склад», то есть склада нет, есть только фикция.

2. Склад на продукцию пользующуюся бешеным спросом. Разгрузки-выгрузки нет.
Нет и склада, торгуют «с колес» (это уже рассматривалось).

3. Склад на продукцию не пользующуюся спросом. Выгрузки нет.
Хранилище.

4. Склад совмещенный с производством (например лесной склад). Поступления нет.
Как... нет? Деревья не растут и не заготавливается древесина?

5,6. Акцизный склад. Товары лежат на реальном складе до наклейки этих чёртовых акцизных марок, которые так мешают открывать пробки. То же таможенный склад.
Типичный склад. Продукция лежит... пока ее не заберут. В чем проблема?

7. Франко склад, регулирующий ответственность на затраты
Это из разряда, морских свинок (в том, смысле, что ни к морю... ни к свиньям... никакого отношения). Франко-склад – означает условия поставки! Например, условие «франко-склад покупателя» означает, что продавец обязан за свой счет и на свой риск доставить товар до склада покупателя.

8. Товарным складом признается организация, осуществляющая ... (ст. 907 ГК РФ)
:)

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

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

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


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


И что характерно -- конкретный класс (в данном случае Models.StdModel) не экспортируется.
Единственное, что меня немного смущает в данной цепочке, -- то, что абстрактные классы Stores.Store и Models.Model (ANYPTR вообще не в счет, т.к. это конструкция языка КП), оставаясь абстрактными, добавляют к записи скрытые поля. Все-таки элемент реализации...

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


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

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


Сергей, большое спасибо за эту ссылку!
Все прежние попадавшиеся мне ссылки на эту статью оказывались недействительными (поэтому и формулу взял с сайта "Информатика-21"), а эта -- работает! :)

Ответ на »сообщение 4239« (Горбунов-Посадов)
___________________________
Но почему-то он не замечает одного из основных механизмов Windows, отвечающего за инсталляцию, -- реестра (регистра). Механизмы реестра, похоже, не разложимы по базису ООП
Реестр представляет собой «базу данных» и с этой точки зрения вполне «разложим по базису ООП».

Ответ на »сообщение 4235« (Горбунов-Посадов)
___________________________
Согласны ли Вы с тем, что Ваш основной результат в терминах этой статьи — вычленение инварианта склада (демпфера)?
Вычленение инварианта – это если и результат, то промежуточный, говоря другими словами, «не цель, но средство».

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

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

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

Может быть, я напрасно упомянул реестр Windows.

реестр имеет иерархическую структуру.

(а) иконки на рабочем столе,

это слабо соотносится с понятием расширяемости. иконка - кнопка вызова приложения. когда иконок мало, они могут произвольно располагаться на панеле задач, которую в windows выполняет рабочий стол. сделано для реализации принципа one click - доступа за один клик. когда иконок много, с ними надо что-то делать, каким-то образом структурировать. представьте ситуацию, когда нужно иметь 250 иконок на столе.

(б) иконки справа и слева на нижней линейке экрана,

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

(в) меню "Программы",

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

(г) однородный список пар "расширение файла — обрабатывающее его приложение".

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

ассоциирование приложения по расширению файла - простая коммутация, которая к полиморфизму имеет достаточно отдаленное отношение. хотя имеет. например, обработка файла с конкретным расширением зависит от того, какое приложение сейчас загружено. берем файлы с расширением pdf: по умолчанию будет запускаться acrobat professional, а если активизировать adobe reader, то файл будет загружаться именно в него без запуска pro. налицо условная коммутация, инициируемая одним расширением. одно расширение - несколько обработчиков с условной коммутацией: это и есть полиморфизм в действии.

Ответ на »сообщение 4234« (AVC)
___________________________
у меня создается впечатление, что здесь вопрос уже (почти?) философский.
Совершенно верно.

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

Если мы постоянно разрабатываем приложения для данной прикладной области, то можно накопить опыт и обобщить его в виде библиотеки классов или даже специального прикладного каркаса. Но такую библиотеку (или каркас), думается, не удастся создать на основании опыта одного приложения
Надо только помнить, что опыт – имеет «две стороны». С одной стороны, он позволяет быстрее получить решение, с другой стороны, он... замедляет процесс принятия решения. С одной стороны, он гарантирует получение качественного решения, а с другой стороны, «качество» может быть некачественным. В этом нет парадокса... все дело в уровне новизны проблемы (даже, казалось бы, в исследованной/изученной предметной области). Для примера, при решении новой задачи в Delphi можно воспользоваться либо готовыми компонентами, либо написать свои. Готовые компоненты – это чей-то концентрированный опыт, который может помочь нам в решении нашей задачи. Но! Компонент может быть много и среди них надо выбирать, что бы сделать хороший выбор, надо потратить время, на то, чтобы изучить их, проверить на совместимость с другими компонентами, обеспечить их соответствие требованиям задачи и т.д. Хорошо если выбор надо сделать из десятка компонент, хуже, если из сотни (качество анализа будет ниже, поскольку время, отпущенное на проект, ограничено, а, следовательно и глубина изучения каждого из многих компонент будет меньше). С другой стороны, выбрав какой-то из компонент, мы вынужденны положиться на то, что его автор не допустил серьезных ошибок, что у нас под рукой будут исходники, что мы сумеем в них разобраться за ограниченное время... Однако, авторы компонентов, как правило, стараются реализовать максимально большую функциональность (максимизация потребительских свойств), большая часть из которой может оказаться избыточной, а необходимая нам функциональность, при этом, может оказаться недостаточно полно и хорошо проработанной. Как следствие потребуется дополнительный код, «привязывающий» компоненты к задаче. В результате общее решение задачи может оказаться избыточно сложным, недостаточно надежным, громоздким и трудным в сопровождении (кто же гарантирует, что авторы будут поддерживать свои компоненты в новой версии Delphi или OS). При этом собственное решение может оказаться значительно проще и легче. Я совсем не призываю создавать каждую программу с нуля, нет... я ратую за продуманное и взвешенное решение.

Но мне кажется, что у Вас здесь какой-то иной подход. "Платоновский", что ли. Правильно ли я понял?
Я исхожу из простого положения: «Все имеет смысл», наша задача понять этот смысл. Даже приступая к анализу требований пользователей, первое, что нужно сделать, на мой взгляд, это понять истоки тех или иных требований...

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

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

(а) иконки на рабочем столе,
(б) иконки справа и слева на нижней линейке экрана,
(в) меню "Программы",
(г) однородный список пар "расширение файла — обрабатывающее его приложение".

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