Зря вы так. Если хотите знать — я работаю с солидной фирме ведущим программистом и проектировщиком. Уже более 10 лет. Я то, что я пытаюсь объяснить, что некоторые серьезно заблуждаются — увы это лишь опыт, и желание предостеречь остальных… Но мы тут не для того, чтобы мерятся… Поэтому давайте или конструктивно с аргументами или никак…
«И никого не должно волновать, как работает черный ящик.» — я уже писал выше — объявите private, зачем классы городить тогда? И пример с окнами логичен только в том смысле как написано у меня в статье, как разделение двух иерархий при наследовании — и ни для чего больше. Но это не имеет отношения к разделению абстракции и реализации. И как и ожидалось такая формулировка лишь путает… поэтому позвольте уж мне высказать, чем авторы паттерна совершенно не правы.
Проблема в том, что «Мост» — это анти-паттерн. И вот вам такой вопрос: как по вашему использование паттернов — это чистое ООП или нет? И еще: когда вы разделяете один класс на два — вы это делаете произвольно или по какому-то критерию? Если по критерию то, как вам кажется должны ли появится значимые сущности или допустимы искусственные образования? А если мы не можете дать четкое название классу и пишите «НазваниеКлассаImpl» — вы понимаете за что ответственен класс?
Давайте по очереди. На примере будильников Вы согласны? Тогда пойдем дальше. Я утверждаю, что выделить реализацию из класса (точнее деля их на два) нельзя в принципе. Это будет не реализация, а одно из двух или произвольное разделение на сущности, или то о чем статья выделение агрегирующего класса, но тогда это будет не реализация «будильника», а просто другой класс, который нужно агрегировать в «будильник». Поэтому я говорю вообще. Я рассмотрел про будильники — как неудачное выделение методов. Но я также рассмотрел и изначальный пример авторов из книги — и он тоже не удачный в принципе. Ниже в комментариях мне предложили еще один пример — посмотрю напишу. Если хотите предложите еще вариант — любой пример я смогу объяснить чем плох, или что он просто не о том (просто совпадение применения агрегации, с такой ненужностью как «мост»).
Вопрос в методе. Давайте вначале определимся, что есть абстракция, а что реализация. Начнем издалека. Если мы классически подойдем, то что такое абстракция? Это некая спецификация класса, т.е. в С++ — это .h файлы. А реализация это собственно тело методов, т.е. в С++ — это .cpp файлы. В С# уже отошли от этого, и так рельефно спецификацию от реализации уже не различают. Почему? Потому что фактически это не удобно для редактирования. Поэтому разделение на абстракцию/реализацию уже мыслится более условно, как спецификация (количество и тип входных/выходных параметров) методов/свойств и прочего и их реальная реализация в коде.
Теперь к нашим баранам. Ну посмотрите на статью, про будильники. Объясните мне пожалуйста, почему LockupAlarmClock — называется абстракцией, а AlarmClockImpl — реализацией?
Это настоящая фикция, и тот и другой класс имеет и абстракцию и реализацию. Тогда важный вопрос: чем реализация LockupAlarmClock отличается от AlarmClockImpl? Да, ничем — совершенное произвольное разделение одной сущности будильник на две с неясными границами.
Зачем? Хотите скрыть от использующего детали реализации — объявите видимость private. Зачем порождение излишних сущностей? И как оказывается совсем не для этого — об этом статья и написана.
А теперь отвечая на вопрос — по сути такое использование — это вынесение всего private в отдельный класс. Зачем? Если как я показываю в статье есть причины из-за разных классификаций при наследовании, это одно (т.е. выделение в подкласс методов ответственных за под задачи — рефакторинг «Выделение подкласса»). Если же искусственно как у будильников — это только ведет к непониманию предметной задачи, точнее ее точек роста.
Теперь к нашим баранам. Ну посмотрите на статью, про будильники. Объясните мне пожалуйста, почему LockupAlarmClock — называется абстракцией, а AlarmClockImpl — реализацией?
Это настоящая фикция, и тот и другой класс имеет и абстракцию и реализацию. Тогда важный вопрос: чем реализация LockupAlarmClock отличается от AlarmClockImpl? Да, ничем — совершенное произвольное разделение одной сущности будильник на две с неясными границами.
Зачем? Хотите скрыть от использующего детали реализации — объявите видимость private. Зачем порождение излишних сущностей? И как оказывается совсем не для этого — об этом статья и написана.
А теперь отвечая на вопрос — по сути такое использование — это вынесение всего private в отдельный класс. Зачем? Если как я показываю в статье есть причины из-за разных классификаций при наследовании, это одно (т.е. выделение в подкласс методов ответственных за под задачи — рефакторинг «Выделение подкласса»). Если же искусственно как у будильников — это только ведет к непониманию предметной задачи, точнее ее точек роста.