Hi Harry.
17 Sep 2003, 20:25, Harry Zhurov writes to Dimmy Timchenko:
DT> Классы - слишком тяжеловесный механизм и нужны далеко не везде.
HZ> Что там тяжеловесного?
Да сама парадигма. Hе знаю, может, это личные особенности восприятия, но для меня читаемость и понимаемость "объектного" кода на порядок ниже, чем "структурного". Слишком высокая связность. Если структурный код легко разбивается на отдельные функции и модули, если я могу выхватить для своих нужд одну функцию из библиотеки и больше ни о чём не думать, то в случае классов надо держать в голове всю иерархию.
HZ> Более того, никто не заставляет использовать использовать классы HZ> вообще, и этого не следует делать где попало.
Именно! Классы хороши там, где сама структура моделируемого "мира" близка к объектной. МК в большинстве применений - не тот случай. А инкапсуляция на уровне модулей совершенно естественно вписывается в структурную парадигму, которая, опять же, практически универсальна.
DT> Пользоваться ими только для инкапсуляции - стрелять из пушки по DT> воробьям.
HZ> Это почему же? Что, оверхед что-ли появляется? Hет там никакого HZ> оверхеда, а есть только более защищенная модель со статической HZ> проверкой типов.
Для чего совершенно не нужны классы. :)
Вот в Аде всё ООП делается на уровне _типа_. Для динамического полиморфизма просто был введён атрибут tagged.
HZ> И инкапсуляция, кстати, очень важная и полезная вещь, т.ч. и HZ> она - не "воробьи". :)
Безусловно. Поэтому я хочу иметь её в чистом виде, без линкора классов. :) Элементарное средство - модуль...
DT> Да и стиль объектный от структурно-модульного значительно DT> отличается: при DT> совмещении получается эклектика,
HZ> С++ - язык гибридный, он поддерживает несколько парадигм, HZ> которые вполне органично дополняют друг друга (не понимаю, где ты HZ> там эклектизм углядел?)
Да посмотри на любой исходник C++ с интенсивным использованием классов: понять ничего невозможно.
DT> да и для МК, опять же, это не особо полезно.
HZ> И тут не согласен. ООП реализуется через полиморфизм, и HZ> реализовать то же, что дает полиморфное поведение объектов, руками HZ> выйдет вряд ли эффективнее.
Hу и какие задачи, решаемые встроенными системами, скажем так, "существенно объектны"? ООП хорошо для всякого рода гуёв и для моделирования и симуляции сложных систем - для чего ещё, с ходу не скажу. А для фирмвари мобильника, микроволновки, АТС, топливораздаточной колонки, кассового аппарата и так далее
- совершенно неаутентично.
HZ> Имею некоторый опыт - то, что ранее на С приходилось делать с HZ> помощью тупых проверок на switch'ах или с помощью массивов HZ> указателей на функции, сейчас реализуется с помощью иерархий HZ> классов с виртуальными функциями.
Может, в отдельных случаях и удобнее, но тянет за собой эклектику. Мне как-то и проверки "на switch-ах" не жмут. :) Если, скажем, протокол описывается таблицей или конечным автоматом, то и реализовывать его удобно в похожем на описание виде.
DT> А без модулей - неудобно: все эти h-файлы синхронизировать,
HZ> А что означает "h-файлы синхронизировать"?
Поддерживать соответствие изменениям в C-файле.
HZ> И как в Аде интерфейс модуля экспортируется в другую единицу HZ> трансляции?
С помощью так называемых пакетов (packages). Пишется:
package BlaBla is
... -- здесь все определения и описания
end BlaBla;
package body BlaBla is
... -- здесь тела всех процедур и функций
begin
... -- опционально - секция инициализации
end BlaBla;
А потом, при использовании в другом модуле, пишем:
with BlaBla; use BlaBla; -- опционально, чтобы не писать BlaBla.<имя-объекта>
и работаем с любыми программными объектами, описанными в интерфейсной секции пакета.
DT> да и проверки лишние не помешали бы.
HZ> Которые нельзя отключить?
Какой в них смысл, если их можно отключить? :) Абсолютно всё, что ты хочешь сказать и сделать, можно сделать по правилам языка, без трюков. Жёсткая типизация, вообще жёсткие проверки - это не помеха, а помощь программисту, это отлов максимально возможного числа ошибок на этапе компиляции.
HZ> Возвращаясь к исходному вопросу: что дает модуль, чего бы HZ> нельзя было выразить с помощью класса?
Для меня вопрос ставится иначе: как можно добиться нужного мне результата максимально простым, надёжным, понятным, "читаемым" способом. Ортогональность семантики. Hужна инкапсуляция - использую средство именно для инкапсуляции - тип, модуль, процедуру.
HZ> И чем реализация с помощью класса уступает реализации с помощью HZ> модуля? Пример можно привести? Хоть на Аде, хоть псевдокод.
Это ж целые программы надо приводить. :) Могу мылом прислать исходники библиотек GNUсного компилятора Ады - GNAT.
Dimmy.