Понимание Фабрик и я должен использовать их?
Я никогда не использовал Фабрики прежде по простой причине, я не понимаю, когда мне нужны они. Я работал над небольшой игрой в свое свободное время, и я решил реализовать FMOD для звука. Я посмотрел на обертку, разработанную для OpenAL (другая звуковая установка), и это смотрело что-то как...
SoundObject* SoundObjectManager* SoundObjectFactory*
SoundObject был в основном экземпляром каждого звукового объекта. SoundObjectManager просто управляет всеми этими объектами. Это является достаточно прямым и имеет много смысла, но я не получаю то, что делает фабрика или что это используется. Я читал на Factorys, но все еще действительно не получаю их.
Любая справка ценилась бы!
4 ответа
Считайте Factory «виртуальным конструктором». Он позволяет создавать объекты с общим типом времени компиляции, но с разными типами времени выполнения. Вы можете переключить поведение, просто указав Factory создать экземпляр другого типа среды выполнения.
К сожалению, я полагаю, что вам потребуется построить таблицу поиска для кодов языков. Это коды ISO 639-1 . Дополнительные сведения см. в разделе «Обозначения языков и языков» руководства по программированию интернационализации.
-121--4088951- Может быть создан каталог интеграционных тестов в src/test ? Конечно, для интеграционных тестов разделение становится менее ясным, но есть что-то, что группирует A, B и C вместе, нет? Я бы начал с этого и посмотрел, как идут дела. Трудно сразу найти идеальное решение, и решение «OK» лучше, чем не решение.
Заводы используются при необходимости параметризации реализации. FMOD - кроссплатформенный, он должен решить, какую конкретную реализацию дать вам для вашей платформы. Это то, что делает Фабрика. Существуют два основных узоров абстрактный заводской образец и заводской метод .
Гипотетическая ситуация: я пишу звуковую библиотеку, которую хочу запустить на нескольких платформах. Я постараюсь сделать как можно больше кода независимым от платформы, но, безусловно, некоторые из них нужно будет изменить для Windows, OSX и Linux.
Итак, я пишу все эти различные реализации, но я не хочу, чтобы конечный пользователь заставлял свою программу зависеть от Linux, Windows или чего-то еще. Я также не хочу поддерживать 4 разных интерфейса для моего API. (Обратите внимание, что это лишь некоторые из причин, по которым вы можете создать фабрику - конечно, есть и другие ситуации).
Итак, я определяю этот прекрасный общий базовый класс SoundObject , который определяет все методы, которые клиент может использовать. Затем я делаю свои LinuxSoundObject , WindowsSoundObject и 5 других производными от SoundObject . Но я собираюсь скрыть все эти конкретные реализации от пользователя и предоставить им только SoundObject . Вместо этого вы должны вызвать мою SoundObjectFactory , чтобы получить то, что вам кажется простым старым SoundObject , но на самом деле я выбрал для вас правильный тип среды выполнения и сам создал его экземпляр.
Два года спустя на свет появляется новая ОС, которая вытесняет Windows. Вместо того, чтобы заставлять вас переписывать программное обеспечение, я просто обновляю свою библиотеку для поддержки новой платформы, и вы никогда не увидите изменений в интерфейсе.
Все это довольно надумано, но, надеюсь, вы уловили идею.
Фабрики изолируют потребителей интерфейса от того, какой тип среды выполнения (т.е. реализация) действительно используется.
Фабрики можно использовать для реализации инверсии управления, а также для отделения кода инстанцирования ("new") от логики ваших компонентов. Это полезно при написании модульных тестов, поскольку вы можете не хотеть, чтобы тестируемые объекты создавали кучу других объектов.