Паттерны проектирование и Delphi.

← →
by © (2004-12-24 15:48) [0]

Кто может подсказать информацию о реализации паттернов проектирования в Delphi? Какие паттерны уже реализованы в самом языке (или VCL), а что вообще нереализуемо. На ум пока приходит что TAction это очень похоже на реализацию Command.

← →
Игорь Шевченко © (2004-12-24 15:51) [1]

> На ум пока приходит что TAction это очень похоже на реализацию
> Command.

А в TComponent реализован паттерн компоновщик (Compositor)

← →
Суслик © (2004-12-24 15:53) [2]

> а что вообще нереализуемо.

Не думаю, что таковые есть.

Нереализуем в каноническом виде АДАПТЕР в применимости к интерфейсу класса - нут нет в дельфи в чистом виде множественного наследования.

Есть также проблемы с инкапсуляцией. Например в ХРАНИТЕЛЕ. Ну нет в дельфи друзей классов.

В остальном с концептуальной точки зрения общеизвестные паттерны, приведенные в книге Эрика Гаммы с товарищами, в дельфи реализуемы.

← →
КаПиБаРа © (2004-12-24 15:54) [3]

by © (24.12.04 15:48)
Кто может подсказать информацию

К сожалению информации не существует. Есть только материя.

← →
DiamondShark © (2004-12-24 15:57) [4]

А на уровне языка реализованы singleton и class factory.

← →
by © (2004-12-24 16:09) [5]

Есть задача - обеспечить унифицированный доступ к разнам источникам данных. Для реализации этого мне наиболее понравился паттерн Мост (Bridge). При его использовании получаем такую схему.
DALBridge (Data Access Layer Bridge) с методами типа Open, Close, Insert, Delete
К этому Мосту обращаются все классы которым нужен доступ к данным
Есть класс DALBridgeImplementation, у которого наследники DALBridgeADOImp, DALBridgeIBXImp и пр. которые содержат код доступа для конкретных источников и оборачивают его в методы DALBridge.

В классе DALBridge есть ссылка на класс DALBridgeImplementation, конкретныя реализация которого (DALBridgeADOImp или DALBridgeIBXImp) создается при создании DALBridge.

В итоге мы получаем унифицированный доступ к данным через единые метода и поля DALBridge.

Кто-то использовал подобный подход или есть лучше реализации?

← →
Суслик © (2004-12-24 16:16) [6]

А МОСТ ли это?:)
В каконическом описании паттерна предполагается наследование в твоем случае и класса DALBridge с комбинированием операций базового класса в укрупненные сущности.

← →
Sandman25 © (2004-12-24 16:18) [7]

[5] by © (24.12.04 16:09)

В классе DALBridge есть ссылка на класс DALBridgeImplementation

Что-то я не понял. Зачем ссылка? Пусть DALBridgeImplementation будет наследником DALBridge. Если это невозможно, можно задействовать шаблон Adapter.

← →
by © (2004-12-24 16:29) [8]

Sandman25 © (24.12.04 16:18) [7]
Если DALBridgeImplementation будет наследником DALBridge, то при использовании DALBridge будет не понятно какая конкретная реализация используется.

Суслик © (24.12.04 16:16) [6]
А МОСТ ли это?:)
А какой паттерн здесь подходит больше? Или как сделать по другому?

← →
Sandman25 © (2004-12-24 16:33) [9]

[8] by © (24.12.04 16:29)

Если DALBridgeImplementation будет наследником DALBridge, то при использовании DALBridge будет не понятно какая конкретная реализация используется.

Фабричным методом получили реализацию и используем без знания того, какая именно реализация.

← →
Суслик © (2004-12-24 16:33) [10]

> [8] by © (24.12.04 16:29)
> А какой паттерн здесь подходит больше? Или как сделать по
> другому?

Советую книгу дочитать до конца. Судя по всему ты до МОСТА дочитал и решил его применить.

← →
Sandman25 © (2004-12-24 16:38) [11]

[10] Суслик © (24.12.04 16:33)

Кстати, я не совсем понимаю. По-моему, Мост - это Адаптер + Стратегия. То есть искуственно получаем единый интерфейс (для этого нужен Адаптер) различных объектов (Стратегия). Зачем нужно было выделять Мост в отдельный шаблон?

← →
by © (2004-12-24 16:44) [12]

Суслик © (24.12.04 16:33) [10]
Та дочитал я её до конца, но почему то мост мне показался наиболее подходящим для данной ситуации.

← →
Суслик © (2004-12-24 16:46) [13]

> [11] Sandman25 © (24.12.04 16:38)

> Зачем нужно было выделять Мост в отдельный шаблон?

Обычный и, наверное, единственно правильный ответ на этот вопрос - различие выполняемых задач.

Если рассуждать, как ты, то можно прийти к тому, что есть 3 паттерна: насследник, полиморфор и инкапсулятор:)

Вот скажи - какой здесь АДАПТЕР. Цель данного паттерна иная - адаптировать один интерфейс к другому интерфейсу. Ты полагаешь, что можно считать правомерным группировку базовых операций МОСТА в более крупные операции примером использования паттерна АДАПТЕР?

В таком случае АДАПТЕРОМ можно считать любой класс, который юзает какое-либо АPI. Ерунда какая-то. :)

← →
}|{yk © (2004-12-24 16:54) [14]

> Есть задача - обеспечить унифицированный доступ к
> разнам источникам данных. Для реализации этого мне
> наиболее понравился паттерн Мост (Bridge). При его
>использовании получаем такую схему.
> DALBridge (Data Access Layer Bridge) с методами типа
>Open, Close, Insert, Delete
> К этому Мосту обращаются все классы которым нужен
> доступ к данным

Мой вариант конечно примитивен, но для обычных задач его хватает
http://delphimaster.ru/articles/frames/index.html

← →
Sandman25 © (2004-12-24 16:55) [15]

[13] Суслик © (24.12.04 16:46)
Если рассуждать, как ты, то можно прийти к тому, что есть 3 паттерна: насследник, полиморфор и инкапсулятор:)

:)

Вот скажи - какой здесь АДАПТЕР. Цель данного паттерна иная - адаптировать один интерфейс к другому интерфейсу. Ты полагаешь, что можно считать правомерным группировку базовых операций МОСТА в более крупные операции примером использования паттерна АДАПТЕР?

Ты хочешь еще и Фасад добавить? :)
Я понимаю так:
есть объект для работы с IBX, у которого есть InsertIBX...
есть объект для работы с DBF, у которого есть InsertDBF...
Теперь мы добавляем Мост (он же Адаптер), c интерфейсом Insert. Реализация этого моста для IBX вызывает InsertIBX и т.д, а для DBF - InsertDBF.

Разве бывает Адаптер, который не выполняет роль Моста, вызывая требуемые методы у "вложенного" объекта?

← →
Суслик © (2004-12-24 16:55) [16]

> [12] by © (24.12.04 16:44)

Посмотри [6].
МОСТ предполагает использование базового класса (моста) в качестве интерфейса к БАЗОВЫМ операциям, реализация которых мостом поручается конкретному классу-исполнителю.

Не хочу повторять пример из книги. Посмотри сам. Если не ошибаюсь там пример про рисование в окне, где реализацию примитвов (линия, текст) предоставляет impelentaion, а потомки моста комбинируют из них что-то специфической.

В том виде в котором ты привел описание это можно, например, считать стратегией.

← →
Суслик © (2004-12-24 16:57) [17]

> Теперь мы добавляем Мост

Это не мост. Смотри описание.

← →
by © (2004-12-24 17:04) [18]

Фактически я хочу адаптировать интерфейсы разным классов к одному общему. Но Адаптер я не могу использовать, так как он предполагает наследование, а у IBX, ADO, XML нет общего предка. По этому я и посчитал Мост (Bridge, wrapper) подходящим для этой роли.
Об абстрактной и конкретной фабриках я тоже думал. Но это когда продуктов много, а здесь он один.

← →
Суслик © (2004-12-24 17:09) [19]

> [15] Sandman25 © (24.12.04 16:55)

У паттерна МОСТ очень точно выбрано название. Пока не прочтешь паттерн внимательно подмывает, все объектные решения, которые позволяют одному клиенту полиморфно обращаться к конкретным операциям, называть МОСТ. Как минимум так у меня был, да и у тебя то же самое.

В действительности МОСТ это предоставление узкого круга БАЗОВЫХ операций, реализация которых осуществлена в конкретномом классе BridgeImpelemenation.
Согласен, что обращение к BridgeImpelemenation можно считать стратегией.
Но сама идея МОСТА: комбинирование в потомках класса Bridge сложных операций из базовых операций, которые реализованы у другом классе, в явном виде не прослеживается ни в одном другом паттерне.

← →
Sandman25 © (2004-12-24 17:10) [20]

[17] Суслик © (24.12.04 16:57)
Это не мост. Смотри описание.

Согласен, попутал.

← →
Суслик © (2004-12-24 17:13) [21]

> Но Адаптер я не могу использовать, так как он предполагает
> наследование, а у IBX, ADO, XML нет общего предка

Это то здесь каким боком?
Ты можешь адаптировать что угодно в нужны тебе интерфейс. Даже классы из разных в принципе бибилиотек.
Почитай внимательно описание АДАПТЕРА. Судя по приведенному тобой описанию именно это тебе и нужно.

← →
by © (2004-12-24 17:16) [22]

}|{yk © (24.12.04 16:54) [14]
У тебя все FrameCurrentDataSet должны быть наследниками TDataset, и только его же минимум операций они могут использовать.

Я же хочу чтобы можно было бы хранить данные даже в текстовом файле и реализовывать много методов.
Например метод DALBridge.Sort
В IbxImp это было бы сделато через Select ... Order By
В ADO например через локальную сортировку посредством индексов.
И т.д.
Но клиент этого класса знал бы только о DALBridge.Sort и все.

← →
Sandman25 © (2004-12-24 17:17) [23]

[19] Суслик © (24.12.04 17:09)

Большое спасибо!
Точно, я давно уже чувствовал, что название у моста не очень ясное. Когда забываешь суть и пытаешься восстановить по названию, Адаптер + Стратегия получается :)

← →
Суслик © (2004-12-24 17:27) [24]

> Точно, я давно уже чувствовал, что название у моста не очень
> ясное

Когда поймешь паттерн хорошо, то обязательно оценишь точность выбора его названия.

← →
by © (2004-12-24 17:29) [25]

Суслик © (24.12.04 17:27) [24]
Когда поймешь паттерн хорошо
Вот поэтому я и спрашиваю о реализации этиз паттернов в Delphi да еще бы и в привязке к БД. А то примеры с графическим редактором не очень понятны, так как графические редакторы я не делаю ((

← →
Sandman25 © (2004-12-24 17:33) [26]

[24] Суслик © (24.12.04 17:27)

Я бы его назвал Переводчик. Тот же мост, но более понятно ИМХО.

← →
Суслик © (2004-12-24 17:36) [27]

> [25] by © (24.12.04 17:29)

Виноват, [24] был адресова [23].

> Вот поэтому я и спрашиваю о реализации этиз паттернов в
> Delphi да еще бы и в привязке к БД

Мое имхо, что говорить о реализации паттернов вообще не очень хорошо.
Скорее всего желание "реализовать паттерн" говорит о недостаточной подготовки в области паттернов.

Если не ошибаюсь, то о том, что паттерн это не руководство к действию говорит и сам Гамма.

[27] Суслик © (24.12.04 17:36)

Если желание реализовать паттерн вызвано желанием лучше его понять, в учебных целях, так сказать, то нормально.
Если речь о реальной задаче, то согласен.

> [28] Sandman25 © (24.12.04 17:38)

Точное замечание.
Вряд ли речь идет про учебыне задачи. Здесь речь адназначна про теальное дело.

Ну так мне показалось.

Суслик © (24.12.04 17:40) [29]
Да это реальная задача. Я и не говорю о б использовании паттерна как кода. Я его хочу взять за основу, для дальнейшей реализации. Вот в каком направлении дввыгаться для этой задачи я и хочу выяснить. Если это будет без паттернов, то тоже подходит.

> У тебя все FrameCurrentDataSet должны быть
> наследниками TDataset, и только его же минимум
> операций они могут использовать.

Да нет... Ты же в наследниках можешь переопределять все описанные методы.

> [30] by © (24.12.04 17:51)

> Вот в каком направлении дввыгаться для этой задачи я и хочу
> выяснить

Мое однозначеное мнение продолжать изучать паттерны как таковые.
Решение само прийдет. :)

> [33] by © (24.12.04 17:54)

Ну в общем да.
В такие книги надо вживаться, а не чатать.
Это долгий процесс. Я уже почти год этим знанимаюсь. Только недавно почуствовал силы смотреть на проектирование концептуально исходя из множества возможных реализаций.

}|{yk © (24.12.04 17:53) [31]
Да нет... Ты же в наследниках можешь переопределять все описанные методы
Переопределять да. Но если у TDataset нет метода LoadBlobFromXML (например), то и переопределить нечего.

Так никто же не мешает нужные методы добавить в базовый фрейм...

}|{yk © (24.12.04 18:00) [36]
Так никто же не мешает нужные методы добавить в базовый фрейм...
Это будут методы фрейма а не датасета. А я хочу отвязать логику от представления, чтобы представление можно было безболезненно заменять на другое. Фрейм, форма, web, консоль ...

Ну так по той же схеме напиши свой класс TMyDataSet и опрерделяй/переопределяй...

Вот о методе написания этого класса (или группы классов) и вопрос )

Паттерны проектирование и Delphi. Найти похожие ветки