|
|
|
Паттерн мост
|
|||
|---|---|---|---|
|
#18+
Читаю главу про паттерн "Мост" в GoF. Там говорится, что паттерн мост решает проблему зависимости клиента от реализации. Но клиент всё равно должен знать какой конкретной реализацией надо инициализировать абстракцию. Там при описании примера с оконными системами говорится: "Только сама реализация окна должна зависеть от платформы, на которой работает приложение. Потому в клиентском коде не может быть никаких упоминаний о платформах". Но как этого избежать если при создании класса IconWindow(Refined Abstraction), например, его надо параметризовать объектом какой-то конкретной реализации, например, XWindowImp(Concret Implementor). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2016, 18:57 |
|
||
|
Паттерн мост
|
|||
|---|---|---|---|
|
#18+
Хотя они там частично отвечают на этот вопрос. Предполагается, что Window(Abstraction) получает нужную реализацию от некоей фабрики, о которой в самом паттерне не говорится ничего. Тогда о платформе должен знать тот, кто создаёт эту фабрику. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2016, 19:21 |
|
||
|
Паттерн мост
|
|||
|---|---|---|---|
|
#18+
.NETЧитаю главу про паттерн "Мост" в GoF. Там говорится, что паттерн мост решает проблему зависимости клиента от реализации. Но клиент всё равно должен знать какой конкретной реализацией надо инициализировать абстракцию. Там при описании примера с оконными системами говорится: "Только сама реализация окна должна зависеть от платформы, на которой работает приложение. Потому в клиентском коде не может быть никаких упоминаний о платформах". Но как этого избежать если при создании класса IconWindow(Refined Abstraction), например, его надо параметризовать объектом какой-то конкретной реализации, например, XWindowImp(Concret Implementor). У тебя есть абстрактная графическая подсистема, реализованная в виде интерфейса или абстрактного базового класса BaseWindowSystem. В этой абстракции ты собираешь все методы, которые тебе нужны для отрисовки твоей графики, не задумываясь о конкретной графической подсистеме. Потом ты создаешь сколько тебе нужно классов (напр Application), в которых будет содержаться зависимость BaseWindowSystem. Каком образом ты будешь эту зависимость внедрять - это не проблема паттерна, возможно зависимость будет внедряться каким-то DI-фреймворком. Идея в том, что ты можешь наделать хоть сколько реализаций BaseWindowSystem (напр WaylandWindowSystem) и с каждой из них программа будет работать, т.к. реализуется контракт. Именно в этом смысл паттерна, как именно ты ты будешь выбирать конкретную реализацию - неважно, может в твоей программе она будет выбираться простым выбором по условию, а может на основании файла-конфигурации или ты скомпилируешь разные варианты программы с разными реализациями, главное, что для этого тебе не придется менять ни BaseWindowSystem, ни Application, ни WaylandWindowSystem. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2016, 20:01 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=39344457&tid=1340566]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
62ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 264ms |
| total: | 417ms |

| 0 / 0 |
