Если действительно много раз, дайте ссылку. Когда я первый раз настраивал udpxy пришлось потратить несколько часов на изучение вики OpenWrt и подобных материалов.
В любом случае теперь у меня есть небольшой мануал, по которому сделать это можно намного быстрее.
Вы умело вырываете фразы из контекста. Мой пример этот вовсе не пример перемешивания логики, это просто пример, если хотите псевдо-код отражающий общий смысл.
Вот кстати цитата из той же книги. Все, - теперь клиенты нашей системы могут свободно запускать данные команды добавления и редактирования в контекстах файлов или базы данных:
Обратите на код в методе main – это то, что и достигается применением данного паттерна: независимый, единый код запуска любых видов команд в любом контексте, который не нужно будет менять и перекомпилировать при каких-либо изменениях в деталях реализации тех или иных операций, алгоритмов выполнения команд и т.д.
Конкретные реализации clientUpdateImpl и balanceCorrectImpl для простоты здесь определяются напрямую, но как говорилось выше часто бывает полезно получать их динамически в конструкторе команды (Command) из абстрактной фабрики.
Мост как раз при чем. Читайте определение паттерна. Используя его во всех указанных примерах мы можем выбрать конкретную реализацию во время выполнения программы.
Ткните меня носом в строку в которой сказано что необходимо создать отдельные классы “МашинаРеализация" и «машина абстракция». Если ткнете я публично признаюсь что я последний идиот. Если нет то это придется сделать вам.
НЕТ! Речь не про публичную спецификацию класса! Речь про весь класс целиком! Изменить реализацию нужно так, что бы файл с абстракцией даже не нужно было открывать (представьте что он закодирован и исходников у вас нет).
конкретный пример:
Имеется окно. Цвет и размер окна хранятся в файле (пусть будет XML, это не важно)
Исходя из ваших слов, мне достаточно в классе окна получать цвет и размер при помощи приватного метода. Что то типа private function getParam(){
return readXML();
}
Но что будет если конфигурация приложения изменилась и теперь параметры хранятся в БД? Вам ничего не останется как изменить уже существующий класс, вставив вместо readXML() что то типа select * from table window.
Банда четырех вместо этого предлагает вынести реализацию чтения свойств в отдельный класс. При этом можно объект класса чтения свойств передавать например в конструктор класса окна. При таком раскладе, после изменения конфигурации приложения вам не нужно менять сам класс окна. Достаточно будет лишь написать новый класс чтения свойств из базы так, что бы его интерфейс соответствовал интерфейсу класса чтения свойств их файла и передать объект нового класса в конструктор окна!
Вот вам абстракция окна. Она не меняется при смене реализации чтения конфигурации.
Вы сами совершенно не понимаете паттерн мост! Почитайте банду четырех еще раз!
об этом паттерне они пишут: Используйте паттерн мост, когда:
Нужно избежать постоянной привязки абстракции к реализации.
Когда конкретную реализацию необходимо выбирать во время выполнения программы.
И абстракции, и реализации должны расширяться новыми подклассами. В таком случае паттерн мост позволяет комбинировать разные абстракции и реализации и изменять их независимо.
Изменения в реализации абстракции не должны сказываться на клиентах, то есть клиентский код не должен перекомпилироваться.
Количество классов начинает быстро расти, как мы видели на первой диаграмме из примера. Это признак того, что иерархию следует разделить на 2 части.
Вы хотите разделить одну и ту же реализацию между несколькими объектами, и этот факт необходимо скрыть от клиента.
Это вам стоит еще раз перечитать банду четырех. Специально отыскал эту книжку, что я там вижу:
Авторы книги декларируют цель: Отделить абстракцию от ее реализации так, чтобы то и другое можно было изменять независимо.
По вашему здесь GOF просит объединять все в одном классе «МашинаРеализация»
читаем дальше: Абстракция окна и ее реализация помещаются в раздельные иерархии классов. Таким образом, существует одна иерархия для абстрактных классов окон (Window, IconWindow, TransientWindow) и другая (с корнем WindowImp) - для платформенно-зависимых конкретных реализаций. Так, подкласс XWindowImp предоставляет реализацию в системе X Window System.
Здесь тоже никто никого не просит ничего объединять.
Далее: Все операции подклассов Window реализованы в терминах абстрактных операций из интерфейса WindowImp. Это отделяет абстракцию окна от различных ее платформенно-зависимых реализаций. Отношение между классами Window и WindowImp мы будем называть мостом, поскольку между абстракцией и реализацией строится своего рода мост, и они могут изменяться независимо.
Ничего не напоминает? Или быть может пример с машиной это что то иное?
Если вы заявляете что по определению паттерна мост необходимо колеса, фары и двигатели объединить в одном классе — «МашинаРеализация», то покажите то самое определение о котором вы говорите. Даже интересно на это посмотреть.
Где в вашей статье черт подери дано хоть какое то определение? Ваша статья необработанный поток сознания.
Возьмите определение хотя бы из википедии: Bridge, Мост — шаблон проектирования, используемый в проектировании программного обеспечения чтобы «разделять абстракцию и реализацию так, чтобы они могли изменяться независимо». Шаблон bridge (от англ. — мост) использует инкапсуляцию, агрегирование и может использовать наследование для того, чтобы разделить ответственность между классами.
Кто вам сказал что нельзя отделить абстракцию от реализации заменив одно из свойств объекта другим объектом, который реализует необходимый интерфейс?
Поменяем объект двигатель на объект другого типа с тем же интерфейсом (другой двигатель), и машина все равно поедет без каких либо вмешательств. Вот вам абстракция машина. Она не поменялась при смене реализации двигателя!
В любом случае теперь у меня есть небольшой мануал, по которому сделать это можно намного быстрее.
Вот кстати цитата из той же книги.
Все, - теперь клиенты нашей системы могут свободно запускать данные команды добавления и редактирования в контекстах файлов или базы данных:Обратите на код в методе main – это то, что и достигается применением данного паттерна: независимый, единый код запуска любых видов команд в любом контексте, который не нужно будет менять и перекомпилировать при каких-либо изменениях в деталях реализации тех или иных операций, алгоритмов выполнения команд и т.д.
Конкретные реализации clientUpdateImpl и balanceCorrectImpl для простоты здесь определяются напрямую, но как говорилось выше часто бывает полезно получать их динамически в конструкторе команды (Command) из абстрактной фабрики.
Прокомментируете?
То что окно не должно читать свойства — не обращайте внимания, это просто пример.
Теперь объясните как же получается что вы смогли изменить приватные методы класса не изменив сам класс?
Учитываю вашу заносчивость предлагаю вам публично признать что вы заблуждаетесь.
Имеется окно. Цвет и размер окна хранятся в файле (пусть будет XML, это не важно)
Исходя из ваших слов, мне достаточно в классе окна получать цвет и размер при помощи приватного метода. Что то типа
private function getParam(){return readXML();
}
Но что будет если конфигурация приложения изменилась и теперь параметры хранятся в БД? Вам ничего не останется как изменить уже существующий класс, вставив вместо readXML() что то типа select * from table window.
Банда четырех вместо этого предлагает вынести реализацию чтения свойств в отдельный класс. При этом можно объект класса чтения свойств передавать например в конструктор класса окна. При таком раскладе, после изменения конфигурации приложения вам не нужно менять сам класс окна. Достаточно будет лишь написать новый класс чтения свойств из базы так, что бы его интерфейс соответствовал интерфейсу класса чтения свойств их файла и передать объект нового класса в конструктор окна!
Вот вам абстракция окна. Она не меняется при смене реализации чтения конфигурации.
Судя по вашим откровениям вам даже 6 месяцев стажа нельзя дать. Какие уж там 10 лет.
об этом паттерне они пишут:
Используйте паттерн мост, когда:Нужно избежать постоянной привязки абстракции к реализации.
Когда конкретную реализацию необходимо выбирать во время выполнения программы.
И абстракции, и реализации должны расширяться новыми подклассами. В таком случае паттерн мост позволяет комбинировать разные абстракции и реализации и изменять их независимо.
Изменения в реализации абстракции не должны сказываться на клиентах, то есть клиентский код не должен перекомпилироваться.
Количество классов начинает быстро расти, как мы видели на первой диаграмме из примера. Это признак того, что иерархию следует разделить на 2 части.
Вы хотите разделить одну и ту же реализацию между несколькими объектами, и этот факт необходимо скрыть от клиента.
Авторы книги декларируют цель:
Отделить абстракцию от ее реализации так, чтобы то и другое можно было изменять независимо.По вашему здесь GOF просит объединять все в одном классе «МашинаРеализация»
читаем дальше:
Абстракция окна и ее реализация помещаются в раздельные иерархии классов. Таким образом, существует одна иерархия для абстрактных классов окон (Window, IconWindow, TransientWindow) и другая (с корнем WindowImp) - для платформенно-зависимых конкретных реализаций. Так, подкласс XWindowImp предоставляет реализацию в системе X Window System.Здесь тоже никто никого не просит ничего объединять.
Далее:
Все операции подклассов Window реализованы в терминах абстрактных операций из интерфейса WindowImp. Это отделяет абстракцию окна от различных ее платформенно-зависимых реализаций. Отношение между классами Window и WindowImp мы будем называть мостом, поскольку между абстракцией и реализацией строится своего рода мост, и они могут изменяться независимо.Ничего не напоминает? Или быть может пример с машиной это что то иное?
Возьмите определение хотя бы из википедии:
Bridge, Мост — шаблон проектирования, используемый в проектировании программного обеспечения чтобы «разделять абстракцию и реализацию так, чтобы они могли изменяться независимо». Шаблон bridge (от англ. — мост) использует инкапсуляцию, агрегирование и может использовать наследование для того, чтобы разделить ответственность между классами.Кто вам сказал что нельзя отделить абстракцию от реализации заменив одно из свойств объекта другим объектом, который реализует необходимый интерфейс?
Поменяем объект двигатель на объект другого типа с тем же интерфейсом (другой двигатель), и машина все равно поедет без каких либо вмешательств. Вот вам абстракция машина. Она не поменялась при смене реализации двигателя!
Если конкретно, в комментарии ниже я привел ссылку. Там прекрасно показано зачем нужен мост.