|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Oleg Goodyckov 2:5020/400 01 Jul 2003 22:15:14
To : Dmitry Astapov
Subject : Re: еще по поводу модератора
--------------------------------------------------------------------------------
On Fri, Jun 27, 2003 at 05:53:17PM +0400, Dmitry Astapov wrote:
> OG> В математическом смысле, по Колмогорову: сложность объекта есть длина
> OG> минимального его описания. Объём программ вполне может служить
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> OG> показателем сложности (исключая патологические случаи натыкивания
> OG> лишнего кода). Объём кода растёт от версии к версии.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 1)Является ли код минимальным описанием? Почему?
Возможно, не абсолютно минимальным, но в каких-то пределах. Потому, что
написание программы стоит ресурсов. А всякий "нормальный" писатель
стремится к минимизации затрат.
> 2)Всегда ли объем растет от версии к версии? Почему?
Когда человек задаёт вопросы с очевидными ответами, возникает подозрение,
что дискуссию он ведёт не в познавательных целях, а в целях кого-то
победить. Если ты хочешь меня победить, то лучше давай прекратим. Можешь
пальму первенства взять себе сразу.
> OG> Следовательно, сложность пакета растёт.
> Мне кажется, что следование в данном случае неочевидно.
Если исходит из означенных выше целей, то - да, не очевидно. Hо если
просто по здравому смыслу и жизненному опыту, то - очевидно. В подавляющем
большинстве случаев.
> >> OG> Фактически, между ними нет разницы.
> >> Фактически, между ними есть разница.
> OG> Какая?
> Определение програмного пакета, как я себе его понимаю, не включает в себя
> понятие инкапсуляции, наследования и полиморфизма, что затрудняет
> исследование общности свойств.
Hаследование и полиморфизм в пакетах представлены во весь рост
(наследование файлов данных от версии к версии и изменение их содержания
при сохранении названия (полиморфизм)). С инкапсуляцей - немножко сложнее.
Hо тоже - вполне поправимо. В пакете присутствуют данные (да хотя бы те же
мейкфайлы), которые извне не видимы (условно говоря, разумеется) и
предназначены только для внутреннего потребеления. В крайнем случае,
таковых данных нет и свойтство инкапсуляции мы можем считать
наличествующим над пустым множеством. То есть, просто не применяющимся.
Что не отвергат парадигму ООП вцелом.
> Одноко, мне кажется, что програмный пакет нельзя рассматривать как
> сущность, реализующую определенное поведение в ответ на посылку извне
> сообщений по строго определенному интерфейсу (его нет).
Сложность здесь лишь в том, что сам пакет - это всего лишь данные. Их
поведение сводится к: а) лежать; б) молча :)))
Их стандартное поведение должен обеспечивать файл конфигурации и
программа, интерпретирующая его. Так что в этом смысле у пакета должен
быть стандартный интерфейс. С чего, собственно и начался мой тренд(ёжь):
остандартить интерфейс к пакетам и тогда можно обойтись без промочек вроде
rpm.
> Програмный пакет не является абстракцей некоего понятия из определенной
> предметной области. Можно продолжать дальше, но стоит ли ... ?
Hу не знаю. Завист от целей, тобой преследуемых.
> OG> на практике, мы можем тривиально взять и простым объединением кодов
> OG> всех исполняемых файлов в один и дописыванием несложного обработчика
> OG> запросов (который будет потом вызвать любую из частей огромного
> OG> командного файла) достичь указанной цели. Собственно, если взять все
> OG> системные программы, расположить их в одном непрерывном экстенте
> OG> RAM-диска, то запуск любой из тех утилит и будет реализацией того, о
> OG> чём я говорил.
> Т.е. мы заметаем все проблемы внутрь одной сущности, делаем вид, что это
> типа правильная инкапсуляция, и раз уж мы успешно замели проблемы под
> ковер, то они нас уже не беспокоят и можно пить пиво, так?
О каких преблемах речь?
> OG> А ОС будет вполне себе объектом класса "ОС Линукс", например.
> OG> Согласен, что это пример применения грубой и невежливой силы в тонком
> OG> деле ООП ;))) Hо как ни верти, а результат будет именно таким, как
> OG> если бы мы взяли и сначала создали объектную модель, а потом написали
> OG> бы по ней весь код - получится библиотека программ и набор разделяемых
> OG> ими данных. А уж как организовать вызовы тех программ - дело
> OG> совершенно десятое.
> Это умозрительные построения и игра слов. Тебя послушать - так объектную
> модель делать вообще не надо, поскольку можно написать абы как, а потом
> завернуть в красивую обертку и результат будет один и тот же. Я просто не
> вижу, как можно с тобой спорить, если твои доводы опираются только на
> голословные утверждения.
Как голословные? Я ж тебе привёл конкретный пример реализации некого
класса без предварительного составления объектной модели и выполнения
прочих реверансов. Этот обходной путь как раз и есть, по мне, главная дыра
ООП, через которую убегают от него разработчики: можно обойтись и без
ломания головы над схемами и связями. И результат будет рабочим. И, как
показывает практика, достаточно качественным для насущных потребностей.
Ядро Линукса (да и любой ОС, за исключениями Mach3, наверно) - тому пример.
Согласен, что не всегда столь красивым и технологичным, как при
использовании ООП. Hо по критерию "эффективность/стоимость" это не всегда
и нужно.
> OG> А вот позднее связывание... Тут надо прояснить, связывание чего с чем.
> OG> В ООП связываются методы с вызовами. Здесь то же, но "вызовом" здесь
> OG> будет операция копирования файла (метода в терминологии ООП) в
> OG> определённое место на диске (или трансляции, редактирования связей и
> OG> т.п.).
> И каков же результат этой операции? И какова семантика?
Результат - выполнение или не вполнение операции.
А что здесь есть "семантика"?
> OG> Так что аналогом таблицы виртуальных методов ООП здесь будет служить
> OG> файл, описывающий все связи между файлами внутри всех версий пакета.
> Можно пример парочки таких связей? Hа примере того же kernel-source-doc,
> допустим.
Hу как там в мейкфайлах:
2.4.18 doc1.txt doc2.txt doc3.txt ...
2.4.19 doc1.txt doc3.txt ...
all 2.4.18 2.4.19
Дерево связей, в общем. Строим граф вхождений файлов в пакеты разных
версий и описываем его.
--- ifmail v.2.15dev5
* Origin: unknown (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
