LINUX.ORG.RU

Порождающий патерн для БД.


0

0

{Вечер,Утро,День} добрый.

Разбираюсь с патернами, но ни могу найти на что похожа следующая идея и где почитать про ее реализацию. Надеюсь на помощь советами и ссылками.
Ситуация довольно проста и широко распространенная, — нужно сделать уровень абстракции для работы с разными хранилищами данных (mysql, postgresql, filesystem, /dev/null, etc.).
Я вижу это следующим образом.
Есть базовый класс, например Storage, от него наследуются MysqlStorage, PostgresqlStorage, FilesystemStorage. Только я не понимать какой патерн их должен порождать. Фабрика? Все что мне видится так это что-то в следующем духе:
Storage storage = StorageFactory.getStorage(«mysql»);
А внутри getStorage огромный свич.
Так оно должно быть? Как-то я не уверен в этом всем.

★★★★★

Читаем про DAO и ServiceLocator interface DAO<A, PK>{ A findByPrimaryKey(PK id); } interface DogDAO extends DAO<Dog, Long>{} class DogDAOMysqlImpl implements DogDAO { ... }

abstract class DAOFactory { public abstract DogDAO getDogDAO(){} public DAOFactory getFactory(String type){ if(type.equals(«mysql»){return new MySQLDAOFactory()} } }

class MySQLDAOFactory extends DAOFactory { public DogDAO getDogDAO( ) {return new DogDAO();} }

как-то так, ну лучше объекты создавать только 1н раз и хранить в какой-нибудь карте

anonymous ()

Есть такой специальный секретный паттерн, он так и называется - Абстрактор.

volh ★★ ()

Storage storage = new MysqlStorage();

чего хочется то? Выбора хранилища по конфиг файлу? Тогда как то так:

Storage storage = StorageFactory.getStorage(properties);

потому что кроме названия ещё нужны параметры (имя файла, имя базы, и тд). Зачем вносить паттерны просто ради паттернов, не понимаю.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

> потому что кроме названия ещё нужны параметры (имя файла, имя базы, и тд).
Да, но они будут для всех одинаковы (dsn только).

Зачем вносить паттерны просто ради паттернов, не понимаю.

Так а как правильно то?

urxvt ★★★★★ ()
Ответ на: комментарий от urxvt

через ассоциативный контейнер, в котором ключам - идентификаторам соответствуют, например, адреса функций, создающих уже конкретные объекты

(см Александреску)

yoghurt ★★★★★ ()
Ответ на: комментарий от yoghurt

через ассоциативный контейнер, в котором ключам - идентификаторам соответствуют, например, адреса функций, создающих уже конкретные объекты

И чем это лучше свича? Ведь абсолютно те же яйца вид в профиль. Разве что эту мапу ещё построить нужно.

bibi ()
Ответ на: комментарий от bibi

1. Не оопе-стайл
2. При большом «ассортименте выпускаемой продукции» свитч раздуется, в одном файле сконцентрируется вся инфа о всех создаваемых классах
3. Расширяемость хуже

стр. 223 (изд. 2002), хотя это всё относится к С++, не знаю как там в Java (которая, судя по всему, у ТС)

yoghurt ★★★★★ ()
Ответ на: комментарий от yoghurt

1. Не оопе-стайл

А пихать указатели на ф-и в мапу - это, очевидно, тру-ООП-стайл, да.

2. При большом «ассортименте выпускаемой продукции» свитч раздуется, в одном файле сконцентрируется вся инфа о всех создаваемых классах

А мапа не раздуется? Она волшебным образом будет генерироваться сама, без участия разработчика.

3. Расширяемость хуже

Совершенно одинаковая.

bibi ()
Ответ на: комментарий от bibi

>А пихать указатели на ф-и в мапу - это, очевидно, тру-ООП-стайл, да.

http://www.antiifcampaign.com/

А мапа не раздуется? Она волшебным образом будет генерироваться сама, без участия разработчика.

Вся генерация сведется к конкретизации типов ключа и значения. Содержимое мапы будет наполняться уже в рантайме

3. Расширяемость хуже

Совершенно одинаковая.

ОЛОЛОЛОЛОЛОЛО, оператор switch уже научился добавлять в себя кейсы в рантайме?

yoghurt ★★★★★ ()
Ответ на: комментарий от yoghurt

Вся генерация сведется к конкретизации типов ключа и значения. Содержимое мапы будет наполняться уже в рантайме
ОЛОЛОЛОЛОЛОЛО, оператор switch уже научился добавлять в себя кейсы в рантайме?

Откуда она будет наполняться? Кем? Где требование к динамическому подключению модулей в рантайме присутствует в оригинальном задании?

Человеку нужна тупая как три рубля фабрика. На вход которой дается DSN a'la DBI & K на выходе же - конкретная реализация заданного интерфейса к базе. Проще некуда. Чтобы лабу сдать. Готовых реализаций, которые можно посмотреть и сварганить свой аналог - вагон с маленькой тележкой на любой язык цвет и вкус. Берется перловый DBI или пхп-шный PDO или что-то другое по вкусу и все, проблема решена в течении получаса. Тут же сейчас родится очередной монстр на базе всех мыслимых и немыслимых конструкций, которые может породить воспаленный разум в плюсах, который работать конечно же не будет зато все классно и с пользой проведут время.

bibi ()
Ответ на: комментарий от yoghurt

Вся генерация сведется к конкретизации типов ключа и значения. Содержимое мапы будет наполняться уже в рантайме

PS: Предлагаю сразу, чтобы зря не терять время, перейти к обсуждению нужности или ненужности использования XMLя для хранения конфигурации сетевых сервисов. Все равно мимо этой богатой темы не пройдём. Впрочем, можно сразу и к лиспу перейти. Что зря тянуть.

bibi ()
Ответ на: комментарий от urxvt

Ну вот в этот контейнер может сам класс себя складывать, типа регистрировать. Хотя тоже странно будет, зачем классу знать об этом контейнере. Но зато не будет супер божественного класса, который должен знать о всех и который будут править разработчики всех плагинов. Как-то так.

vga ★★ ()
Ответ на: комментарий от vga

Ну вот в этот контейнер может сам класс себя складывать, типа регистрировать. Хотя тоже странно будет, зачем классу знать об этом контейнере. Но зато не будет супер божественного класса, который должен знать о всех и который будут править разработчики всех плагинов. Как-то так.

Это что понимать под плагином. Если это динамически подгружаемый в рантайме плагин, то, очевидно, разработчику плагинов как раз нет необходимости что-то там править в управляющей фабрике. Ему нужно лишь реализовать заданный фабрикой интерфейс, не более. В свою очередь ей понять, как отобразить DSN на тот или иной плагин и загрузить его. Как раз это хранится где-нить там, в настройках. Но это все уже чуть веселее, чем 'просто фабрика'. И AFAIU не нужно топикастеру здесь и сейчас.

bibi ()
Ответ на: комментарий от bibi

> И AFAIU не нужно топикастеру здесь и сейчас.
Вообще-то не особо нужно сейчас. Но дико интересно. Так что вы обсуждайте, обсуждайте :)

urxvt ★★★★★ ()
Ответ на: комментарий от urxvt

все это инверсия зависимостей. есть разные методы и способы, можно реализовать с помощью уже описанных паттернов, можно и вообще не реализовывать, просто в нужный момент заменить строку с вызовом коструктора стоража в коде.. все это детали, все это не решает.

trashymichael ★★★ ()
Ответ на: комментарий от bibi

>>В свою очередь ей понять, как отобразить DSN на тот или иной плагин и загрузить его

Ну если это ява, то фабрика может обойтись Class.forName(somePacakage + dsn + someSuffix), как-то так. Тогда уже будут захардкоджены package, а не классы. Но XMLя не будет, и настроек не будет. SUN в J2ME для коннекторов что-то подобное делает, AFAIK.

vga ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.