Правильный вывод тут такой: и учёный, и неуч конечно могут быть как религиозными людьми, так и атеистами, но, как правило, ученые — атеисты, а неучи — верующие.
300 лет назад наука, как таковая, только зарождалась. И ученых, как таковых, не было. А как доросли до неопозитивизма и прочей современной научной философии, так сразу и поняли, что совмещать-то особо не получится.
Ну, я согласен с тем, что сама по себе диаграмма не слишком выразительна. Но это потому, что нужно читать сопроводительный текст. UML сам по себе не может все объяснить.
Вы не различаете реальный тип объекта, который передается на вход, и тип параметра функции. Тип объекта — не IDrawingApi (хотя бы потому, что это вообще интерфейс). Тип параметра конструктора — именно IDrawingApi. Далее вспоминаем все, что я говорил раньше, и понимаем, что стрелки не нужны.
Ок. По вашей ссылке определение такое: «Зависимость существует, если класс Х — это параметр, член или локальная переменная в методе класса А». В случае паттерна Bridge наследники Б, в отличие от самого Б, под это определение не подходят.
Я напоследок позанудствую. По вашей логике, если некий класс А работает с иерархией классов (имеющих базовый класс Б) через указатель/ссылку на базовый, нужно в UML-диаграмме провести зависимости из класса А во всех возможных потомков Б. Так вот, это неправильно. Зависимость А->Х означает «изменение спецификации Х влечет за собой изменение А». В нашем случае для А имеют значение только изменения Б, интерфейса к Х. А детали реализации его потомков (включая, возможно, публичные функции, не объявленные в Б) нам абсолютно не важны. Потому и стрелочки такие тут рисовать нельзя.
Во первых, какие еще варианты с точки зрения мгновенного понимания могут быть? Я бы понял, если бы была альтернативная интерпретация этой диаграммы. Но ведь нету ее. Что еще может пойти на вход конструктору, если не подклассы абстрактного класса AlarmClockImpl?
Во-вторых, что еще за «простые стрелочки»? В UML есть агрегация, композиция, наследование, реализация и зависимость. Ваши «простые стрелочки» ни к одному из этих типов не относятся.
В целом, мне проще отослать вас вот сюда. Хотя, если вы не поняли эту статью (с довольно понятной, к слову, UML-диаграммой классов), то, наверное, и статью по ссылке не поймете.
В С++:
virtual ReturnType VirtualFunc(ParamType param); — виртуальная функция (можно переопределить в производном классе).
virtual ReturnType PureVirtualFunc(ParamType param) = 0; — чисто виртуальная функция (нужно переопределять в производном классе).
Во первых, какие еще варианты с точки зрения мгновенного понимания могут быть? Я бы понял, если бы была альтернативная интерпретация этой диаграммы. Но ведь нету ее. Что еще может пойти на вход конструктору, если не подклассы абстрактного класса AlarmClockImpl?
Во-вторых, что еще за «простые стрелочки»? В UML есть агрегация, композиция, наследование, реализация и зависимость. Ваши «простые стрелочки» ни к одному из этих типов не относятся.
virtual ReturnType VirtualFunc(ParamType param); — виртуальная функция (можно переопределить в производном классе).
virtual ReturnType PureVirtualFunc(ParamType param) = 0; — чисто виртуальная функция (нужно переопределять в производном классе).