|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Dmitry Astapov 2:5080/1003 27 Jun 2003 18:53:17
To : Oleg Goodyckov
Subject : Re: еще по поводу модератора
--------------------------------------------------------------------------------
Evening, Oleg.
Oleg Goodyckov <og@videoproject.kiev.ua> 14:17 27/6/2003 wrote:
>> Советую почитать, например, статью "A critique of object-orientation - a
>> technical diatribe"
>> (http://www.programmersheaven.com/search/download.asp?FileID=15651), в
>> особенности - раздел о вреде одной иерархии класифицирования и
>> невозможности завести несколько.
OG> А можно в двух словах узнать смысл невозможности? Бо я скорее всего не
OG> буду читать статью.
Hет, в двух словах - нельзя. Короче, чем там, я не расскажу.
>> А если более формально? Что есть "простое", что есть "сложное"? Я точно так
>> же могу сказать, что все развивается от синего к зеленому ...
OG> В математическом смысле, по Колмогорову: сложность объекта есть длина
OG> минимального его описания. Объём программ вполне может служить
^^^^^^^^^^^^^^^^^^^^^^^^^
OG> показателем сложности (исключая патологические случаи натыкивания
OG> лишнего кода). Объём кода растёт от версии к версии.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1)Является ли код минимальным описанием? Почему?
2)Всегда ли объем растет от версии к версии? Почему?
OG> Следовательно, сложность пакета растёт.
Мне кажется, что следование в данном случае неочевидно.
>> OG> Фактически, между ними нет разницы.
>> Фактически, между ними есть разница.
OG> Какая?
Определение програмного пакета, как я себе его понимаю, не включает в себя
понятие инкапсуляции, наследования и полиморфизма, что затрудняет
исследование общности свойств. Одноко, мне кажется, что програмный пакет нельзя
рассматривать как сущность, реализующую определенное поведение в ответ на
посылку извне сообщений по строго определенному интерфейсу (его нет).
Програмный пакет не является абстракцей некоего понятия из определенной
предметной области. Можно продолжать дальше, но стоит ли ... ?
>> OG> Чистая условность (мы ведь вполне можем написать весь пакет как одно
>> OG> большое приложение - набор классов и объектов, опуская из рассмотрения
>> OG> качество результата).
>> Вот именно. Ты уверен, что для любого пакета ты сможешь построить объектную
>> модель, реализовать ее, и не потерять в функциональности?
OG> Если слово "любого" - в математическом смысле, то нет, не уверен. Hо
OG> на практике, мы можем тривиально взять и простым объединением кодов
OG> всех исполняемых файлов в один и дописыванием несложного обработчика
OG> запросов (который будет потом вызвать любую из частей огромного
OG> командного файла) достичь указанной цели. Собственно, если взять все
OG> системные программы, расположить их в одном непрерывном экстенте
OG> RAM-диска, то запуск любой из тех утилит и будет реализацией того, о
OG> чём я говорил.
Т.е. мы заметаем все проблемы внутрь одной сущности, делаем вид, что это
типа правильная инкапсуляция, и раз уж мы успешно замели проблемы под
ковер, то они нас уже не беспокоят и можно пить пиво, так?
OG> А ОС будет вполне себе объектом класса "ОС Линукс", например.
OG> Согласен, что это пример применения грубой и невежливой силы в тонком
OG> деле ООП ;))) Hо как ни верти, а результат будет именно таким, как
OG> если бы мы взяли и сначала создали объектную модель, а потом написали
OG> бы по ней весь код - получится библиотека программ и набор разделяемых
OG> ими данных. А уж как организовать вызовы тех программ - дело
OG> совершенно десятое.
Это умозрительные построения и игра слов. Тебя послушать - так объектную
модель делать вообще не надо, поскольку можно написать абы как, а потом
завернуть в красивую обертку и результат будет один и тот же. Я просто не
вижу, как можно с тобой спорить, если твои доводы опираются только на
голословные утверждения.
>> OG> быть непременно и полностью тождественны. Hо механизм познего
>> OG> связывания в применении к пакетам мне нравится.
>> Эээээ... Тогда давай сюда свое определение пакета. Потому как слова
>> "позднее связывание" и "пакет libxyz-dev" (или "kernel-doc") у меня как-то
>> в голове рядом не ложаться ...
OG> Пакет - в обычном смысле этого слова.
Я попросил тебя привести определение именно потому, что мне кажется, что ты
оперируешь не "обычным" смыслом этого слова.
OG> А вот позднее связывание... Тут надо прояснить, связывание чего с чем.
OG> В ООП связываются методы с вызовами. Здесь то же, но "вызовом" здесь
OG> будет операция копирования файла (метода в терминологии ООП) в
OG> определённое место на диске (или трансляции, редактирования связей и
OG> т.п.).
И каков же результат этой операции? И какова семантика?
OG> Так что аналогом таблицы виртуальных методов ООП здесь будет служить
OG> файл, описывающий все связи между файлами внутри всех версий пакета.
Можно пример парочки таких связей? Hа примере того же kernel-source-doc,
допустим.
OG> Конкретно - пути формированию текущей версии пакета из имеющихся
OG> файлов. Мне сильно кажется, что в роли такого файла может выступать
OG> всем хорошо известный Makefile. Поскольку, как тут метко заметил
OG> Вагнер, язык написания этих файлов относится к разряду языков
OG> логического программирования, а реализация древовидных (иерархических
OG> то бишь) структур - первейшее призвание таких языков.
--
Dmitry Astapov //ADEpt E-mail: adept@umc.com.ua
GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D
--- ifmail v.2.15dev5
* Origin: People also know me as 2:463/218 (2:5080/1003@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
