Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, LIS, Вы писали:
LIS>>Компонент = модуль с точки зрения статического анализа его исходного кода по направлениям:
VD>Не может быть компонет "с точки зрения". Или мы о КООП и тогда компонент имеет конкретный смысл. Или вообще не ясно о чем мы говорим.
Не "компонент с точки зрения", а "компонент = модуль с точки зрения", т.е. есть вода, а есть бензин, но с точки зрения анализа текучести к ним применяются одни и те же методы (пример дурацкий, но смысл я думаю понятен)
LIS>>1. Анализа структуры логических объектов, из которых он состоит (под объектами я здесь понимаю процедуры или классы) LIS>>2. Анализа потока управления программы внутри компонента (модуля) LIS>>3. Анализа потока данных внутри компонента (модуля)
VD>Нельзя рассматриватьв все эти аспекты в рамках модуля.
Почему? В рамках компонента или класса можно, а в рамках модуля — нет? Не понял... (с)
LIS>>А вот с точки зрения анализа взаимодействия с внешней средой:
LIS>>процедура -> класс -> модуль -> компонент
VD>Это вообще чушь. В КООП "класс" == "компонент". Таким образом модуль содержит классы которые могут являться компонентом. Классы же содержат методы.
LIS>>т.е. модуль выступает просто как контейнер
VD>В твоей схеме модуль идет между классом и компонентом. Так чему он по-твоему является контейнером.
LIS>>ЗЫ. Уж больно тонка грань между этими понятиями...
VD>Грань то нормальна. Просто нужно ее понимать вот тут http://en.wikipedia.org/wiki/Software_component все более менее описано.
Прочитал — там написано что обычно компонент = классу!
До понедельника придумаю примеры и на них попробуем разобрать что есть что, а щас надо бежать тяпничать
Здравствуйте, LIS, Вы писали:
LIS>Обидно как-то... LIS>Неужели никто не интересовался такой темой, как получение количественных оценок по исходному коду программы?
Может быть нужно было именно этот вопрос выносить в качестве темы?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, LIS, Вы писали:
LIS>Прочитал — там написано что обычно компонент = классу!
А знашь что такое "обычно"? Это значит, что если не оговорено обратное, то все будут считать что ты говоришь в рамках "компонент = класс".
Так вот Губанов здесь уже достал всем втюхивать свое личное понимание КОП. Если бы он при этом делал оговорку, что мол моя позиция исходит из несколько необычных предполсылок и т.п., то вопросо бы не было. Но он проста таки навязыывает свое мягко говоря спорное мнение. Вот это и задевает.
LIS>До понедельника придумаю примеры и на них попробуем разобрать что есть что, а щас надо бежать тяпничать
Какой интересный термин "тяпничать". Это всмысле тяпать по пятницам?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, LIS, Вы писали:
LIS>Неужели никто не интересовался такой темой, как получение количественных оценок по исходному коду программы?
А что могут мне сказать о качестве кода такие вещи как 150 классов, 50000 строк или 200000 операторов? В случае той же аналогии со зданиями. измерить стоимость здания в кирпичах приблизительно можно, но в случае программного кода — это чушь. Иногда может даже оказаться всё с точностью до наоборот.
... << RSDN@Home 1.1.4 stable rev. 510>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>А что могут мне сказать о качестве кода такие вещи как 150 классов, 50000 строк или 200000 операторов? В случае той же аналогии со зданиями. измерить стоимость здания в кирпичах приблизительно можно, но в случае программного кода — это чушь. Иногда может даже оказаться всё с точностью до наоборот.
Ага, вот например, любая кирпичная многоэтажка в кирпичах намного дороже чем скажем Музей Ленина. Но не думаю, что это так на самом деле.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, LIS, Вы писали:
LIS>>Обидно как-то... LIS>>Неужели никто не интересовался такой темой, как получение количественных оценок по исходному коду программы?
VD>Может быть нужно было именно этот вопрос выносить в качестве темы?
Ды было дело — толку ноль Вот и решил лучше спрашивать отдельные конкретные вопросы.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, LIS, Вы писали:
LIS>>Неужели никто не интересовался такой темой, как получение количественных оценок по исходному коду программы?
IT>А что могут мне сказать о качестве кода такие вещи как 150 классов, 50000 строк или 200000 операторов? В случае той же аналогии со зданиями. измерить стоимость здания в кирпичах приблизительно можно, но в случае программного кода — это чушь. Иногда может даже оказаться всё с точностью до наоборот.
Самая часто встречаемая реакция
А Вы кроме этих метрик еще какие-нибудь знаете? (без наезда )
С другой стороны, возьмем модный нынче рефакторинг: примерная интерпретация — "Если у вас в методе (классе, ...) слишком много временных переменных (методов, ...), то следует сделать то и то с этим методом (классом)". Чем это не статический анализ характеристик программного кода? Так же считаем количество переменных, методов, классов, также оцениваем количественно их связи...
Никто ведь не говорит что эти метрики являются панацеей от всех проблем (как многие это воспринимают) — это просто еще один инструмент разработчика для создания хороших программ.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, ты сам то свою ссылку читал? Там есть замечательные слова: VD>
The combination of some aspects of object-oriented programming, safety, and modularity with extensibility as a goal is called Component-Oriented Programming.
VD>То есть ООП как бы подразумевается как базис.
Естественно. Я про это всегда и говорил. КОП есть результат скрещивания ООП и Модульности.
(КОП) = (ООП) + (Модульность) + (Некоторые ограничения связанные с несовместимостью мэйнстримного ООП с Модульностью).
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, LIS, Вы писали:
LIS>>Прочитал — там написано что обычно компонент = классу!
VD>А знашь что такое "обычно"? Это значит, что если не оговорено обратное, то все будут считать что ты говоришь в рамках "компонент = класс".
Я так понимаю, что мы пришли опять к началу
КОП предполагает объединение ПП-процедур или ООП-объектов в компоненты по принципу функциональной общности и целостности.
В частном (вырожденном) случае компонент = класс, с чем я и не спорил.
VD>Так вот Губанов здесь уже достал всем втюхивать свое личное понимание КОП. Если бы он при этом делал оговорку, что мол моя позиция исходит из несколько необычных предполсылок и т.п., то вопросо бы не было. Но он проста таки навязыывает свое мягко говоря спорное мнение. Вот это и задевает.
Ну тут многие высказываются подобным образом , просто Сергей один из наиболее ярких и стойких "ораторов" (2 Сергей — без обид )
LIS>>До понедельника придумаю примеры и на них попробуем разобрать что есть что, а щас надо бежать тяпничать
VD>Какой интересный термин "тяпничать". Это всмысле тяпать по пятницам?
Есть такая слабинка
Здравствуйте, VladD2, Вы писали:
VD>Так вот Губанов здесь уже достал всем втюхивать свое личное понимание КОП. Если бы он при этом делал оговорку, что мол моя позиция исходит из несколько необычных предполсылок и т.п., то вопросо бы не было. Но он проста таки навязыывает свое мягко говоря спорное мнение. Вот это и задевает.
Маугли: Багира, а я могу достать вон тот кокосовый орех.
Багира: Да, можешь.
Маугли: Багира, а я могу достать и вон те кокосовые орехи тоже.
Багира: Да, можешь.
Маугли: Багира, а я могу достать и вон те кокосовые орехи которые растут на самой макушке.
Багира: Да, можешь.
Маугли: Багира, а я могу достать еще и вон те орехи.
Багира: Да, Маугли, ты кого угодно можешь достать.
Чтобы понять что такое компонент, нужно задать вопрос: "Компонент чего?". После того как ответ получен, становится понятным и что такое компонент.
0) Если процедура — это компонент, то компонент чего?
1) Если объект — это компонент, то компонент чего?
2) Если класс — это компонент, то компонент чего?
3) Если EXE или DLL модуль — это компонент, то компонент чего?
...
Компонентами модульной расширяемой системы являются модули. Модули — это компоненты модульных расширяемых систем.
Компонентами библиотеки классов являются классы. Класс — это компонент библиотеки классов.
Объект является компонентом какого-то другого объекта-агрегата.
Процедура является компонентом, э-э-э, даже не знаю чего, наверное процедурной программы ...
Здравствуйте, LIS, Вы писали:
LIS>Самая часто встречаемая реакция LIS>А Вы кроме этих метрик еще какие-нибудь знаете? (без наезда )
Мысль здравая, но есть маленькая неприятность...
LIS>С другой стороны, возьмем модный нынче рефакторинг: примерная интерпретация — "Если у вас в методе (классе, ...) слишком много временных переменных (методов, ...), то следует сделать то и то с этим методом (классом)". Чем это не статический анализ характеристик программного кода? Так же считаем количество переменных, методов, классов, также оцениваем количественно их связи...
Вот это может оценить лишь человек, да и то два разработчика передерутся — одному покажется мало, другому много.
LIS>Никто ведь не говорит что эти метрики являются панацеей от всех проблем (как многие это воспринимают) — это просто еще один инструмент разработчика для создания хороших программ.
Сама идея прекрасная. Вообще наверное об этом стоит спросить у Gaperton'а — он несколько раз предлагал весьма интересные идеи относительно метрик кода.
Подобная тема обсуждалась здесь
Предположим у нас есть некий элементарный текстовый редактор типа Notepad. Кроме стандартной функциональности у него есть две дополнительные возможности:
1. Plug-in, реализующий воспроизведение макросов на 2 ЯП — XScript & ZScript. Каждый плагин состоит из двух частей:
— компилятор (Compiler): выполняет функции синтаксического разбора кода и построения некоего промежуточного кода
— run-time система (.DA): выполняет промежуточный код
Использование:
— на вход .DA подается текст макроса
— Compiler преобразует исходный текст макроса в промежуточный код и возвращает его в .DA
— .DA выполняет промежуточный код
Реализация: Compiler & .DA реализованы как
а) 4 отдельные .dll: X_Compiler.dll, Z_Compiler.dll, X_DA.dll, Z_DA.dll
б) 2 отдельные .dll: X_Script.dll, Z_Script.dll
в) 3 отдельные .dll: X_Compiler.dll, Z_Compiler.dll и общая для обоих языков run-time system .DA
При проектировании использовался ООП-подход (т.е. все делалось через классы)
Для каждого ЯП общие низкоуровневые функции (парсинг строки по разделителям, работа с деревом и т.п.) вынесены в общую библиотеку CommonLowLevelFunctions.dll в виде набора функций.
Что здесь по Вашему является компонентом, а что модулем?
Мое мнение:
1. CommonLowLevelFunctions.dll — ПП-компонент (т.е. компонент, построенный на основе процедур)
а) X_Compiler.dll + X_DA.dll — X модуль, Z_Compiler.dll + Z_DA.dll — Z модуль, все dll — ООП-компоненты
б) X_Script.dll, Z_Script.dll — просто компоненты
в) ?
2. Plug-in, позволяющий перехватывать набранный текст и пересылать его по сети специальной программе-клиенту. Этот механизм состоит из трех частей:
— библиотека Hook.dll которая и подключается как plug-in, в ней два класса — один отвечает за перехват набранного текста, второй — за пересылку этого текста программе-клиенту.
— программа-клиент также состоит из двух частей: получения данных от "сервера" и сохранение их на диск
Что здесь по Вашему является компонентом, а что модулем?
Мое мнение:
Hook.dll — компонент
Программа-клиент — модуль из 2-х компонентов
Здравствуйте, AndreyFedotov, Вы писали:
LIS>>С другой стороны, возьмем модный нынче рефакторинг: примерная интерпретация — "Если у вас в методе (классе, ...) слишком много временных переменных (методов, ...), то следует сделать то и то с этим методом (классом)". Чем это не статический анализ характеристик программного кода? Так же считаем количество переменных, методов, классов, также оцениваем количественно их связи...
AF>Вот это может оценить лишь человек, да и то два разработчика передерутся — одному покажется мало, другому много.
Да и пусть дерутся — главное что бы мы знали что эти цифры означают, как их получить и как ими пользоваться, а оценивать все равно в конечном итоге будет человек.
LIS>>Никто ведь не говорит что эти метрики являются панацеей от всех проблем (как многие это воспринимают) — это просто еще один инструмент разработчика для создания хороших программ.
AF>Сама идея прекрасная. Вообще наверное об этом стоит спросить у Gaperton'а — он несколько раз предлагал весьма интересные идеи относительно метрик кода. AF>Подобная тема обсуждалась здесь
Здравствуйте, LIS, Вы писали:
IT>>А что могут мне сказать о качестве кода такие вещи как 150 классов, 50000 строк или 200000 операторов? В случае той же аналогии со зданиями. измерить стоимость здания в кирпичах приблизительно можно, но в случае программного кода — это чушь. Иногда может даже оказаться всё с точностью до наоборот.
LIS>Самая часто встречаемая реакция
И это очень здорово. Наконец-то народ начинает понимать, что одними строками код не измерить.
LIS>А Вы кроме этих метрик еще какие-нибудь знаете? (без наезда )
Знаю. Последнее время меня постоянно преследует навязчивая идея о том, что хорошее решение должно порождать простой прикладной код, очень хорошее – очень простой, а идеальное решение – синоним примитивного кода.
Возможно это очень грубая метрика, но практика показывает, что она работает. Например, если у вас проблема с выбором одного из подходов к решению того или иного вопроса, то просто сделайте тестовые примеры того, как будет выглядить прикладной код. То решение, для которого прикладной код будет проще с вероятностью 99% будет правильней. И как следствие — как только сложность прикладного кода начинает напрягать, нужно начинать искать другие решения.
Т.е. фактически всё сводится к тому сколько телодвижений должен делать прикладной программист, чтобы решить ту или иную задача. Поэтому, правильная метрика должна выражаться в телодвижениях
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Естественно. Я про это всегда и говорил. КОП есть результат скрещивания ООП и Модульности.
СГ>(КОП) = (ООП) + (Модульность) + (Некоторые ограничения связанные с несовместимостью мэйнстримного ООП с Модульностью).
Мне показалось, что ты постоянно говоришь о КОП вообще при отсуствии ООП. У тбя КОП == DLL.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Т.е. фактически всё сводится к тому сколько телодвижений должен делать прикладной программист, чтобы решить ту или иную задача. Поэтому, правильная метрика должна выражаться в телодвижениях
Согласен, но хочу заметить, что телодвижения того кто будет читать этот код и тмболее править куда важнее.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Знаю. Последнее время меня постоянно преследует навязчивая идея о том, что хорошее решение должно порождать простой прикладной код, очень хорошее – очень простой, а идеальное решение – синоним примитивного кода.
IT>Возможно это очень грубая метрика, но практика показывает, что она работает. Например, если у вас проблема с выбором одного из подходов к решению того или иного вопроса, то просто сделайте тестовые примеры того, как будет выглядить прикладной код. То решение, для которого прикладной код будет проще с вероятностью 99% будет правильней. И как следствие — как только сложность прикладного кода начинает напрягать, нужно начинать искать другие решения.
Согласен на все 100%!!! Кстати, а ведь рефакторинг можно назвать "упрощением кода"...
IT>Т.е. фактически всё сводится к тому сколько телодвижений должен делать прикладной программист, чтобы решить ту или иную задача. Поэтому, правильная метрика должна выражаться в телодвижениях
Если нам не помогут, то мы тоже никого не пощадим.
Вот и решил лучше спрашивать отдельные конкретные вопросы.
