Лучше иметь механизм кэширования внутри или снаружи класса Factory?

Question

Мой вопрос здесь не связан исключительно с языком, это скорее общая концепция программирования.

Если у меня есть класс Factory, у которого есть метод для возврата объектов Parser, и я знаю, что эти классы анализатора не нужно создавать более одного раза за цикл итерации (конечно, за пределами фабрики).

Лучше с точки зрения использования и разделения объектов создать механизмы кэширования для всех созданных экземпляров анализаторов внутри Factory, т. Е. Во время вызова метода или вне его, когда метод уже был вызван?

Заранее спасибо.

Answer 1

Возможно, вы могли бы определить интерфейс для вашего Factory, а затем иметь несколько реализаций - одна реализация могла бы выполнять внутреннее кэширование, чтобы гарантировать, что класс Parser создается только один раз.Другая реализация не может выполнять кэширование и просто предоставлять новые Parser объекты всякий раз, когда что-то запрашивает один.

В любом случае, я предлагаю вам попытаться сохранить эту логику в ваших Factory реализациях, а остальная часть вашего приложения работать с интерфейсом Factory.Таким образом, если позже вы решите, что не хотите ничего кэшировать или что вам нужно изменить способ создания экземпляра Parser, у вас есть только одна точка создания объекта - внутри Factory.Это позволяет очень легко изменить способ создания Parser объектов без необходимости изменять каждую часть вашего приложения, которая хочет новый Parser.

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

Answer 2

Я не понимаю проблемы: клиентам фабричного класса все равно, кэшируются ли полученные ими объекты или нет.Таким образом, логика кэширования должна принадлежать фабрике.

Более того, когда вы реализуете это, вы сначала реализуете фабрику без кэширования, чтобы что-то работало быстро ( Сделайте самое простое, что могло бы работать ).Затем вы реализуете кеширование.Обратите внимание, что выполнение чего-либо еще - это случай преждевременной оптимизации .Если клиентские классы должны были знать, кэшируются ли объекты или нет, ваш процесс разработки быстро сгнил бы.

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

(PS: я вижу много шаблонных шумов в ответах на этот вопрос. Это распространено среди Java?люди всегда думают в терминах шаблонов? Здесь нет никаких синглетонов для проектирования, нет прокси-классов для написания здесь, только простое рассуждение о том, какой интерфейс не может измениться.)

Answer 3

Как заявил Shakedown, одним из подходов будет работа с интерфейсом и предоставление реализации с кэшированием и отдельной реализации без кэширования. Однако в некоторых обстоятельствах это может быть немного громоздким (действительно ли вашему приложению нужны две разные реализации?).

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

Использование динамического прокси расширит этот подход и позволит вам реализовывать кэширование везде, где вам нужно, с очень небольшим дополнительным скоплением библиотеки (но за счет повышения сложности).

Answer 4

Похоже, мне нужно использовать Singleton Pattern .