1. Дело в том, что вступление — единственное, его нет в других постах. Просто я не хотел выносить его в отдельный пост.
2. Диаграммы, кстати, очень даже очевидные, стрелочки — чистой воды классика. И да, они унылые, но я предупреждал :)
3. Полностью согласен.
4. Согласен, учту на будущее.
5. Ну, точнее есть одна — перед реализацией Class Adapter, я пояснил про замену множественного наследования на реализацию интерфейсов в Java.
В этом нет необходимости, механизм наследования это подразумевает. Более того, ссылка на базовый класс (AlarmClockImpl) одновременно является ссылкой и на все наследники этого класса.
Честно говоря, не понял, как можно «повторить» атрибут brigde но уже с другим типом. Он же наследуется. Наследуется как есть. Вопрос в другом. Какой именно тип там будет храниться. Этого сказать нельзя. Это даже не обязательно ShellMP3AlarmClock. Это просто ссылка на базовый класс.
LookupAlarmClock — это уточнение абстракции. ShellMP3AlarmClock — уточнение реализации. Связаны они по ссылке bridge на AlarmClockImpl в интерфейсе AlarmClock.
Не совсем так. Во первых мост — это не класс. Это название паттерна. Если говорить более конкретно мост — это 2 интерфейса: Интерфейс абстракции и интерфейс реализации. Причем, интерфейс абстракции содержит ссылку на интерфейс реализации, для делегирования методов оной. Важно понимать, что это два различных интерфейса, с различным набором методов, но реализующих похожие вещи. Абстракция содержит более общие методы (например, toWake() — разбудить). Реализация — простейшие методы (ring() — звонить, может быть showNotifycation() оповестить пользователя). При этом, абстракция использует эти методы для своих корыстных нужд.
Возможно проблема в том, что я сразу привожу диаграммы конкретных практических задач. А в статьях и литературе обычно приводятся абстрактные диаграммы с соответствующими названиями классов, вроде AbstractionInterface, AbstractionImplInterface и т.д. Возможо есть смысл сначала приводить абстрактные диаграммы, а уже потом практические. Я учту это.
Более того, можно было просто воспользоваться cron`ом или планировщиком в Windows. Но моя цель была — изучить и применить паттерн на практике. И то, что у меня не оказалось будильника под рукой — это просто случайность :) Если бы я забыл в гостях утюг. Я бы написал утюг (правда не знаю как, но можно было бы подумать).
Я понимаю Вашу неприязнь к множественному наследованию. Я сам, на самом деле ни разу на практике не применял его. Попросту не было необходимости. Однако, в классической литературе, написанной кстати говоря давненько, говорится, что именно множественное наследование реализует паттерн Class Adapter. И то, что сейчас мы вправе заменить это самое множественное наследование на термин «реализация интерфейса» — это наше право :)
Абсолютно с Вами согласен. Когда я писал про сопровождение кода, я именно это и имел ввиду. Код написанный в соответствии паттернам проще и читать и сопровождать и соответственно обсуждать на тех-же code review.
Новые паттерны, по просьбам трудящихся, будут появляться с периодичностью раз в 2 дня. По крайней мере я буду стараться придерживаться этого цикла.
2. Диаграммы, кстати, очень даже очевидные, стрелочки — чистой воды классика. И да, они унылые, но я предупреждал :)
3. Полностью согласен.
4. Согласен, учту на будущее.
5. Ну, точнее есть одна — перед реализацией Class Adapter, я пояснил про замену множественного наследования на реализацию интерфейсов в Java.
Честно говоря, не понял, как можно «повторить» атрибут brigde но уже с другим типом. Он же наследуется. Наследуется как есть. Вопрос в другом. Какой именно тип там будет храниться. Этого сказать нельзя. Это даже не обязательно ShellMP3AlarmClock. Это просто ссылка на базовый класс.