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

Все правильно - http://en.wikipedia.org/wiki/Factory_method_pattern, а читать GoF http://en.wikipedia.org/wiki/Design_Patterns_%28book%29

Паттерны бесполезны.

Ваш вариант реализации?

Читаем про 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н раз и хранить в какой-нибудь карте

Делать фабрики через switch - не тру :)

Ну а по теме - да, фабрика

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

Storage storage = new MysqlStorage();

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

Storage storage = StorageFactory.getStorage(properties);

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

> Делать фабрики через switch - не тру :)
А как лучше сделать?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://www.antiifcampaign.com/

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

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

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

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

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

> через ассоциативный контейнер
А ну это я в курсе, я думал может еще какой патерн найдется :)

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

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

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

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

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

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

Точно, лисперы, питонисты и стив ягг http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html смотрят на все это странно.

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

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

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

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

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

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