Не можете управлять экземплярами с фабричным шаблоном метода?

Question

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

Это замечательно, но для того, чтобы фабрика могла создать объект, когда это необходимо, этим классам объектов нужны открытые конструкторы. Поэтому кто-то теоретически может пойти прямо в класс и попросить новый экземпляр, и фабрика не будет знать. Объект, созданный вне фабрики, не будет добавлен в пул объектов.

Есть ли способ остановить создание объектов за пределами фабрики?

Answer 1

Есть ли веская причина для предотвращения создания объектов, кроме как на фабрике? Этот вид контроля обычно не продуктивен. Имейте в виду, что вы никогда не сможете полностью предотвратить это благодаря рефлексии Вы просто делаете это более раздражающим. Если это вопрос стиля кодирования, производительности или чего-то подобного в вашем проекте, вам лучше использовать инструмент статического анализа, такой как checkstyle , PMD или FindBugs чтобы следить за объектами в неправильном месте.

Answer 2

В качестве альтернативы вы можете сделать ваши экземпляры классов частными вложенными классами фабрики.

Answer 3

Вы должны сделать ваши класы приватными для его пакета

Answer 4

Я на самом деле не рекомендую следующее, и я, вероятно, никогда бы не сделал это сам.

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

Для этого в конструкторах объектов просто вызовите Thread.currentThread().getStackTrace(), затем «раскручивайте» стек, пока не доберетесь до фрейма сразу после (до) конструктора. Теперь вы можете проверить вызывающего абонента и выдать исключение, если это не Factory.

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

Теперь, очевидно, есть издержки при проверке и раскручивании трассировки стека, и если фабрика не может интернировать / кэшировать ранее построенные объекты (т.е. она должна каждый раз возвращать новый экземпляр), и вы вызываете его достаточно много раз все это может стать дорогостоящим.

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

Answer 5

Есть несколько вещей, которые вы можете сделать, чтобы контролировать доступ к конструктору в различной степени:

1. Дайте классу конструктор с областью видимости пакета (по умолчанию) и фабрика существует вта же фабрика: если вы сделаете это, только классы в одном и том же пакете могут получить доступ к этому конструктору.Этого должно быть достаточно.

2. Сделайте ваши классы закрытыми внутренними классами фабрики: это гарантирует, что только фабрика сможет использовать их.

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

Answer 6

Они могут иметь защищенные конструкторы, а не общедоступные.